Tag Info

Hot answers tagged

63

The output of MD5 is binary: a sequence of 128 bits, commonly encoded as 16 bytes (technically, 16 octets, but let's use the common convention of bytes being octets). Humans don't read bits or bytes. They read characters. There are numerous code pages which tell how to encode characters as bytes, and, similarly, to decode bytes into characters. For almost ...


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 ...


5

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 ...


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, ...


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

[Disclosure: I work for AgileBits, the makers of 1Password] I may have my history wrong here, but I believe that KeePass is designed to work with PasswordSafe databases, and that PasswordSafe was designed prior to general adoption of PBKDF2. So what we are seeing here is a "home grown" approach to do the job that PBKDF2 was designed to do. (And of course ...


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 ...


2

As the SHA-3 page on Wikipedia illustrates, there are currently no known attacks for the SHA-3 hash function that result in a cryptographic break. The first cryptographic break for the GOST hash function was published in 2008. See cryptanalysis for more information. The first cryptanalysis on a reduced version of the WHIRLPOOL hash function (number of ...


2

It all boils down to how compromised your system is. If attacker is able to only put/replace your dlls with malicious ones - probably some sort of digital signature will help to filter our untrusted dlls. If attacker controls system enough to replace not only dlls, but also your executable - he can modify code which verifies signature, defeating your ...


1

What KeePass does appears to be a custom password hashing, using AES encryption as part of the process. The AES key here plays the role of a salt. The salt is a non-secret parameter which selects the actual function used to process the input password (i.e. there is not one hash function, but a whole family, and the salt tells you which one is to be used). ...


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 ...



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