New answers tagged

1

[Note: This question has been re-posted on crypto.SE.] Let's break down the problem into two parts: The first problem is that you want something that looks random to an outside attacker (ie is unpredictable), but can be computed by anybody in the know. That sounds a lot like a Cryptographically secure pseudorandom number generator (CPRNG) where all nodes ...


1

Can this scheme be extended to work with hashed passwords somehow? Not this scheme. Because of how it works it needs to have the password or some specific equivalent (see http://stackoverflow.com/questions/1000281/storing-password-in-tables-and-digest-authentication for details) to do some necessary computations. Of course with a naive approach you ...


3

Am I right to say that this won't work if the password is not stored in plain text on the server? I fail to see how the server could verify the hash if the password is already hashed (with salt and pepper) on the server. This scheme does require the password to be stored in clear-text. Very bad. Can this scheme be extended to work with hashed ...


1

If you're using a secure channel namely TLS, you don't need to do these sort of tricks. About your first question, yes you're right, this scheme requires the server to have access to password in clear text to be able to reproduce H(nonce+cnonce+password). About your second question, I can't think of a way that won't open you up for replay attacks.(but I'm ...


1

Although in your case the IV should be okay in plaintext in the DB, there is a severe vulnerability if you allow the user to control the IV. The IV in decryption is used (and only used) to XOR the first block into the final plaintext - so if an attacker can control the IV they can arbitrarily control the first block of data, and the rest of the plaintext ...



Top 50 recent answers are included