New answers tagged

2

No, wrapping the data key set seems a good idea to me. It's pretty standard and should even work with e.g. hardware modules. Note that your old ciphertext would still rely on the security of your old secret (password) when you choose this scheme! If $Enckey$ is ever guessed it can be confirmed by decrypting (the first part of) your ciphertext. There is a ...


0

Quoting “Exam Ref 70-486 Developing ASP.NET MVC 4 Web Applications (MCSD): Developing ASP.NET MVC 4 Web Applications” by William Penberthy, Pearson Education, 15 Sep 2013: Salting is a process that strengthens file encryption and hashes, making them more difficult to break. Salting adds a random string to the beginning or end of the input text prior to ...


2

"I'm using [AES] in CBC mode, but the implementation doesn't add the randomness I want, the same message when encrypted looks the same." This is a problem. If you were using CBC mode correctly (i.e. with a random IV), then encrypting the same message twice would produce completely different ciphertext. Since you're not using CBC mode in the way it's ...


0

It all depends on your restriction of length of initial password. If your user is able to enter password of just 4 characters, then doing SHA1 etc is not going to add any entropy (in simple words the brute force space for the attacker is not going to increase). Assuming attacker can check One million password per second then below is a summary for your ...


3

For example, someone suggested improving UNIX authentication by defining 3 different passwords for a user that are stored in the shadow file. All three passwords are stored with the same salt value. When a user wants to authenticate to some system, he must provide in the i attempt to login, the i mod 3 password. For example, in the first attempt he will ...



Top 50 recent answers are included