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

91–100 of 113 posts

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

#91

Post by drdaeman »

sneak wrote: post #78
Joakal wrote: post #69

Earlier quoted context omitted.

PGP-encrypted emails? It becomes a question of security vs convenience eventually with security considerations (Someone mentioned dating sites are more engagement > security). There is no 'safest' way with encryption. It's a matter of time before it's breached.

PGP encrypted emails? Are you serious? Those of us that live in the Real World send our regards.

Unless your general audience are hackers.

For example, Canonical's Launchpad requires you to sign "code of conduct" with your GPG key before doing certain actions. And, if I remember correctly, they do send GPG encrypted emails for key ownership verification.

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

#92

Post by Locke1689 »

Locke1689 wrote: post #39
underwater wrote: post #7

A good idea for some situations. There are some obvious caveats: * Remember email is not encrypted. The links can be intercepted. * Consider looking at other factors (like IP, browser data, persistent cookies) that will let you know the user is legit before you green light the auto-login. * Link to HTTPS, not HTTP. The user might be on a shared computer and you don't want login-able URLs left in the history. * Force…

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).

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

#93

Post by mikecomstock »

DavidMcLaughlin wrote: post #65

The real point is: don't do two-level ACL on websites. At my previous company we had these "auto-login" links in emails and they are extremely powerful. But maybe once every six months people would call or write in and say "I forwarded a job posting from one of your email alerts to a friend and they had full access to my account!" and we'd have to revisit the issue again, but the conclusion was always the same - we w…

A good take-away from this might be "don't do two-level ACL until you have user traction".

DavicMcLaughlin says, "we were getting absolutely ridiculous user engagement..." When you are starting a site, you want as little resistance to usage as possible, and this helps with that. It makes it one step easier for people to use your site. It helps reduce the typical chicken/egg problem, or any other "it's hard to get users" problem.

Once you have the users, and security becomes more of a concern ("But security should always be a concern", yeah I know.) then you should start to think about something more secure. Until then, do all you can, within reason, to get users.

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

#94

Post by underwater »

sneak wrote: post #8
underwater wrote: post #7

A good idea for some situations. There are some obvious caveats: * Remember email is not encrypted. The links can be intercepted. * Consider looking at other factors (like IP, browser data, persistent cookies) that will let you know the user is legit before you green light the auto-login. * Link to HTTPS, not HTTP. The user might be on a shared computer and you don't want login-able URLs left in the history. * Force…

The "click here to reset your password" links are sent over unencrypted email, too. I guess I am being insufficiently clear about why this is no less secure than what exists today. > Force the user to enter their password to access sensitive settings or data (like changing email, passwords, etc.) If they have to enter their password to change their password... then how will the "click here if you forgot your password…

That's true but with reset password links you can force the user to do extra work, like enter a CAPTCHA or answer a secret question. That should prevent bots from scraping and compromising accounts on a large scale.

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

#95

Post by cdcarter »

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.

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

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

#96

Post by AretNCarlsen »

mikecomstock wrote: post #93
DavidMcLaughlin wrote: post #65

The real point is: don't do two-level ACL on websites. At my previous company we had these "auto-login" links in emails and they are extremely powerful. But maybe once every six months people would call or write in and say "I forwarded a job posting from one of your email alerts to a friend and they had full access to my account!" and we'd have to revisit the issue again, but the conclusion was always the same - we w…

A good take-away from this might be "don't do two-level ACL until you have user traction". DavicMcLaughlin says, "we were getting absolutely ridiculous user engagement..." When you are starting a site, you want as little resistance to usage as possible, and this helps with that. It makes it one step easier for people to use your site. It helps reduce the typical chicken/egg problem, or any other "it's hard to get use…

> 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 beta testing is such a resource burden that your product will go under before it can get its footing, then your product goes under. Ethics do not go away when your profitability and success are on the line -- that is the specific moment when ethics come into play.

I realize you have already thought through this and have a different POV. Newbies are liable to see this kind of talk however, and think it is an accepted industry-wide practice to treat security as an afterthought until you have scaled, when that is in fact a profitable but unacceptable antipattern.

P.S.- This is like a new small-town restaurant saying "Refrigerators are expensive, so we can't afford to refrigerate our eggs and milk until we get more customers. Otherwise we might go under from the increased operating cost, and then our customers wouldn't get to enjoy our restaurant!" Draw your own conclusion.

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

#97

Post by thenduks »

sneak wrote: post #6
Legion wrote: post #4

If you create a blog, don't use fixed headers and footers that take up half a netbook's screen.

Sorry, I design for 2560x1600. I don't want poor people reading my site. (That's a joke. I didn't even make the theme.)

Joke or not, I have to point out that just because someone's screen resolution is 2560x1600 doesn't mean they have their browser that huge. Personally, my browser is never wider than 1100px. I do usually go as tall as the screen, but on a small laptop...

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

#99

Post by andrewflnr »

AretNCarlsen wrote: post #96
mikecomstock wrote: post #93

Earlier quoted context omitted.

A good take-away from this might be "don't do two-level ACL until you have user traction". DavicMcLaughlin says, "we were getting absolutely ridiculous user engagement..." When you are starting a site, you want as little resistance to usage as possible, and this helps with that. It makes it one step easier for people to use your site. It helps reduce the typical chicken/egg problem, or any other "it's hard to get use…

> 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".

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

#100

Post by nitrogen »

Splines wrote: post #89
unshift wrote: post #80

Earlier quoted context omitted.

amazon does that. you can browse the site and it identifies you and your preferences, but when you go to check out or modify account settings, you have to enter your password.

... and it feels really natural. Amazon identifies me easily, but if I do anything that feels like I need my password, it asks for it. Apple's App Store has similar logic, although it bothers me in one place where they ask for your password when downloading free apps. And then there's Windows Live. Click on anything remotely related to Passport? You need a password (followed by 17 redirects, which is hilarious when m…

followed by 17 redirects, which is hilarious when managers have sound turned on and you here the "click click click click click" as IE bounces around

I wonder if someone added a few extra redirects just for that reason. Seems like a quick and easy way to remotely identify coworkers that don't customize or disable their sound scheme and use IE.

Post reply on HN