Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If you develop web apps, don't do this.

sneak.datavibe.net

Post reply on HN
Print view View original

101–110 of 113 posts

Re: If you develop web apps, don't do this.

#101

Post by AretNCarlsen »

andrewflnr wrote: post #99
AretNCarlsen wrote: post #96

Earlier quoted context omitted.

> Once you have the users ... then you should start to think about something more secure. Until then, do all you can, within reason, to get users. Worked well for Sony! Seriously, that is an egregious abuse of both ethics and morality, the latter because you are implicitly abusing your users' trust (unless your welcome screen says "NOT YET SECURE" in huge font). If implementing reasonable security before you enter be…

I think you're overblowing his point a little, and attacking a straw man. I don't think he's talking about not-using-refrigerators/storing-passwords-in-plain-text type of insecurity, just worrying less about loopholes that are non-critical and unlikely to be exploited anyway until you have lots of users. He did say "within reason".

Here are two suggestions that we would have seen, if the underlying assumption was not that {increasing the derivative of user count per day} justifies {poor security}:

1.) Implement bulky external security measures -- like client-side certs or VPNs -- and replace them with more scaleable solutions as the user count grows.

2.) Inform your users that they are interacting with an unsecured fledging service, such that they do not have an expectation of privacy. At the very least, warn them not to use this service on an unsecured coffee-shop WAN.

Re: If you develop web apps, don't do this.

#103

Post by LokiSnake »

cdcarter wrote: post #95
sneak wrote: post #45

Earlier quoted context omitted.

> With the instant login system, you can't expire the token after its first use since the email will still be in the user's inbox where they expect it to work. As the article mentions, you can expire them after a week or so. And if you're smart enough to do this, you're smart enough to fall back gracefully to the old "login form" behavior when you get a link with an expired token.

Hell, you could expire them as soon as they are clicked, and then have the fallback.

An immediate expiry would not solve the initial problem. A user can easily click on the link on an iPhone, then want to read the content on his desktop. A timed expiry would work much better.

Re: If you develop web apps, don't do this.

#104

Post by dkokelley »

After reading the article and comments, it appears that what this really represents is a need for more secure email protocols. How would one go about creating and ensuring and end-to-end secure email protocol? It could be done within a domain, but once you send or receive messages outside of your domain it's up to the intermediate and end parties to keep the message secure.

I suppose you could ensure secure communications via encrypted messages and end-clients with the key, but how could such a system be ubiquitous and practical?

Re: If you develop web apps, don't do this.

#105

Post by rachelbythebay »

It seems like this calls for a two-pronged approach. If you've been logged in to their site from that browser in that account, then the link from the e-mail should auto-log in (unless it's been disabled for that account). Otherwise, it should prompt to allow an actual login as usual.

This way, you can forward an e-mailed link, and unless they happen to have logged as you already, they don't get into your account.

This probably means a significant amount of attention to detail to exactly which cookies are set, how long they live, and what they mean, but it sounds worth the effort.

Re: If you develop web apps, don't do this.

#106

Post by lamby »

sneak wrote: post #45
mdasen wrote: post #36

The reason so many sites prompt for password is for security. Yes, they will also send you an email with a link to reset the password to the same address. However, the difference there is that you will know if someone has changed your Foursquare password and the token used to allow for a password change can be expired immediately after the change takes place rather than offering continued access. With the OKCupid sys…

> With the instant login system, you can't expire the token after its first use since the email will still be in the user's inbox where they expect it to work. As the article mentions, you can expire them after a week or so. And if you're smart enough to do this, you're smart enough to fall back gracefully to the old "login form" behavior when you get a link with an expired token.

Another trick is to mix in the user's hashed password when you generate and check the HMAC - that way if the user ever changes their password all the previous links fail to work.

Re: If you develop web apps, don't do this.

#107

Post by leviathan »

pyrhho wrote: post #53
yaix wrote: post #13

Earlier quoted context omitted.

Just wanted to comment the exact same thing. And netbooks still have a big screen compared to many phones.

There's a mobile version of the blog, though (without the massive header/footer.

Mobile version didn't kick in on iPad, which doesn't do CSS position: fixed, so the footer ends up hiding some of the text, and makes the site unreadable.

Re: If you develop web apps, don't do this.

#108

Post by pbreit »

mdasen wrote: post #36

The reason so many sites prompt for password is for security. Yes, they will also send you an email with a link to reset the password to the same address. However, the difference there is that you will know if someone has changed your Foursquare password and the token used to allow for a password change can be expired immediately after the change takes place rather than offering continued access. With the OKCupid sys…

> The reason so many sites prompt for password is for security

I doubt it. I think the reason has more to do with what their framework or authentication scheme supports or how rigorous they are with user engagement.

Re: If you develop web apps, don't do this.

#109

Post by pbreit »

randomwalker wrote: post #16

The funny thing is that CAN-SPAM mandates 1-click opt-out, and requiring login to unsubscribe is specifically prohibited.[1] So most websites already have code to include and verify auth tokens in emailed links, which they utilize when they are mandated to. But somehow they haven't figured out that it is in their own interest to do so the rest of the time. [1] http://blogs.boomerang.com/blog/2009/06/16/can-spam-2008-…

> CAN-SPAM mandates 1-click opt-out

Actually it requires one-click or two-click. And not for transactional emails.

Re: If you develop web apps, don't do this.

#110

Post by uxp »

Locke1689 wrote: post #92
Locke1689 wrote: post #39

Earlier quoted context omitted.

Remember email is not encrypted. The links can be intercepted. This is somewhat false. You should clarify your intention here.

Whoever downvoted me is apparently unaware of encrypted protocols like SMTP w/ TLS (which most major webmail providers use) and IMAP (which is increasingly preferred over POP3).

IMAP is an unencrypted protocol (as well as SMTP and POP3) in the same regard that HTTP is not HTTP + SSL. All three mail protocols can be wrapped nicely inside SSL/TLS, but it is only point to point encryption.

If I connect to my SMTP server over TLS and send you a message to your server, I cannot guarantee that your SMTP server is listening on the secure ports, let alone serving IMAP or POP3 over SSL to your client, which can be intercepted. Never mind the fact that 45%+ of all mail servers are storing these messages in plain text in /var/mail/

Post reply on HN