1,792 reputation
515
bio website touset.org
location San Francisco, CA
age 30
visits member for 1 year, 11 months
seen 6 hours ago

Cyclist. Rubyist.


Jul
2
comment Automated software hackers use to try passwords
Please don't use the "lazy" approach recommended. Use a password manager and solve the problem for real. LastPass, KeePass, 1Password, etc., are all well-built implementations. Pick one, use it.
Jul
2
awarded  Curious
Jul
1
comment Hashing session tokens
First, openssl_random_pseudo_bytes() returns bytes, not characters. "60 characters" is entirely dependent upon what encoding you use (hex? base64? raw binary?). This is important information to know. Assuming your password_hash function is a slow hash, it's unnecessary to pass your tokens through that type of function. Any modern secure cryptographic hash (for instance, SHA-256) is good enough; it's not possible to brute-force the preimage as with passwords, assuming the token itself is cryptographically strong.
Jul
1
comment Hashing session tokens
Session tokens, remember-me tokens, and similar authentication-equivalent tokens should be hashed in the database. Not all database breaches allow write access, nor do all allow read-only access to every table, and not all database breaches are noticed immediately. Not hashing tokens certainly isn't as bad as not hashing passwords, but given how simple it is to implement, there's little reason not to.
Jun
24
comment I know scrypt is newer than bcrypt, but is there any reason it would be weaker?
True. There are also well-known time-memory tradeoffs that an attacker can use against scrypt, negating the memory requirements. Just thought I'd mention that there are some arguments for going with bcrypt over scrypt. That said, both are excellent, and any security distinction between the two is minuscule compared to using a simple salted hash.
Jun
23
comment I know scrypt is newer than bcrypt, but is there any reason it would be weaker?
Actually, the Catena paper outlines a cache-timing attack against scrypt. This largely negates the memory-hardness property of scrypt against a well-motivated attacker. As a result, if you ignore scrypt's memory-hardness property, bcrypt may be better in that there's a far smaller difference in its performance characteristics on CPUs (likely defender hardware) and GPUs (likely attacker hardware).
Jun
23
comment Aren't password managers still incredibly risky?
1Password absolutely does not, although you're right about LastPass. That said, @user49637 seems to believe that if a service like LastPass goes down, your passwords go with it. Or that you would ever send your credentials to them in such a way that they could be phished. Neither of those scenarios is the case.
Jun
23
comment Aren't password managers still incredibly risky?
Your concerns seem to revolve around password management as a service provided over the Internet. Most password management applications do not work this way — the software and password database are stored entirely on your own machine (e.g., 1Password, LastPass, KeePass). Combine this with something like Dropbox and you can sync your passwords to any device, without having to worry about a third party going offline and taking your passwords with them.
Jun
23
comment Aren't password managers still incredibly risky?
If someone has enough access to install a keylogger on your system, you're already hosed.
Jun
20
comment Theoretical home grown password options, or what is it that SCrypt, BCrypt, PBKDF2 does that is so special?
scrypt has memory-hardness as well (distinguishing it from bcrypt and PBKDF2). If each hash requires 16MB to compute, an attacker with a 2,560-core GPU would require over 40GB of memory on the card to fully utilize every core – typical graphics cards of this caliber only have 4–8GB of memory. You can forget about FPGAs or ASICs. Iterated SHA, on the other hand, can be done essentially entirely in GPU registers.
Jun
20
comment Theoretical home grown password options, or what is it that SCrypt, BCrypt, PBKDF2 does that is so special?
Also, the SHA-family of hashes are very fast to compute in dedicated hardware, and not so fast in general purpose CPUs. One design criteria of a slow-hash is to minimize any possible advantage of an attacker over a defender. SHA-512 is a poor choice for that.
Jun
20
comment Is salted MD5 or salted SHA considered secure?
Not to mention, it can never accurately measure the password's strength. Whatever metric you use will be gameable.
Jun
20
comment Is salted MD5 or salted SHA considered secure?
No. Password crackers use heuristic rules that will let them crack enormous numbers of non-random passwords. Most 12-character passwords your users will actually use (e.g., d34rm0m1!!!!) will fall extremely quickly. I truly cannot imagine that there is no better use of your time than to micro-optimize the storage space of your users' hashed passwords. Just use bcrypt or scrypt and move on to more important problems.
Jun
20
answered Is salted MD5 or salted SHA considered secure?
Jun
20
comment Is salted MD5 or salted SHA considered secure?
The issue with MD5 and SHA-1 isn't their collision-resistance. It's their speed.
Jun
11
comment How secure is iOS Touch ID?
I could be wrong, but I believe each app can define its own fallback (e.g., a strong password) in the case Touch ID fails. The 4-digit passcode is just the fallback for unlocking the phone, and is not tied to the use of Touch ID itself.
May
28
comment Reliable random seed for RNG
/dev/urandom on Linux/OS X/BSD, CryptGenRandom() on Windows. Or save yourself the effort and use one of the many password managers that already exist and do this for you.
May
24
comment Is it secure to use *no authentication* for services listening only on localhost?
This kind of setup automatically improves exploits that grant remote, unprivileged access into ones that grant remote, privileged access. Are you okay with that?
May
24
comment Why are GPUs so good at cracking passwords?
Salts do not protect against brute force attempts. Slow hashes do.
May
24
comment I want to roll my personal cloud hosted Password Manager using pass. How secure/insecure would this be?
@3h8d I'm going to paraphrase Thomas Ptacek, but if you think the dangerous stuff is contained inside those tools and you'll be safe just gluing them together, you're gonna have a bad time.