Tag Info

Hot answers tagged

33

It is possible that the service not only computed the hash of the full password when it was created, but also hashed the 3rd and 7th character (or possibly every character) individually. That way, they technically wouldn't be storing the characters or the full password in plaintext. However this would be a terrible idea. A hash of a single character is ...


19

What's the point of stealing hashed passwords? Let's say I steal a hashed password, I can take a random string, hash it, and see if the hashes match. If they do then I've just cracked your password. For example, assume that under some hash function we get the following hash table: "cat" --> AA "dog" --> AB "elephant" --> AC ... If I steal a ...


17

If you can verify the password by character, it significantly reduces the effective strength of the password. Rather than being exponentially stronger for each character it would only be incrementally stronger. For example, say I have a password four characters long that is "ABCD". If I have to know the entire password to get it right, the possible ...


14

First, you misread the page: this is not about collisions. The Wikipedia page says: the cost of finding a set of CGA Parameters that yield the desired 59 bits is approximately O(259) The important word here is "desired". The attacker wants to find an input that hashes to a specific, given output. This is called a preimage attack. By contrast, a ...


9

Salt doesn't have to be secret. However, it MUST be unique for each password. Consider this : if all your passwords are hashed with the same salt, then an attacker who gets access to your database "only" has to compute H(pwd+salt) for each possible pwd value and he gets all your passwords. If the salt is unique however, the same operation will only get him ...


8

Any authentication which asks the user for details about the password indicates that the plaintext password is available to the system. This means they are unhashed, but may still be encrypted and protected by other means. There are no techniques to verify the subset of a hashed password against the whole of the hashed password. This is actually one of the ...


7

The login credentials were found in password dumps from other sites. They were credentials where the username was a .gov email address. The concern is that people tend to reuse passwords and the passwords used on these sites are the password for their government login credentials. Either the passwords were stored in plaintext or the hashed passwords were ...


6

A salt does not make brute-forcing a single password any harder, as you correctly pointed out. Without a salt, an attacker could build one single rainbow-table, and (s)he would get all passwords at once. With a salt, the attacker has to build a rainbow-table for exactly this salt, so he cannot reuse already existing rainbow-tables. When you use a different ...


5

I am kinda confused about what you are trying to achieve with this rather complicated and error-prone protocol. If I understand your idea correctly, you are basically just moving the problem of integrity onto the communications with the "hash server". If someone was able to MITM both Alice's and Bob's in- and outbound traffic, they could mess with Alice's ...


5

What you're talking about is known as the pigeonhole principle - if you have n possible passwords and a hash function with m possible outputs, where n > m, there will always be some input values which produce the same output hashes. The question then becomes: does this matter? With a hash output space of 2160 possible values, an accidental collision has a ...


4

My first instinct is that it's some homebrew algorithm. It might be online somewhere, but there are a million of these homebrew algorithms. It's unlikely you could find it if it's something obscure, though you can try a few top google hits just to see. Another idea is that it's encrypted and stored with some weird encoding (since I see letters but it's not ...


4

As previous answers have already stated, there is no known technique to carry out a partial hash of a password and verify the string. The nature of unidirectional hash functions makes it impossible to verify if a password is similar to another, only that the passwords are identical. Therefore, it would imply that the bank has stored the passwords either ...


4

Doesn't look like a hash to me, and its labeled "scrambled". That would lead me to think this is a simple substitution cipher. Do you control this value? i.e. can you try entering in a longer password to see what the result is? When I've come across this in the past and I've controlled the value, I've entered the same letter multiple times, i.e "aaaaaaaa", ...


4

Hashing the password with a salt makes it much harder for an attacker to use a precomputed list of hashes (aka rainbow tables) to run the discovered hash against. It will force him to compute the hashes again for any salted password hash he wants to crack.


4

The problem you are asking about is called the Socialist Millionaire problem and has been discussed in research before; as far as I know there is a protocol to do this comparison without disclosing any of the two secrets and without involvement of a third party. I will edit my answer with a full explanation as soon as possible.


4

Yes there is a security issue. You stand the risk of inadvertently leaking the length of the passwords using this approach. An attacker could abuse this to determine the length of a password using a form of timing attack. Since calculating the hash is computationally more expensive than comparing the length of the provided password with the stored length ...


4

I'd be happy to explain my comments further :-) Unfortunately it's not a simple explanation. For a bcrypt-hashed password, how much of an advantage would this give the attacker? Can this be quantified? Quantifying this will be hard since guessing at the runtime of an algorithm is tough, especially if the attacker is allowed to make specialized chips ...


4

For password-based encryption, you need to: transform the password into a key suitable for the encryption algorithm (a process called key derivation); use that key to encrypt the file. Assuming that everything about the encryption phase was done properly, and the used algorithm is not weak, then the most direct attack route is the password: the attacker ...


3

As with any question of "is X secure" the answer will, to some extent, be "that depends on your exact requirements from a security standpoint, the threats you face, the type of application and the environment that you'll deploy in" However with that caveat out of the way, I'd say that the scheme outlined above sounds relatively reasonable from a security ...


3

If that was produced by crypt(3) then it is an MD5 hash. If salt is a character string starting with the characters "$id$" followed by a string terminated by "$": $id$salt$encrypted then instead of using the DES machine, id identifies the encryption method used and this then determines how the rest of the password string is ...


3

Seems that partial password need not be stored in plaintext-equivalent way. This scheme, based on Shamir secret sharing scheme might be useful: http://www.smartarchitects.co.uk/news/9/15/Partial-Passwords---How.html A. Global Parameters At the beginning, someone has to define global parameters of the system. Well, there is actually just one - how ...


3

This sounds like the perfect use of an HMAC. You create a secure random secret S. Then the ticket for each page will be ID + HMAC(S, ID). When you get a ticket you extract the ID, redo the HMAC and then compare your result with that in the ticket. While this is likely be simpler and faster than an encryption solution, it will only work if you don't mind ...


3

Both hash tables and rainbow tables store precomputed hash values. Rainbow tables are a computing power vs storage tradeoff compared to hash tables. They are used because hash tables can grow very large especially as the throughput of cracking hardware has improved. You can brute force more combinations but now you need to store more. How much space are we ...


2

You're right. Salting really makes password hacking more difficult for non-trivial passwords, but if some users use common passwords, can still hack the password by brute force a few thousands times. If the salt is public/stored together, like your case, it is just used to prevent pre-computed password hashes lookup, i.e. rainbow table. Thus, if for ...


2

There is a difference between a hash as defined for a specific protocol and a cryptographic hash. A cryptographic hash simply takes a message of x bits and outputs n bits where x can be any positive number or zero and n is the output size of the hash. So in that sense a cryptographic hash doesn't define any encoding. A cryptographic hash is indistinguishable ...


2

I think you are missing something -- for the OPM break in, the problem was that they stole a live credential. That is very useful. Having said that, note that no password should be useful. In theory, every worker is issued a smartcard that hosts an e-auth level 4 authentication mechanism in their Personal Identity Verification card. (This is the FIPS 201 ...


2

You might try a syllable hash. Start with a basic hash algorithm to digest individual data identifiers; it doesn't really have to be crypto-strength, and I'd recommend against. Most implementations will produce a byte array which is perfect; a few will produce a single larger primitive or arrays of larger primitives in which case you'll want to split them ...


2

Hashing is indeed the opposite of what you are looking for (any change in the input leads to a completely different hash). You could try a perceptual hash instead. As a side note regarding your hash/salt attempts: why would you need salting? It is not like someone could reconstruct the original document (similar to reconstructing a password and comparing ...


1

The traditional way to avoid the user having to type in a user name is to include "remember me" functionality where the user name is persisted in a manner that is associated with the browser, e.g. an encrypted cookie or a cookie containing a durable token (say, 30 days) that the server can use to infer the user name. Some of the replies here are going to ...


1

User names are predictable. I would prefer using random value as a salt. An attacker could begin the generation of precumputed hash table targeting one user (admin?) even before obtaining the hash&salt to crack. So, you should NOT. Edit: The main purpose of having a salt is that rainbow tables are useless. From my point of view, using a guessable ...



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