💾 Archived View for dioskouroi.xyz › thread › 25010709 captured on 2020-11-07 at 00:56:00. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
________________________________________________________________________________
MD5 is known to be very insecure and you should never use it for real world password hashing. Instead, you would use SHA-512, SHA3 or another highly secure algorithm.
No, you should use a (poorly named) "password hashing algorithm" which has different security properties from normal cryptographic hash functions.
Later on they indicate that they're using PBKDF2-HMAC-SHA512, which is outdated and not as good as scrypt or bcrypt, both of which are offered in the pycryptodome library they're using. The only reason to use PBKDF2 is for backwards compatibility, or with systems that don't offer better (memory-hard or cache-hard) algorithms. The documentation even states "New applications and protocols should use scrypt or bcrypt instead."[1]
Hardly ultra-secure. They didn't even bother reading the docs of the crypto library they used.
[1]
https://www.pycryptodome.org/en/latest/src/protocol/kdf.html
The architecture is convoluted and they couldn't even be arsed to read or understand the crypto they were using, so if they failed at that implementation why believe they didn't leave holes in such a complex architecture setup. I'd prefer simple and reliable.
It seems like infra playboys trying to make crypto. Go ahead and make stuff like this, it's great, but don't call it "Ultra Secure". A more apt description would be "Completely unproven and experimental while built on crypto primitives approaching obsolescence".
What's an infra playboy?
This is supremely complicated, compared to the usual advice of just using bcrypt, and there's a lot of complexity left unmentioned, mainly IAM. You need to ensure:
1. DynamoDB IAM permissions are correct.
2. EC2 IAM is correct.
3. The nitroenclave attestation is securely written, so as to avoid proxy-attestations from the main VM (and other attacks)
4. KMS IAM permissions are correctly written, to avoid direct decryption.
The additional complexity of writing this beast, managing it, making sure that your setup remains maintainable and scalable might be worth it, but you need to compare it to the ROI:
The salt for any hash cannot be accessed by the attacker to perform a brute-force attack.
Using bcrypt with a high cost factor pretty much guarantees the same.
I'd be more interested in seeing a SGX-like solution using NitroEnclaves. Perhaps something that solves the Signal Contact Discovery problem[0]?
[0]:
https://signal.org/blog/private-contact-discovery/
Looks like it's a bit overloaded.
https://web.archive.org/web/20201106201819/https://www.senti...
That really inspires confidence... infra playboys can't even setup a blog page to handle decent traffic, but trust them with their enclave work.
I wonder how this compares against bcrypt.
I'm not a encryption expert, but reading the article got the impression that bcrypt is superior, at least is IMO is easier to use
Yeah, if you're trying to guard against brute force attacks, having a hash that takes one second to generate seems like it would be pretty effective. Maybe not against an attacker with nearly unlimited computing resources, but then again, what really can stand up to that?
EDIT: No, I'm not really right about this, as explained here:
https://news.ycombinator.com/item?id=25011716
The hash they chose takes one second on their host. bcrypt and scrypt provide better guarantees in terms of computation complexity.
Yeah, basically any modern KDF not being misused trumps this... I feel bad for the people that worked on this, since it definitely required a lot of effort, but I don't see any widespread adoption for it, since most engineers won't be able to keep up with it.
I'll give it some proprs over the current mainstream stuff, which you have no idea how it works, at least there's some spec here.
Is there any advantage in using this method over HMAC with the key stored in the HSM, without pepper or salt? It seems overly complex to me but I'm not a cryptographer.
The main benefit of peppering is that if your password hashes are compromised (read: stolen) ... they can't be brute-forced. Password hashes such as argon2 make brute-force cracking more expensive, but nothing can help you all that much if the password is "letmein" or something quite high up on the guess list. With well implemented pepper there's just no way to even check one password, never mind brute-forcing.
If you go beyond peppering and also use encryption to protect the whole password database you can get additional benefits like keeping the list of usernames secret.