= 27d567bc2d48d9f40e9ccc20ea370b15)
CBHacking comments on Open thread, Feb. 9 - Feb. 15, 2015 - Less Wrong Discussion
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (321)
Looks like Less Wrong limits password lengths to 20 characters, which makes it hard to use "correct horse battery staple"-style password schemes.
It also raises worrying considerations about how passwords are stored in the database. Passwords should never be stored in plain text, nor with reversible encryption. Instead, each account should store a password verifier value (and a salt, unique to the user).
A password verifier is the result of running a password, its salt, and possibly another input that isn't kept in the DB all through a function that produces some deterministic value that is nigh-impossible to brute force. A property of password verifiers is that they produce output of a constant length, regardless of the input length. This makes it easy to allow arbitrary-length passwords because any actual limit you impose is artificial and exists for some reason other than your database schema.
For those familiar with hash functions: a raw hash, even a long or fancy one like the new SHA3 family, is a bad password verifier function. However, it does exhibit the desired properties with regard to length. In fact, you can build a decent PVF out of cryptographic hash functions; see PBKDF2.
The worrying questions have somewhat less worrying answers. Here is the cause of the length limit of 20 (in r2/r2/templates/login/html):
Removing the maxlength="20" restriction on password fields allows longer passwords without a problem (I'm actually unsure why that's there in the first place -- it doesn't actually prevent a malicious actor from sending a 1 GB password, as it's a client-side check).
Good to know. I hadn't actually bothered to check; I just used a unique password and email address as a matter of course - but I'm glad anyhow. Of course, that doesn't guarantee they're storing the password verifier, but I certainly could go read the source myself and find out.
Of course, if I was actually concerned about the security of my account here, I wouldn't use the site at all because it's only available unencrypted. Given how easy and cheap (even free) it is to enable TLS these days, I'm honestly surprised this site not only defaults to plaintext but doesn't support encryption at all. Intercepting network traffic is easy (promiscuous mode on open WiFi, run your own hotspot with an expected SSID, ARP spoofing, etc.)