Tag Info

Hot answers tagged

38

The goal isn't to make the hash slow for you to compute. The goal is to make the hash slow for an attacker to compute. An attacker with fast hardware and a copy of the hash and salt, giving him the ability to mount an offline attack, to be specific. The attacker need not pause a thread during his computations just because you added that to your software. He ...


29

No. The constants are part of what make the hash secure, and the constants in the specifications are what have been used in the cryptographic community's examinations of the hash functions that we currently believe are safe. It has been shown that intentionally badly chosen constants can break a hash function in subtle but exploitable ways, and coming up ...


25

You are basically right; this is poor practice, for several reasons: As you note, it requires server-side storage of the password as plaintext or in some reversible format. Typing a password repeatedly works on "muscle memory", which allows the user to "remember" his password as a sequence of gestures on the keyboard; asking for specific letters exercises ...


16

Don't do it. Salts have to be unique, that's their only requirement. But your approach doesn't generate unique salts, but password-dependent ones. A per-db-unique salt helps when its long enough (256 bits), and you also hash in the username, but that still leaves issues. Having only 3 iterations of SHA256 is rather not the way password hashes should be, ...


12

I personally prefer Google Authenticator which is basically an elegant implementation of Time-Based One-Time Password Algorithm but I would not feel comfortable saying it “is more secure”. To use one of my favourite buzzwords… it all comes down to Threat Modelling. What exactly are you trying to protect against? Is it a technical attacker who might be able ...


10

The only issue is that you're leaking information, in this case, the user's email address. Since it's plaintext in the querystring, it's going to be stored by any logging that's occurring anywhere between the client and your server, potentially in bookmarks if the user bookmarks that page, if the URL is copied and stored or sent to anyone, etc. I'll ...


8

Cryptographic hash functions must have several properties: Resistance to preimages: given x, it should be infeasible to find m such that h(m) = x. Resistance to second-preimages: given m, it should be infeasible to find m' such that h(m) = h(m'). Resistance to collisions: it should be infeasible to find m and m' such that m ≠ m' and h(m) = h(m'). These ...


8

If they are indeed sending you a new password (i.e.: a system-generated password other than the one you previously had) when you click 'forgot my password' then no, that doesn't mean they're not hashing passwords. They can have their forgot password function generate a password, hash it and store it in their database, and then (while it's still in memory) ...


8

No, due to reasons you have already stated: Don't design your own algorithms. You can achieve resistance from rainbow tables by using unique salts, no need to mess with the constants of your hashing algorithm. The algorithms have been subject to thorough cryptoanalysis by international experts, like for NIST SP800-90 Dual Ec Prng, its likely you won't have ...


7

uniqid() should not be used for anything security related: This function does not create random nor unpredictable strings. This function must not be used for security purposes. Use a cryptographically secure random function/generator and cryptographically secure hash functions to create unpredictable secure IDs. Also, you should make your link a HTTPS ...


6

This attack is not about generating a modified SHA-1 that makes collisions easier, it's about generating a modified SHA-1 as part of the process of generating one specific collision. The modified hash function so produced is only useful for creating the single collision used in the generation process; it is no more vulnerable to collisions in general than ...


5

It's actually not a SHA1 hash in the CSR. It's a signature of the message. For simplicity, I'll assume we are talking about RSA certificates, where the public key is (N, e) (the modulus and public exponent which is typically 65537) and the private key is (N, d) (the modulus and the private exponent which can be easily calculated via Euclid's extended ...


4

The assessment of any strong 256 bit cryptographic hash as having a security level of either 128 or 256 bit depends entirely on how it is used. In an application where an attacker can succeed simply by finding any hash collision, the security level cannot exceed 128 bit since a simple birthday attack will (probabilistically) succeed after 2^128 random ...


4

By default, echo leaves a trailing newline. So you need to do: echo -n Hello | md5sum 8b1a9953c4611296a827abf8c47804d7


4

Short answer: don't do it. Salt should be used to provide some security against leaked hashed passwords, since the same password will have the same hash, when unsalted. If salt is predictable, there is no gain. Since you're not adding any entropy by doing that, there is no gain by doing that kind of thing. And since you're using a very small number of ...


3

it depends on how you plan to use the answers. If you expect to do strict automatic checking then treat them as passwords and apply key-derivation function such as bcrypt/scrypt. (But remember, that BCrypt uses only first 72 characters of string for the hash. is that enough for your case?) on the other hand, if there is a chance of phone-based support and ...


3

You're overcomplicating the solution, and not really gaining much out of it. Others have gone over the flaws with your implementation, but I'll outline a better approach. When a user chooses to have their authentication remembered across browser sessions, use a CSPRNG to generate a random 128-bit string. Send them this string, then hash it (SHA-2/256 is ...


3

Most cryptographic hash functions operate on a fixed-size internal state and process the message to be hashed block by block, where a block is a number of bits. MD5, SHA-1 and SHA-2 follow the Merkle-Damgård construction which operates as follows: Let S be an array of N bits, initialized to a predefined value. N is the size of the internal state and may be ...


3

I assume your question is: Can an attacker find pass15 more easily if they know both hasha and hashb than if they know only hashb? If that hash function is truly good it should have a good uniformity. That means that any input given to the function will be mapped to an output irrespective of how similar input is mapped. This means that knowing how ...


3

No. In the context of a hash, "bits of security" is a measure of how many possible outputs a hash function has, and thus, how hard it is to find an input with a given output. It's on a logarithmic scale, so each additional bit doubles the security. You can't compare the security of SHA-256, AES-128, and ECC-256. They're totally different things: SHA-256 ...


3

Yes, sort of. Ideally two values are stored. A unique salt, and a hash of the salt+password. A globally unique salt is generated and stored for each password. Again, sort of. First the salt for that user account is retrieved from the database, then the salt+password is hashed and compared to the hash value sotred in the database. No, because the salt ...


3

The term you're looking for is "hash rate", and a quick Google search indicates that a GPU-based password cracker can try on the order of 10^10 passwords per second when cracking MD5 hashes. Generating hashes is an example of an "embarrassingly parallel" process, so doubling the available computing resources will double your hash rate.


2

As @aviv pointed out, revealing to a user that some other user also has the same password is a problem. If you really intend to maintain such statistics, then you have another inherent problem: the "statistics engine" can only help any attacker, since it outputs a list of passwords that are in use. Even a reduced form which merely says "this password is ...


2

I dont think you want to do that at all... you will be giving hints about other user's passwords. If I get the message that 1 other user is using my password - now I have valuable information. I might even know or guess who that user is if I have some prior knowledge on him


2

I would highly recommend you look at redesigning your solution to be able to use a hash, rather than either work with anything other than a one-way hash. If you absolutely need to work with the cleartext password, it should be encrypted using a a high level library like NaCl (http://nacl.cr.yp.to/). Symmetric vs. public-key encryption will be a function ...


2

A shared password is a poor design for managing access to a private communication channel. For example, you can't kick a user out without closing the channel: you can't cause them to forget the password. You can't prevent a user from sharing the password with other users (voluntarily or involuntarily) — if a user's password is exposed, you can invalidate it, ...


2

(I worked for Google's Account team, specializing in Usable Security issues just like this one.) In authentication, there are three basic factors: "has a", "knows a", or "is a". The two systems under discussion are both "has a". In the case of LastPass, the user has a piece of paper. In the case of GAuthenticator, the user has a particular smartphone. As ...


2

On most UNIXoid operating systems, the openssl command line program should be available. It implements most of the hashes you mention. To use it just for hashing, pipe the output of echo -n to openssl dgst -[ALGORITHM]. To calculate the SHA1 hashsum of "Hello World", for example, use this: echo -n "Hello World" | openssl dgst -sha1 openssl dgst supports ...


2

Just because a UUID is highly likely to be unique doesn't mean that it's difficult to guess. Version 4 UUIDs contain 122 random bits, and I would recommend that or version 5 (SHA-1). Honestly, I usually use SHA256 or higher and a long string of concatenated random numbers. Then store the hashcode in both the database and a cookie. There isn't much benefit ...


2

What you describe is a witty password: a password which relies on the user knowing some specific generation method. This is bad. Witty passwords are not secure passwords; they more are quite the opposite. When you use a "witty password", you rely on the attacker being less smart than you. Self-confidence notwithstanding, this always fails. Attackers know ...



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