If you develop web apps, don't do this. • Hacker News Board

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

#51

Post by skrebbel » Tue, Jun 14, 2011, 8:52 AM UTC

sneak wrote: post #46

bkhl wrote: post #38

I'm not sure if I can totally agree with the author. I understand his pain, but email isn't the most secured place. If your email is being "watched" by someone else, then that someone else can access other web services that you own WITHOUT requiring to type passwords! I know that it is very rare to have your email being watched, but in security, even the most rare case should be taken into consideration. It's a trade…

> If your email is being "watched" by someone else, then that someone else can access other web services that you own WITHOUT requiring to type passwords! The person watching your email can ALREADY DO THAT NOW by clicking on the "I forgot my password" link, intercepting the reset email, and then setting a new password and logging in.

That assumes someone has live access to your email. If someone has a recent enough dump (or simply a mail you forwarded yourself, because you didn't understand the security implications), then the "forgot password" button does really provide more security than login tokens inside the URL.

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

#52

Post by danenania » Tue, Jun 14, 2011, 9:01 AM UTC

newhouseb wrote: post #31

If you want to do this, at least make the login cookie expire at the end of the session. I had a friend forward me an OKCupid e-mail when they sent mis-matches for April Fools - a few days later I realized that I had somehow been logged in as said friend and was majorly creeped out. Had I been less mature about it there was major potential for trolling said friend - particularly on OKC.

Mistakes like this will inevitably occur even with a cookie that expires as you suggest. Not as often as with a non-expiring token, but there are plenty of people who will leave a browser tab up for days at a time, keeping the session alive.

The convenience is tempting but it seems careless.

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

#53

Post by pyrhho » Tue, Jun 14, 2011, 9:03 AM UTC

yaix wrote: post #13

Legion wrote: post #4

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

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.

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

#54

Post by danenania » Tue, Jun 14, 2011, 9:05 AM UTC

thirsteh wrote: post #28

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-…

You can use such tokens to disable email notifications, and still not provide complete access to the account, though.

This seems like a good compromise.

Allow immediate access for convenience in some cases, but restrict that access to a specific task until login.

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

#55

Post by JoachimSchipper » Tue, Jun 14, 2011, 9:09 AM UTC

itcmcgrath wrote: post #44

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…

Not to also forget that if you have automagic login links in the email, you can no longer forward that email to anyone without compromising your account. Try educating end-users on that one!

Simple solution: put a persistent cookie on the computer of everyone who's ever logged in. Automatically log the user in if this cookie is present and the URL is correct. Obviously, the cookie should be unforgeable - e.g. HMAC-SHA1(service_secret_key, username).

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

#56

Post by cubicle67 » Tue, Jun 14, 2011, 9:10 AM UTC

Legion wrote: post #4

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

yes. I use space to move the content up a screen, and layouts like this mean I then have to go and scroll back a few inches.

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

#57

Post by zaidf » Tue, Jun 14, 2011, 9:16 AM UTC

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-…

AFAIK CAN-Spam only applies for unsolicited emails, so a newsletter from a service you opted into does not need to abide by it. May be I'm mistaken.

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

#58

Post by danenania » Tue, Jun 14, 2011, 9:16 AM UTC

acron0 wrote: post #14

I for one will not be adding this feature to my web app. However, might it be possible to kick in a login process using OAuth/OpenID? The onus isn't then on you to validate the user.

This is the way to go imo. For some reason a lot of people have the idea that it's somehow more secure to build your own login system than it is to use Google's or Facebook's. But doing it yourself opens up new vulnerabilities and you'll be reinventing the wheel making all the mistakes that have been tested out of veterans' systems.

The convenience factor is also superb.

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

#59

Post by zaidf » Tue, Jun 14, 2011, 9:19 AM UTC

Plentyoffish emailing you your password.

OKCupid sending login token'd links

Notice the trend? When you're a dating website, engagement trumps security in many cases. But if you are a bank or any service with some liability, you're probably going to play it conservative as you should.

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

#60

Post by thirsteh » Tue, Jun 14, 2011, 9:21 AM UTC

danenania wrote: post #54

thirsteh wrote: post #28

Earlier quoted context omitted.

You can use such tokens to disable email notifications, and still not provide complete access to the account, though.

This seems like a good compromise. Allow immediate access for convenience in some cases, but restrict that access to a specific task until login.

Yes, but the scope of access would have to be severely limited, to the point where's there's no real sense in doing it, e.g. you'd have to prompt for settings change, but also probably read/write access to private messages, wall, etc... It'd be a lot of work with little return (the more return, the less security).