26
votes
Are tildes passwords salted?
I was reading over tildes' privacy policy and saw that passwords are stored hashed, but are they salted as well?
not that tildes is big enough atm to have big public database breaches, but in the future it's a good idea to store passwords with a secure salting system, especially to help users that might have common passwords like "Diane" in the Tumblr post.
Here are the Tildes models. On line 62,
password_hashis defined. It has a setter on lines 156-162, where you can see that it is run throughhash_string(), defined here.There, we see that it uses argon2-cffi, specifically the PasswordHasher class, which defines a 16-byte salt unless told otherwise.
So, yes.
Sweet. Nice to see argon2 too rather than something outdated like MD5 or SHA-1.
cool, thank you for the detailed response!
@Adys answered the main question, but I wanted to quickly address this as well:
Tildes uses a list of 517 million passwords that have been seen in data breaches, and won't let users use any password that's in that list. Almost all simple/common passwords will be blocked because of that.
From this list is seems that they're only released as SHA-1, which is fairly crackable now. So that leaves one of two possibilities:
Neither option seems ideal. Is one of these options the case, or am I missing a third possibility?
edit: Although I suppose TLS would mitigate the concern of option 1.
The dump is downloaded onto the Tildes server and checked there, not client-side.
Even though I'm not using it, they do actually have a pretty good method for checking over their API without needing to reveal the actual password that you're checking, see this post about Pwned Passwords (specifically the "Cloudflare, Privacy and k-Anonymity" section that I linked to).
Thanks for your answer! The API approach is quite clever.
Still, I'm not sure I understand their resistance to releasing the list in plain text. Presumably that data is already out in the wild as it's been assembled from various leaks. A full list would allow site owners to hash the entries ahead of time to whatever system their site is using. Then the final salt is just added on the server-side before storing in the database.
For non-API users, that seems more secure to me than sending SHA-1 hashes over the wire, anyway.
Yeah, I understand his justification for not releasing the actual passwords, but I also disagree with it. There's one major practical reason that I would have much preferred the actual passwords, which is that then people using the list could remove all the ones from it that are shorter than their required minimum password length or violate other restrictions, because those are effectively just a waste of space if people can't possibly use them anyway.
To show what I mean, Royce Williams (who has some pretty neat hash-cracking setups) cracked almost all (99.41%) of the SHA1 hashes in the original release (320M) and released some statistics about them: https://gist.github.com/roycewilliams/b1de2afbfe5cb71bea16c94042b9bbfc
Looking at the "Length" list at the top, you can see what percentage of the hashes belong to passwords of each length. So imagine that you're running a site where passwords have to be at least 10 characters long. 32% of the list is length 8, 13% is length 9, 10% is 7, 6% is 6, and then everything shorter than that is mostly insignificant. But that still means that over 61% of the passwords you're blocking are totally unnecessary, because they're impossible for people to use anyway due to being too short.
There are similar cases if you have any other password requirements as well. For example, those stats also show (under "Character-set") that 47% of the passwords are "loweralphanum" (lowercase letters and at least one number) and 24% are "loweralpha" (only lowercase letters). So if you require people to use at least one uppercase letter or symbol in their password, now over 71% are effectively useless to be blocking as well.
It's not a big deal in the end, but it's a bit annoying that you have to use way more resources than are strictly necessary if you have other restrictions that you could use to shrink the list.
Wow. I'm actually shocked that my old password isn't in that list. Six-letter word + single letter + single number. Eight characters total. That little fucker has really withstood the test of time.
Still, I prefer my randomly-generated 32-character base 70 passwords. Better not to tempt the universe :)
oh man, I forgot messing with that when I registered. thank you for implementing such cool features deimos