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

The definitive guide to forms based website authentication

stackoverflow.com

Post reply on HN
Print view View original

51–60 of 74 posts

Re: The definitive guide to forms based website authentication

#51

Post by dfox »

oakwhiz wrote: post #5
DenisM wrote: post #2

As a rule most security advice on stack overflow is dangerously wrong. It's just not a good topic for the site, because consensus if often wrong in such complicated question. I don't see anything obviously wrong with this particular article (aside from challenge response or SSL choice - one should just always use SSL, and if you can't, then seek professional advice), however I am still apprehensive of the hive mind.

There was some information in there about SRP being patented that I thought was misleading. It is patented, but it's freely licensed.

The main problem with SRP being mentioned at all is that it has no meaningful security value in web application context. It makes sense when client does not entirely trust server, which makes no sense when you deliver client as bunch of .js files from the same "untrusted" server.

Re: The definitive guide to forms based website authentication

#52

Post by sirmarksalot »

jonalexr wrote: post #19

Regarding website authentication, I've been looking for some feedback on a new auth scheme. Instead of using a standard password (all characters are allowed, min 5 characters, common passwords not allowed), you're able to login with a 4 digit passcode. I know someone just cringed at that thought, but the idea centralizes around improving user experience on the website. First, all normal precautions would be taken (no…

Sounds expensive. I already pay ~$1/month in SMS fees for TFA on my Google account. If it cost me $0.20 every time I fatfingered my password, I would probably stop using your service. What's worse, attack #3 would cost the victim even more money, and it's one thing to get charged for your own screwups. It's another thing altogether to get charged for somebody else trying to hack you.

Re: The definitive guide to forms based website authentication

#53

Post by mdemare »

Well, this is weird. I created this question when StackOverflow was just out of beta, hoping to steer it to more broader questions - guides, if you wish. This question really took off, but the format didn't, and SO mostly became a stack of incredibly specific questions and answers.

And now somebody, but not me, has submitted this question to HN. Under my name. I'm puzzled...

Re: The definitive guide to forms based website authentication

#54

Post by skeletonjelly »

pygy_ wrote: post #46
nsxwolf wrote: post #42

I still have no idea what a "Remember me" checkbox is when I encounter one. It certainly doesn't seem to be a "keep me logged in" function. I don't know if it has something to do with form autofill, because my browser seems to do that wether it is checked or not. Can anyone demystify this for me?

"Remember me" checkboxes and form auto-fill are unrelated. The form auto-fill behavior depends is part of the browser UI, and can be configured in its option menu. The a "remember me" checkbox sets an identifying cookie with a late expiry date. Until that date, and unless you log out, the web site will recognize you (the server keeps a registry of what ID number correspond to which user). No need to authenticate on c…

> The form auto-fill behavior depends is part of the browser UI, and can be configured in its option menu.

This can be dictated by the website as to whether or not this is allowable.

Re: The definitive guide to forms based website authentication

#55

Post by nsxwolf »

pygy_ wrote: post #46
nsxwolf wrote: post #42

I still have no idea what a "Remember me" checkbox is when I encounter one. It certainly doesn't seem to be a "keep me logged in" function. I don't know if it has something to do with form autofill, because my browser seems to do that wether it is checked or not. Can anyone demystify this for me?

"Remember me" checkboxes and form auto-fill are unrelated. The form auto-fill behavior depends is part of the browser UI, and can be configured in its option menu. The a "remember me" checkbox sets an identifying cookie with a late expiry date. Until that date, and unless you log out, the web site will recognize you (the server keeps a registry of what ID number correspond to which user). No need to authenticate on c…

Great info! I'll try examining the cookie next time I encounter one.

Re: The definitive guide to forms based website authentication

#57

Post by jonalexr »

sirmarksalot wrote: post #52
jonalexr wrote: post #19

Regarding website authentication, I've been looking for some feedback on a new auth scheme. Instead of using a standard password (all characters are allowed, min 5 characters, common passwords not allowed), you're able to login with a 4 digit passcode. I know someone just cringed at that thought, but the idea centralizes around improving user experience on the website. First, all normal precautions would be taken (no…

Sounds expensive. I already pay ~$1/month in SMS fees for TFA on my Google account. If it cost me $0.20 every time I fatfingered my password, I would probably stop using your service. What's worse, attack #3 would cost the victim even more money, and it's one thing to get charged for your own screwups. It's another thing altogether to get charged for somebody else trying to hack you.

Hm, that's a good point. I've found that most people have a text message plan which allows for unlimited incoming text messages but we'll take that into account and make it clear to the user.

Re: The definitive guide to forms based website authentication

#58

Post by jonalexr »

bigiain wrote: post #39
jonalexr wrote: post #19

Regarding website authentication, I've been looking for some feedback on a new auth scheme. Instead of using a standard password (all characters are allowed, min 5 characters, common passwords not allowed), you're able to login with a 4 digit passcode. I know someone just cringed at that thought, but the idea centralizes around improving user experience on the website. First, all normal precautions would be taken (no…

You're now outsourcing your users security to their cell phone provider. Was it Twitter who had their domain hijacked by someone ringing up the right telco and saying something like "my cell pone is out of action temporarily, can you please forward all calls/messages to this other number?" in a sufficiently convincing fashion to some minimum wage telco support staff, then getting a two factor auth token sent to an at…

Thanks for the feedback! You brought up a valid point. It's something that will become more of an issue as the website increases it's user base and we'll think of ways to address it.

Re: The definitive guide to forms based website authentication

#59

Post by moe »

UnoriginalGuy wrote: post #14

I'm normally highly sceptical of anything which is essentially a how to guide on security of, well, anything but I have to say whoever this author is they absolutely know their stuff. Normally security advice is just 1980s circle-jerking of the same meaningless "sound good" concepts (e.g. "At least one upper-case, number, special character") but actually, no, not in this case. Instead he is giving advice which is mod…

To provide a counterpoint, the section about the "Remember Me"-cookie is rather terrible (I stopped reading after that).

It's not fundamentally flawed but rather inelegant (and potentially expensive) to store a magic number server-side for each session. You can implement the same thing more easily by handing out tamper-proof (HMAC) cookies containing the start- and end-time, and storing only the last_logout-timestamp for each user on the server-side.

Any cookie where expire_at or created_at is to be rejected at validation time.

Re: The definitive guide to forms based website authentication

#60

Post by mceachen »

mdemare wrote: post #53

Well, this is weird. I created this question when StackOverflow was just out of beta, hoping to steer it to more broader questions - guides, if you wish. This question really took off, but the format didn't, and SO mostly became a stack of incredibly specific questions and answers. And now somebody, but not me, has submitted this question to HN. Under my name. I'm puzzled...

It's not under your name, unfortunately. mdemare != mmare
Post reply on HN