Tag Info

New answers tagged

3

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


2

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


0

After 5 month without answer, only comments, I like to sum up: From a discussion in sci.crypt it seems that scrypt is demonstrably secure. Most people on SO trusts scrypt. I have seen no one claimed to have a problem with the algorithm itself. Regardless there might be issues with the implementation. A straight forward implementation of scrypt is ...


1

No. Every hash would have to be recalculated, essentially reproducing the work that was needed to create the original rainbow table. Hashing is basically a mathematical formula. You have a formula (hashing algorithm) of X + 5 = Y, where X is the password and Y is the hash. You use a rainbow table to store all possible values of X with their Y results. ...


0

WPA/WAP2 does not use a dedicated random salt. Instead it was designed to use the SSID as a salt value. This is better than no salt but it does mean some access points are vulnerable. For quite a while most routers would ship with a static SSIS ('linksys' or 'default'). So while hackers can't just precompute a single set of passphrases they could ...


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


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


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


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


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


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


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


0

What are you trying to achieve? Do you want to anonymize a database with sensitive data in order to be able to give it away safely to an external QA test team without compromizing the content? In this case, anonymizing the person and firm names is not sufficient, because the rest of the data has a footprint as well which allows to draw conclusions to the ...


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


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


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


0

If it's a UNIX crypt(), then it's an MD5 hash. As written in PHP's crypt page Normally, hashes starting with $1$ are MD5 hashes. The $ signs are separators, but the the initial $1$ indicates it being MD5. If you're looking to brute force this, most tools automatically detect the hashing algorithm.


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


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


0

If they always use the 3rd and 7th character for this, they might save only hases of the password and this excerpt. Essentially, this would split your full-length password abcdefghijklm into two shorter passwords cg and abdefhijklm. Of these, the two character password offers practically no security. Additionally, the remaining password is not only shortened ...


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


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


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


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


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


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


1

The short of it is that you can't. Hashes don't output encoded characters. They output bytes, and a good hash function should appear to generate all of its output bytes at random. Often, hash outputs are later encoded for humans to read or for compatibility; for example, as hex or base64. But any data can be encoded this way, and there is no way to ...


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


0

Take a look at the following page: http://hashcat.net/wiki/doku.php?id=example_hashes It will provide you with some examples of hashes. You can use tools like hashid or hash-identifier to help try to identify various hashes (both are included with Kali if you are up for spinning up a Linux VM). The tricky part, as I recently went through, is that sometimes ...


0

I would say; A generate a pseudo random token encrypt using the word as the key send result B decrypt generate next token using predefined method encrypt it send it back A decrypt check received token (now A has authentificated B) if not ok then stop here generate next token encrypt it send to B B decrypt check With this you don't have ...


1

The personal-digest-preferences option does not set preferred digest algorithms for creating keys, but during signing (if also encrypting at the same time, the most preferred algorithm supported by the recipient is chosen). From man gpg: --personal-digest-preferences string Set the list of personal digest preferences to string. Use gpg ...


0

O(259) is the same as O(1). Wikipedia is misusing notation. It should say For a CGA with Sec equal to 0, this means that the cost of finding a set of CGA Parameters that yield the desired 59 bits is approximately 259 You are correct that the average cost of finding a value with the same hash is 258. The actual cost might be as little as 1, and it may ...


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


1

Looks to me like standard public-key crypto should work. For example, using RSA (with public key N=p*q and e, private key d): S would be your private key d. Transforming: B = A^e mod N. Transform back: B^d = B mod N. Your requirements seem to then naturally fit the security assumptions of RSA. The one wrinkle here is that anyone can compute B from a ...


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


0

in the CGA protocol in section 7.2 RFC3972 the technique is called hash extension. It seems to be a method used particularly for CGAs and seems not to be well known in other scenarios.


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


1

the password size is fixed by the hash function in which the password is given -> No. The hash functions hash passwords of any length to a smaller length string. They hardly collide. What can promise you a collision is that you hash 2^160 + 1 number of different passwords, then at least one hash must collide. Only hashing two passwords of length ...


0

Yes, statistically you are right. But consider the number of passwords with length of 160 bits, its 2^160=1461501637330902918203684832716283019655932542976 And collision can occure even between two 3 characters long password :)


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


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


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


0

It makes a dictionary attack a lot more difficult, if the salt is created in a smart way. For example, bcrypt uses a 128 bit salt. A salt is usually generated randomly. If it was derived only from the password or the password hash, it would indeed not add much security. If it is generated in a way that cannot be predicted by the attacker, it significantly ...


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.


-1

Hashing is definitely the way. If brute-forcing is an issue then there is no secure way to do this, as any algorithm which compares two 5-letter strings and returns equivalence could be trivially brute-forced in a maximum of 26^5=11881376 comparisons. The only feasible way of defending against brute-forcing in such a low-entropy environment is to use a ...


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.



Top 50 recent answers are included