# Tag Info

73

The reason that salts are used is that people tend to choose the same passwords, and not at all randomly. Many used passwords out there are short real words, to make it easy to remember, but this also enables for an attack. As you may know, passwords are generally not stored in cleartext, but rather hashed. If you are unsure of the purpose of a hash-...

49

Entropy is a measure of what the password could have been so it does not really relate to the password itself, but to the selection process. We define the entropy as the value $S$ such the best guessing attack will require, on average, $S/2$ guesses. "Average" here is an important word. We assume that the "best attacker" knows all about what passwords are ...

49

For password-hashing, you should not use a normal cryptographic hash, but something made specially to protect passwords, like bcrypt. See How to safely store a password for details (this article advocates the use of bcrypt). The important point is that password crackers don't have to bruteforce the hash output space ($2^{160}$ for SHA-1), but only the ...

21

(Converted to answer from a comment.) If pen and paper are permitted, one could probably carry out the RC4 algorithm fairly easily using 256 numbered pieces of paper (small post-it notes might be ideal, since they'd be harder to move by accident) arranged in a 16 by 16 grid (I'd suggest numbering the notes in hex for easier indexing), with two coins or ...

18

The XOR is indeed meant as a protection against hypothetical short cycles. For a given password $P$, the sequence of $U_i$ should make a "rho" structure: at some point in the sequence, a cycle is entered. For a $n$-bit hash function and random password, on average, there will be a single "big" cycle of size about $2^{n/2}$ and for almost all possible salt ...

18

A few observations: RC4 suffers from related key attacks. This means your idea of concatenating a 224 bit key and a 32 bit IV is not a good idea. You should rather use $\operatorname{SHA-256}(Key||IV)$ Remember that a (Key, IV) pair must not be reused, ever. A 32 bit IV can work if it's a counter, but IMO such a scheme is unnecessarily fragile. I'd rather ...

17

The emerging consensus seems to be that the "crypto.se" site is best suited for more theoretical questions, while more practical questions like this which really turn on the question of risk management are more suited for the broader audience at http://security.stackexchange.com/ I recommend looking at the many password-hashing-related questions there, e.g. ...

17

I can think of 2 cryptographic systems. One that can be done with a deck of cards is a scheme called Pontifex (aka solitaire) that was developed for the book Cryptonomicon. Some more technical details and example of it in use at Bruce Schneier's website. Although it should be noted that some weaknesses have been discovered in Pontifex . Another one, ...

16

To the best of my knowledge there is no formal distinction, since "password hashes" aren't formally defined. That said, if you look at this presentation from the author of scrypt you'll see that he wanted: Password hashing to be CPU hard (i.e. to require significant amounts of CPU processing, in a manner that cannot be optimized away). Password hashing to ...

16

"In my system, there are no user names, only passwords." This is the real problem. Using the same value for both identification and authorization is usually a bad idea, for several reasons: Two accounts cannot have the same password. An on-line attacker needs only a single query to determine if any password in the system matches their guess; thus, they ...

15

There exists something which is one step further than your idea. Look up SRP: this is a Password-Authenticated Key Exchange protocol; the two parties (client and server) who run the protocol end up with a newly generated shared key (which can be used to derive encryption and integrity-check keys), with mutual authentication with regards to a shared ...

15

Layering encryption doesn't effectively concatenate the keys (despite what intuition may suggest). The attacker can still attack the two passwords separately, such as by using a meet-in-the-middle attack. This means the effective key space (that is, the number of possibilities for the combined password that the attacker must try) is much lower for the double-...

13

The overall idea is a sound migration strategy. The nice thing is that security for all users is upgraded in a one-shot operation, rather than at the hypothetic next login of each user. Of course, original salt and new_secure_salt shall be stored, or perhaps for some portion derivable exactly from material keyed-in by the user, e.g. user name lowercased. ...

13

Multiple hashing, in itself, is not a bad idea. What's bad is trying to design your own non-standard password hashing scheme, without understanding what features such a scheme needs in order to be secure. In fact, hashing the password many times can be a very good idea, as long as you do it sufficiently many times. This is one way to slow down the hashing ...

13

There are a number of considerations here, I'll try to lay them out one at a time for ease of following: What must the site do with the data? Oftentimes, we ask web sites to do things on our behalf when we are not actually visiting them. For example, I may want crypto.SE to email me when there are responses to this post. The site could not do that ...

12

If k is a constant, such as 3, it becomes possible to select a pair (N,g) such that the discrete log of k to the base g is known, which would enable the two-for-one guessing attack again.

12

Short answer: don't. Use a password hash like PBKDF2, scrypt or bcrypt. Also, if at all possible, use a library that takes care of the low level stuff like password database for you. E.g. passlib might work if you use Python. I'm sorry if that sounds blunt, but that's how it is. To answer your actual questions: There is just only one thing which ...

12

Using several different encryption algorithms, and not disclosing which is used in each particular case would require password verification to try all possible algorithms. Feasible only when using just a few algorithms. Truecrypt does this, for example. This could strengthen security, when implemented properly - but it is much more difficult to implement. ...

12

I know that humans would find it impossible to maintain a 128 bit password -- however, I wonder if there is some technical reason why a 52 bit password would not be as weak as a 52-bit encryption key for that matter. First, I would argue that 128 bits is not impossible to remember. My current password manager master password is almost 100 bits (6 words ...

11

OpenPGP's "Iterated and Salted S2K" is just a single hash instance over a very long input, which consists in the repeated concatenation of the salt and the password. This is extremely GPU-friendly, especially when using a hash function which is built over 32-bit elementary operations (this category includes MD5, SHA-1, SHA-256 and RIPEMD-160; GPU are not as ...

11

No, it's not safe to seed a PRNG with the hash of a password, then generate a key from that PRNG. That is especially bad with DSA and shared parameters $(p,q,g)$, and only slightly less unsafe for RSA, or DSA with per-key parameters $(p,q,g)$. Two essentials things are missing: some slow step, and salt. If the proposed procedure was applied, all there is to ...

11

Using encryption in a non-standard way very often results in decreased security, and not in the information-theoretical sense. Consider: you will have two different passwords. You have twice the difficulty in managing them. Twice the chances of losing them. Twice the chances someone will screw up trying to follow your complicated directions. I also assume ...

11

The usual answer is that a salt can be make public; if that was a problem, then the salt would not be called a "salt" but a "key". In some protocols, unauthenticated obtention of the salt is the norm, and is not considered to be a problem. E.g. with SRP, a password-authenticated key exchange, where any salting and hashing must necessarily occur client-side. ...

10

Short summary: Don't do it, use an established password hash function like bcrypt, scrypt or PBKDF2. Long form: What you are doing here in effect is this: Create a combined hash algorithm out of several different hash algorithms (or block ciphers made into hash functions). Use a salt input to the combined algorithm to decide which of these algorithms ...

10

GPG's (or OpenPGP's) public-key file encryption uses multiple steps: Generate a random session key encrypt the file using this random session key encrypt the random session key using the public key of the receiver (or using multiple keys in parallel, if the file is meant to be decrypted by multiple receivers). store the encrypted file together with the ...

10

The short answer is: technically, no. The weaknesses of MD5 are not an issue here. However MD5 is seriously inappropriate, for it is the wrong king of security primitive; also its reputation is tarnished. If a collision attack was to be feared, then using MD5 would be a disaster, for it is now hopelessly broken w.r.t. to collision resistance; but that does ...

10

No, RC4 is not completely broken. It is possible to use it properly. It's just not very likely that an average developer will do so. RC4 is not a good choice for new systems. It is tricky to use properly. There are some serious pitfalls which, if you're not an expert cryptographer, can bite you in the butt. In fact, if you take a quick look in the ...

9

password = sha1 ( mainPassword . domainName . number ) Is this secure enough? Answer is no. Let me explain. The only part that is really unknown in the above is mainPassword. The rest can easily be guessed by a hacker. If your original password is weak (not many characters, no digits, no specials characters), the number of combinations to test is small ...

9

Well, the reason we add salt when hashing passwords is not to make a single hashed password stronger (it doesn't, except in a way I'll explain below), it's to fix up some weaknesses that appear when you have a collection of hashed passwords. If the attacker somehow gets a single hashed password, then adding a salt doesn't really slow the attacker down (...

Only top voted, non community-wiki answers of a minimum length are eligible