Ultra Secure Password Storage with NitroPepper | Hacker News Reader

Ultra Secure Password Storage with NitroPepper

sentiatechblog.com

32 pointsarkadiyt16 comments

> 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?

Probably short for "infrastructure playboy", I suspect they're thinking of the sort of person who tries to make a text editor starting from a k8s cluster out of containers running in VMs on AWS.

Love your definition. This goes to urban dictionary :-)

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...

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.

Only assuming the attacker doesn't get the "pepper". Since the password hashes should be kept securely, if you've got a way to keep the attacker from getting to the pepper you should just store the hashes there instead.

It can be useful as a "defense in depth" thing, but it's not a particularly meaningful improvement to practical security.

In general, the benefit of encryption is 1/ defense in depth by requiring an additional secret and 2/ the reduced size of that secret you have to protect. E.g. you can protect a 2GB top secret data trove with a 128-bit AES key. The same applies here, and it can be cheaper/easier/more-effective to lock an encryption key away in an enclave than the whole thing.

Except that they're talking about per-user pepper, so 16 bytes per user, in addition to the hash & salt. It's not a sensible tradeoff.

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.

Reply on news.ycombinator.com