Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

DNS as a password manager is kind of an own-goal, as you give the attacker the means to mount an offline attack against your encrypted passwords at the outset. They can simply retrieve the encrypted blobs over the network, and begin.

Putting that aside, as instantiated by the author, there are some problems with the encryption methodology:

1. CBC doesn't provide integrity

There's no guarantee given to you by the construction that the password you (successfully!) decrypted is the same password you encrypted. If you're symmetrically encrypting anything nowadays, you should be using some form of authenticated encryption.

2. `openssl enc`'s -pbkdf2 flag defaults to 10k iterations, which is off by more than an order of magnitude by today's standards for a comparable use case(protecting password vaults).

3. using PBKDF2 in the first place.

There are more modern KDFs nowadays(scrypt, argon2) that are resistant to more kinds of attacks[0] that should probably be used instead.

4. using `openssl enc` in the first place.

OpenSSL has always cautioned against using the `enc` command for anything serious, so I feel obligated to mention it.

Sorry if this seems like I'm talking out of school, but in case any one reading was inspired to use this methodology for encrypting their own passwords, I wanted to give a proper accounting of what I think the limitations are.

Off topic: is this guy a Drake fan?

[0]: https://en.wikipedia.org/wiki/Custom_hardware_attack




> 4. using `openssl enc` in the first place.

> OpenSSL has always cautioned against using the `enc` command for anything serious, so I feel obligated to mention it.

Can you talk more about this? I can't find anything in the OpenSSL wiki and my searching skills haven't revealed much except about the possibility of the ciphertext being modified when using AES-256-CBC.


I had thought it used to be all over the manpages for the openssl command, but I can't seem to locate it now. It's my understanding that the openssl command line tool wasn't(and isn't) designed for serious production cryptographic use. It was developed as a way to test the functionality of the library, not as a robust way to encrypt files/data on the command line.


>1. CBC doesn't provide integrity

Is this a serious issue for this use case? If the attacker tries to tamper with the ciphertext, chances are it will cause the decrypted plaintext to be gibberish with many invalid/unprintable ascii characters. That should alert the user that something's up.


> chances are it will cause the decrypted plaintext to be gibberish with many invalid/unprintable ascii characters.

Not necessarily. If the plaintext you're trying to modify is in the first ciphertext block(which in this scenario is likely the case), you can modify a byte in the IV(assuming the IV is stored alongside the ciphertext) to modify the corresponding byte in the first plaintext block without a trace.

> Is this a serious issue for this use case?

In my opinion this whole use case is an issue. Why give an attacker access to your encrypted passwords?


>you can modify a byte in the IV(assuming the IV is stored alongside the ciphertext) to modify the corresponding byte in the first plaintext block without a trace.

So with this vulnerability, the attacker can... cause you to enter a wrong password. That's kinda annoying, but at the end of the day it's a DoS attack, and even though using AEAD ciphers would prevent this specific attack, it won't prevent other DoS attacks (eg. blocking/mangling all DNS traffic).


Indeed, we're kind of lost in the weeds here. The real question is...why do this in the first place? It isn't a good idea.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: