Tag Info

Hot answers tagged

27

It is not a problem if the attacker learns the salts. Salts are not meant to be secret. What is important for a salt is that it is unique for each hashed password instance (i.e. not only a unique salt per user, but the user's salt must be changed when the user changes his password). If you think of your salt as something that may be shared between ...


7

How about you take his challenge? Go make a quick rainbow table of common passwords and run it over his database. You're bound to hit something (especially if he doesn't have a password policy). However, this may not work if he has a small database.


5

Well, we will probably never be completely sure as we don't have the code. But we can discuss some possibilities. But first, Why the change, actually? What could be a reason for this change anyway? A possibility is that intelligence agencies had something to do with this, like is assumed to have happened with an older version of A5/1, Comp128v2, where the ...


5

If someone were to get a hold of this database and try cracking the passwords, would allowing these additional combinations significantly reduce password strength? I would argue that it would not in this specific situation. I highly doubt that they are storing three forms of the hashed password in the database, but rather hashing three different ...


5

Even if he was using a salt, it would still be a terrible plan. SHA-512 is a fast hash, so you don't need rainbow tables in order to find passwords, simply testing inputs along with the salt can be done at the rate of hundreds of millions to billions of candidate passwords tested per second. What your friend should do, is read the answers to How to ...


5

My answer is going to differ than everyone else. Tom Leek, and Xander provided good insight, so here goes my response to your initial question, expanding from this comment of yours: "I don't want to store the salt in a database that could be compromised - that defeats the purpose of salting, doesn't it?" Yes, and no. If someone compromised your ...


4

HTTPS is more than security enough to send and receive information, don't start implementing your own security as HTTPS will take care of it for you. It provides: Confidentiality Integrity Authenticity The biggest caveat when writing mobile applications is to verify the the behavior of your application when it receives a certificate exception. With ...


4

It would add complexity without adding much value. It does not defeat the purpose of salting, as you feat, because a salt is not intended to be secret, just unique. The goal is not to make it impossible to figure out the password from the hash, but to make it impossible to pre-compute hashes that can then be directly compared with yours to see if any ...


3

It's not necessary. Think about it this way... If your server has access to the salts and an attacker gets root on your server, he would get access to your "remotely stored salts" wherever they were located as well. Since you're using PHP, check out the password_hash and password_verify functions.


3

Extra information can only help the attacker; but that extra help might be negligible. If we model the hash function as a random oracle, then showing h(P+B) for a given non-empty string B does not yield extra information useful for the attacker (I take "+" to mean here string concatenation, not numerical addition). A "random oracle" is (in rough terms) a ...


3

The primary characteristic of a salt is that it should be globally unique for each user's password hash. It need not be secret, and a username will certainly not meet the required criteria of uniqueness. A shared secret string (used for all users) is not a salt, but a pepper, and has not been demonstrated to add any security over unsalted passwords, and so ...


3

Currently windows uses NTLMv2 to store the password, but for backward compatibility some system uses LM hashes. Now it is recommended by the Microsoft to not to use LM method to store the password because of its weakness towards brute force attacks. If you want to see currently which method is used then you have to navigate to ...


3

No. MD5 and SHA1 are largely unrelated. Knowledge about one does not confer any knowledge about the other.


2

The answer to this question depends on two factors: the attack vector the implementation of allowing different passwords Websites should store passwords not in plain-text or any other form allowing to get the password from the saved value. Therefore usually a irreversible hash-function is used, so that only the hashes of the passwords are compared. Now ...


2

I'm slightly confused by the construction of your question, but should still be able to shed some light on the subject in any case. First, I'm going to assume that when you say P+B you intended to mean that P and B are going to be concatenated, rather than that addition in some form is being preformed, and I'll denoted this below with the || notation ...


2

Your first link says what the source is: This list is from files containing stolen passwords posted online during the previous year. In a perfect world this would not happen. Not only would everyone salt and hash their passwords with an expensive algorithm, security would also be good enough that password lists won't get stolen. Unfortunately the world ...


2

No, don't do that. First: salts are not secret. They are used to make sure that reversing the hash for one password does not reveals all the copies of that password on your database. It is used to make reversing the hash more difficult. Second: it will increase latency. Your authentication system will have to get the username and the password from the ...


2

This is not a hash. You always have a base64 encoded data (the one that ends with '==') and the hex value of the decoded data. I am not sure what type of data this is, but I am almost sure that it is binary data. AAAAAATOM2KIII+kbR/Dqw3TLTw4PHsGPZft2c+b93rImFIuAQ== 0000000004CE336288208FA46D1FC3AB0DD32D3C383C7B063D97EDD9CF9BF77AC898522E01 ...


1

Truncating a well designed cryptographic hash digest should not result any security weaknesses other than a reduction in the collision space. As these hash algorithms have a key design requirement of being uniformly distributed across the hash space. All other things equal, using a more modern hash algorithm (SHA) and truncating it is safer than using an ...


1

"Pass the Hash" is a combined weakness of windows and NTLM, which can be exploited in a corporate environment if one administrator account with the same password is used for multiple computers, to gain access to all of those computers. From the Wikipedia NTLM article: The NTLM protocol uses one or both of two hashed password values, both of which are ...


1

While "reputable" websites may do this, there are just as many that do not securely store them and get compromised. Compromised password databases are available, and if you acquire them, you can construct such a list as the one that SplashData has constructed.


1

Collision resistance is about the infeasibility of finding two distinct inputs m and m' such that h(m) = h(m'). The attacker gets to choose m and m' arbitrarily, as long as he ends up with two distinct messages that hash to the same value. Second-preimage resistance is very similar except that the attacker does not get to choose m. Instead, we give him m, ...


1

We are talking about the database of a bank, and that's not your average database. It's a special kind of database, when every step is audited, every alteration is logged. So a database leak is very, very unlikely. If someone can get access to the bank database, why bother with PIN or password for any user? They can go direct to the money. The reason to ...


1

The scheme you describe is commonly used to ensure that a link is current, so if someone's changed the content, no other references to it will continue to work. Generating a new GUID upon reboot guards against someone making database changes while the server is down, ensuring old links are invalidated. This scheme has almost nothing to do with security, ...


1

"Is is necessary to encrypt the message digest?" and "Is it necessary to encrypt the hash of the message?" Yes, since otherwise: An eavesdropper could determine, with overwhelming accuracy, which pairs of [core ciphertext + hash] pairs are for the same message. (The following three sentences wouldn't apply if you used a MAC instead of a hash.) An ...



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