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

41–50 of 74 posts

Re: The definitive guide to forms based website authentication

#41

Post by bigiain »

debacle wrote: post #6
thefsb wrote: post #4

it's mostly good. NIST abolished their algo for pasword entropy estimation some time ago. i do not much like any password strength tests, most of which rate any number of terrible passwords as strong. as such i think they give a false sense of security. maybe consider cracklib. as DenisM said, always use SSL for all traffic if security matters and don't trust SO for security advice.

The only really useful password strength test would be one that said "A stock Thinkpad would be able to brute force this password in $x hours and $y minutes." Might make people think twice about that six character password.

How about a response that says "we just googled that combination of email address and the md5 hash of that password, it's been listed in at least 7 different database disclosures, including the Gawker one, the Sony one, and 5 different pr0n site compromises. We suggest using a different password here."

;-)

Re: The definitive guide to forms based website authentication

#42

Post by nsxwolf »

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?

Re: The definitive guide to forms based website authentication

#43

Post by DenisM »

duncans wrote: post #23

> if an attacker got his hands on your database, he could use the [persistent login cookie] tokens to log in to any account If an attacker gets his hands on your database, it's kind of game-over already.

I don't mean to be rude, but you clearly don't understand this subject. Databases leak, not least of all due to human errors. Half the effort in computer security goes to preventing the leaks, and the other half goes to mitigating the consequences of such leaks. Hashing the passwords, salting the hashes, the entire md5/sha/pbkdf/bcrypt/scrypt debacle, all of these things are there only to mitigate the consequences of a database leak that is presumed to happen at some time in the future.

Re: The definitive guide to forms based website authentication

#44

Post by callahad »

rodolphoarruda wrote: post #16
dochtman wrote: post #13

Added a mention of/link to Mozilla Persona. IMO, it's the easiest way to handle authentication today, fully decentralized, secure, and with nice privacy guarantees. With it, you don't have to care about user names (just use email addresses), passwords and secure storage thereof, it mostly just works (and once it'll get linked into the big email providers in December or so, almost everyone will already have an account…

how does it prevent that sniffing data issue from happening when you are not using SSL? Or you just cannot use Persona without SSL?

Presuming you're using session cookies, Persona is no less secure than any other reasonable authentication system when used without SSL.

It also has the nice property that what Persona transmits over the wire -- the proof of identity -- is only valid for 120 seconds. Sniffing it in real time would temporarily allow you to masquerade as another user on that specific site, but any sort of delay and you're locked out.

This is a huge improvement over, say, transmitting passwords, which could grant access to an account for months or years.

Re: The definitive guide to forms based website authentication

#45

Post by callahad »

led76 wrote: post #36

What do people think of services like https://www.loginprompt.com/ ? (provides logins as a service for your startup) Isn't this sort of security something we wish we didn't have to learn? And for people who don't take the time maybe it's best to let a third-party handle it.

> Isn't this sort of security something we wish we didn't have to learn?

Absolutely. Time spent on your auth scheme is time you're not spending on building your product. (And half-assing your auth scheme generally comes back to bite people.)

That said, outsourcing it to a centralized provider may not be the best idea for business, user, or security reasons. So it's a balance.

Of course, I'm biased: I work on the Persona team at Mozilla, where we're trying to build a simple, secure, fully decentralized, and open source authentication system that fits that niche rather nicely, but the points above stand: you have to figure out the opportunity cost of your chosen solution. There's no universal answer.

Re: The definitive guide to forms based website authentication

#46

Post by pygy_ »

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 connection because the cookie is sent with each request.

Without the remember me option, the expiry time is short, say 30-60 minutes, but it may be renewed as long as the user is active. If you're inactive for a longer period, the cookie will be discarded, and the site will not recognize you anymore.

When you log out, the session reference is deleted on the server, and, optionally, the cookie is cleared in the browser.

Re: The definitive guide to forms based website authentication

#47

Post by devicenull »

WayneDB wrote: post #18

Why do maximum security sites always disable auto-complete for username and password? That seems less secure to me. If I always have to type in my password, chances are that I'll choose a password that can be easily remembered or I'll be forced to write it down somewhere. (Personally, I use plugins to get around this anyway. My computer, my rules.)

Some stupid PCI audits fail you for having autocomplete enabled. I know it's completely absurd, but try convincing an auditor that's the case.

Re: The definitive guide to forms based website authentication

#48

Post by shardling »

think-large wrote: post #32
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…

I think that is the beauty to this post it wasn't one person... However, Jeff Atwood seems to be the main contributor. He was also the co-founder of Stack Overflow. http://stackoverflow.com/posts/477578/revisions The power of team work.

He's probably incorporating information from highly rated posts below, rather than generating content.

Re: The definitive guide to forms based website authentication

#49

Post by hayksaakian »

Two things that stood out to me:

Given that the most common 50 passwords are known, why not reject them outright? Simply state to the user: your password is too easy to guess.

Passwords should always allow spaces in order to allow people to use easier to remember passwords, a la xkcd.

http://preshing.com/20110811/xkcd-password-generator

Re: The definitive guide to forms based website authentication

#50

Post by cedricd »

callahad wrote: post #45
led76 wrote: post #36

What do people think of services like https://www.loginprompt.com/ ? (provides logins as a service for your startup) Isn't this sort of security something we wish we didn't have to learn? And for people who don't take the time maybe it's best to let a third-party handle it.

> Isn't this sort of security something we wish we didn't have to learn? Absolutely. Time spent on your auth scheme is time you're not spending on building your product. (And half-assing your auth scheme generally comes back to bite people.) That said, outsourcing it to a centralized provider may not be the best idea for business, user, or security reasons. So it's a balance. Of course, I'm biased: I work on the Pers…

100% agree with you. I love the concept of Persona, but it has a serious cold-start problem. If I could implement it and nothing else on my site, I would, but unfortunately the reality today is that most users don't know it.
Post reply on HN