61–70 of 74 posts
2 points by sreeix 160 days ago | flag | discuss http://news.ycombinator.com/item?id=4047424 316 points by moonlighter 457 days ago | flag | comments http://news.ycombinator.com/item?id=2859234
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
They only created the HN account today in order to post this story, and they chose a username which is obviously a reference to Michiel de Mare from the SO post.
Whereas according to mmare's profile, he's been around on HN for a good while now.
I agree that it's strange.
"If I asked this question, 5 minutes later it would be closed as subjective"
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.
In case 1 a lock-out policy would quite easily negate your attack. In case two the hashing algorithm used is often more important than the length and complexity of the password (up to a point of course, but that point is nowadays well beyond what's pactical for a user)
Earlier quoted context omitted.
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.
EDIT: SRP is going to be integrated into TLS soon anyway, so we might as well hold our breath for that.
Earlier quoted context omitted.
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.
Would it be possible to replace the whole storing by signing the token with some private key, so that the validity of the token can be checked without having to compare it to some stored value ?
The first answer mentions a couple of time that any token given to the user (for remember-me login or password reset) should be hashed in the database. Would it be possible to replace the whole storing by signing the token with some private key, so that the validity of the token can be checked without having to compare it to some stored value ?
Whereas if only token hashes are stored in the database, then the entire database could be stolen and nobody can use it to generate valid cookies.
EDIT: Also, if an account goes rogue you have no way to invalidate its cookies, so you'll have to do a lookup for each request to see if the account is blocked.
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…
Also, though less of an issue with SSL, the HMAC approach is subject to replay attacks while expire_at .
EDIT: The HMAC approach also lacks any method to invalidate cookies manually, or automatically e.g. when the user changes their password. This means a compromised account is open to attack until expire_at , and there's nothing you can do about it other than blocking the account for that duration, which now means that each request needs to do a database lookup to see if the account is blocked. You could generate a per-user secret key, but now you have a database lookup again, so you might as well use the magic number scheme.
> 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.
An adversary who makes a single copy of your database could impersonate any user, and go unnoticed for potentially a huge period of time unless you have good intrusion protection. A targeted attack might steal just a single token, and could last a few seconds only, but then have unauthorised access indefinitely via the token.
EDIT: Incidentally this is why only the hash of the token should be stored in the database, just like storing passwords. Also the token should expire.