Tag Info

Hot answers tagged

9

When you hash the password the first time (when the user registers), you use a salt and store both the salt and the resulting hash in the database. The second time (when they try to log in again), you use your username to pull the salt and the hash out of the database. You use the salt to hash their password input, and compare the two hashes. You may be ...


8

No, I don't think this is true. News coverage gets this wrong all of the time, probably because its not an easy topic for an outsider. It all starts with the term encryption. If you are really encrypting a password, you are most probably doing something wrong. Passwords in the context we are talking about are used for authentication. There is absolutely no ...


6

Hash functions with a configurable output length exist, but we don't really call them "hash functions". We have Key Derivation Functions. Also, some hash function designs naturally allow for a configurable output length, in particular Sponge functions, a prime example behind Keccak, the soon-to-be SHA-3 standard. Indeed, NIST is currently drafting the ...


6

I think this question was already discussed here and the answer was like that it is actually possible, as examples like Skein and Keccak show. They participated at SHA3-Competition in 2012, particularly the so called NIST hash function competition. Skimming the functionality of the winner of this competition, the currently representative of the SHA-3 ...


4

The password is padded with null bytes: extra bytes of value 0x00 are appended so that the total length is exactly 14 bytes. See this, item 4. Of course, LM hash is a very poor password hashing algorithm. Don't use it (if you have the choice).


4

Ideally, we should do most (but not all !) of the hashing on the client side. The overall need for password hashing, with all the involved iterations and salts (see this answer), is to make sure that the value which is stored (the "password verification token") cannot easily be used for an offline dictionary attack (the attacker tries potential password, ...


4

Don't roll your own crypto. Generally, if you are directly calling (as opposed to specifying the name of) some crypto primitive (SHA-512, AES, etc), then you are violating this rule. If you think crypto implementation bugs are not hard to avoid, I suggest you give Matasano's crypto challenges a try. Fewer lines of your code. This means fewer chances of you ...


4

First, there's Kerckhoffs's principle which is always desirable: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge. where in this case the password is the key. So its not a goal to keep the cryptosystem secret. Second, you are wrong about those being md5 or sha512 hashes; the values stored in ...


3

Most antivirus will try to protect processes from code injection. However, this is ultimately heuristic: the only clear distinction between malicious code injection, and normal process behaviour, is at the human level: did the human user actually wanted that to happen, or not. Software in general, AV in particular, cannot fathom the intricate psychological ...


3

The salt is stored with the hash, for example in a separate database field or it is tagged onto the end of the hash or the username is used as the salt. The purpose is so that even if two users have the same password, their salts will be different and therefor their hashes will not be the same. This is useful if someone manages to steal the database, they ...


2

There some things in that linked article that are true and useful. But identifying those parts from the things that are erroneous and misleading is something that can only be done by someone who doesn't need the advice in the first place. As @user1201232 correctly pointed out, there are some (ancient) systems that only use the first eight bytes of a ...


2

This claim is nonsensical. The most common practice by far is to take an MD5 hash (or, increasingly, something else like a SHA hash), with a salt. The salt is a random string added to the plaintext password before it is hashed, and stored with the lot; it serves to make it hard to compute tables of all possible hashed passwords since this must then be done ...


2

I have seen sites that allows long passwords, but only uses the first X characthers, then create a hash with a salt from those X characters... leaving the last Y characters not used, and efectively could be anything. for example your passwor would be mylongandboringpassword with the X set to 8 the actually stored password (and all you would need to ...


2

Passwords should be hashed at least once on the server, to prevent pass-the-hash style attacks where a malicious attacker can simply inject the hash he sniffed from the network to authenticate. This doesn't however mean that you shouldn't hash the password locally as well. A fairly paranoid strategy is to have the user submit an iterated hash of a password, ...


2

The user always submits the actual password to the server and the server stores the salt and hash values. The point of a salt is simply to make sure that if the DB is compromised, an attacker can't try brute forcing all the passwords at once. It also prevents identifying reused passwords. It doesn't matter if the salt becomes public knowledge because it ...


2

There are a lot of ways to look at security questions, and rarely a "right" answer. In this case, you might want to start by listing out what the basic goal(s) of the cryptosystem is/are; i.e., "what's the point?". From there, you can consider what is not being fulfilled if the hash doesn't match. In this case, you're looking at a system that works by ...


2

Short answer: this is the link you're probably looking for (-s specifies SSID). Longer answer: Precomputed 'hash' files are used to accelerate password bruteforce when cracking WPA. They do this by eliminating the need to perform costly transformation of a password into an encryption key; instead somebody already computed such keys for common SSIDs and ...


2

Obscuring which hash is used makes it impossible for the system to authenticate the password for a legitimate user. When password authentication via hashing in Unix was first invented, the password hash function was hard coded to use DES (now badly out of date). If the password hash is derived by any other function, there must be an identifier to allow the ...


2

There' a pretty good Microsoft KB article on this exact subject. Basically, LM is used for compatibility with older clients. Specifically, Windows 98 and below. If you do not have any older clients on the network, then the cause for both hashes is most likely due to the password length being <15 characters. When you set or change the password for a ...


1

Cryptographic hashes are in principle not reversible. So it should not be possible to get the salt by taking a known query string and associated hash (or a set of them) and reversing them, other than by trying brute-force. Brute-force is not going to be feasible with a random GUID that's has 32 hex-characters (one hex character is 4-bit, hence the GUID is ...


1

Attempting to obscure the hash implementation is really just moving the problem, from I can see by protocol the hash function is X() to Looking at the code**, I can tell the hash function is X() ** (or other side channel of information) If your attacker has any way to probe the system they will almost certainly be able to figure out the algorithm ...


1

See Comparison of SHA functions on Wikipedia. As the table shows, a theoretical collision attack with an estimated complexity of ~2^69 exists for SHA-1. See Marc Stevens' presentation for reference. Since you're concerned about collisions I recommend using SHA-2 instead. You can choose any of the variants, but I suggest you pick one that meets your security ...


1

The following links may provide you with an in-depth answer: REST security standards I just send username and password over https. Is this ok? http://stackoverflow.com/questions/3461298/password-hashing-non-ssl Please keep in mind that it is better to not use the username-password combination in every request that you make. Better is to authenticate the ...


1

This is a flawed system if its meant to ensure data wasn't tampered by a malicious attacker. Any attacker who can tamper with the transmission of the file (or the file on the FTP site), could have similarly tampered with the transmission of the md5sum (or the storage of the md5sum on the site) and changed it to something that corresponds to the tampered ...


1

I would advise against implementing this yourself. If you disagree, have a look at the current existing AES implementations; many libraries are available and it's likely that these will suit your needs. Have a look at Turning a cipher into a hashing function and Description of the AES cipher on Wikipedia if you're interested how the algorithm works.


1

Collisions are irrelevant to most usages of hash functions in conjunction with passwords. For password hashing, preimage resistance is important, not collision resistance. MD5's resistance to preimages is (almost) as good as new. MD5 for password storage would be a poor choice "alone", though, because password hashing requires salts and slowness, both ...


1

So long as your token is sufficiently long enough, I think you would be OK using simply SHA256. I'm not very familiar with PHP, but it looks like you are creating tokens of length 200, which would be more than sufficient. The reason that I would think that SHA256 would be OK is that the search space for a length token is so gigantic that it doesn't really ...


1

Well, first of, hashing does not actually help in encryption (strictly speaking, it can, with OAEP padding, but I strongly doubt that applies to your case). I suppose that what you call "encryption" is actually a digital signature. Digital signatures are unfortunately often described as "encryption with the private key", which is a flawed analogy, since it ...


1

You cannot, by looking at a hashed sequence, determine what kind of hash did generate it. If you could, that would strongly hint at a non-randomness - even worse, recognizability - of the hash, which would make it less useful for security purposes. You can however tell between a SHA-1 or SHA-2 hashed value from its length. SHA-1 is 160 bits (20 bytes) in ...


1

Great answers so far, but something that I think should also be mentioned because its not very clear from the article you referenced. The hashing function is run against the salt concatenated along with the password and then the salt is concatenated again with the resulting hash from the function and that string is what is stored in the password database ...



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