Tag Info

Hot answers tagged

60

The weakness you allude to is real. An important point is that once the server is compromised, the attacker has little incentive to grab passwords that grant access to that server -- he is already in the place. However, human users have the habit of reusing passwords, and that is a big problem, because a reused password means that compromises on one server ...


37

Number of rounds is often stored with the password and hash. For example, using bcrypt: $2a$10$oEuthjiY8HJp/NaBCJg.bu76Nt4eY4jG/S3sChJhZjqsCvhRXGztm The 10 indicates the work factor, effectively adding 10 bits of entropy in terms of hashing time to brute force. 2^10 = 1024 rounds. It is stored with the hash in case of the need to up the work factor due ...


14

So there's two separate parts to this. First, the server getting compromised, and second, sending hashes to the server instead of passwords. For the first part with the server getting compromised, yes, the attacker could pretty much do whatever they want. If they own the server, they can indeed get the usernames and passwords from the users being passed to ...


13

How does a hacker know how many times a password was hashed? The same way you do. The goal of hashing a password is to make it impossible (in practice very difficult) to determine the password, even with full access to all the data. The other requirement for hashing is that the server must be able to determine if an entered password is correct. This means ...


13

To expand on the point that @cthulhu makes in his comment, the correct answer to this is "nether". SHA2 family hashing algorithms are not designed for password storage and unless you have no choice but to use a general purpose hashing algorithm, they should not be used. To quote this answer the main reasons for this are A basic hash function, even if ...


11

An algorithm can be secure only if used properly within a protocol that matches what the algorithm was meant to do. So none of the algorithms you list can be deemed "secure" in an absolute, unconditional way. On the other hand, some algorithms are necessarily insecure and should never be used (for a security purpose). In your list, these are: DES block ...


9

Simply truncating a hash is the common and accepted way to shorten it. You don't need to do anything fancy. There are plenty of questions here, and on crypto.stackexchange about whether doing this reduces the strength of the hash (see the list of related questions at the bottom). The answer is that No, truncating a hash does not reduce its strength (apart ...


8

The number of iterations and the salt are stored in the same database, usually in the same field as the password hash itself. Because the site needs to know those things just as much as a potential attacker does, and so they have to be easily available. For example, bcrypt hashed passwords contain the (log base 2 of the) number of iterations separated by $ ...


7

Passwords are hashed for the case that an attacker can read the hashes from the database (e.g. SQL-injection). Afterwards he can brute-force with the full speed of his own environment, often with a GPU, this is called an offline attack. A sleep on the other hand could only protect from online attacks, even then an attacker could make multiple requests and ...


6

An existential forgery of a chosen plaintext is having the ability as an attacker to obtain a valid MAC for a plaintext of your chosing, without knowing the key required to generate a correct MAC. A common vector for this is a timing attack, and that would work like this: The attacker sends a message, and an HMAC (really just a sequences of bytes the ...


6

Whether you should be worried or not depends on the sensitivity of what you're protecting. The lock protecting my filing cabinet holding my taxes and medical information doesn't need to be that secure, and I don't worry that the lock is cheaply designed. But I want the locks protecting my money to be extremely secure. It does show that they may not be ...


6

Today I have read this discussion about wheels and that we should not simply strap ourselves to a wheel to travel on a multilane highway. And I have read here that instead we can take the bus, because it has safety features. That is great, but what about if I use a seatbelt with my wheel? Salting is good. Iterations are good. SHA-512 is a good ...


6

I can tell you which ones are currently not secure: Anything ending in "Ecb" is insecure. ECB mode does not hide large-scale patterns in the data. Anything beginning with "Des" is insecure. The key size for DES is simply too small to resist attacks using modern hardware. Anything beginning with "Rc2" may be insecure, depending on how you use it. It's ...


5

On most modern distributions, the salts and the hashed passwords are stored in the shadow file /etc/shadow (which is only readable by root), not the /etc/passwd file. For each user record in /etc/shadow, the salt is between the 2nd $ and the third $. See answer by mti2935 in ...


5

First, Base64 will use, well, 64 different chars (hence the name) to encode binary data. The almost only set of symbols used is this: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ I am not aware of any implementation that uses a different one. According to Wikipedia, "A hash function is any function that can be used to map digital data ...


5

I am going to give you two answers, neither of which are information-theoretically correct, either of which should illustrate why not to bother. Entropy. Basically, your scheme adds an element of randomness: between 5 and 15 hash cycles. So, any random number X such that 5 <= X <= 15... in other words, X has 11 possible random values... which ...


4

There's a misconception or two in your question. As a message (file, etc.) hash, MD5 is not insecure because of the “ability to brute force and pick up the result”. Cryptographic hashes are supposed to have three security properties: One way: Given a hash, it is infeasible to find a message with that hash. Integrity: given a message, it is infeasible to ...


4

I know that most hash functions today use Base64 encoding for their functions, resulting in hashes that use a-Z and 0-9, and, sometimes, other special characters. This results in 62-76ish possible values for each character, so if your hash ends up being say, 70 characters long, there are 70^62 possible combinations. Most hashes are expressed ...


3

A collision for a cryptographic hash function h is a pair of data elements (two sequences of bits) m and m', which are distinct from each other, but hash to the same value (m ≠ m' but h(m) = h(m')). Since a hash function accepts as input sequences of bits that can be much longer than the fixed output size, the number of possible inputs to a hash function ...


3

While the currently accepted answer is correct and the number of iterations is usually stored where the hashes themselves are, even if this was not the case: By Kerckhoff's principle, you should assume the attacker can find out. In practice they could find out for example by creating their own login with a known password or timing a login attempt. Even if ...


3

If session identifier is randomly chosen from sufficiently big space (something like 12 bytes should be more then enough) then any non-invertible hash function (even md5) will be secure, and there will be no need for salt (rainbow tables of this size are infeasible). To expand, problem when storing password hash is that passwords usually have very low ...


3

You should really stray away from rolling your own crypto implementation. Why not use bcrypt for password storage? It's been tested extensively for that and works quite well. Some advantages it has are: Resistance to brute-force Resistance to rainbow tables Salt generation Scalable speeds via setting the rounds of hashing Built upon blowfish algorithm ...


3

Password hashing is a trade-off: you make the function slower (through using many iterations), which makes both attacks and normal usage more expensive. You accept to spend more CPU on the task of verifying a password because you know it will also make the attacker spend more CPU on the task of cracking a password. A decent password hashing function offers a ...


2

In fact, they are the same hashing algorithm: SHA2, just with two different digest sizes. It is "cheaper" (faster) to generate SHA256 than SHA512. So from the security perspective a potential attacker will need more time to generate all possible SHA512 hashes to brute force a hashed password from your database. Therefore, you can consider SHA512 as more ...


2

Argon2 the winner of the PHC also allows for client side hashing. Note that this is an additional feature, and doesn't make Argon2 to a fully fledged authentication protocol. The PHC has awarded it as password hashing algorithm, not as authentication protocol. Isn't Secure Remote Password Protocol (SRP) pretty much client side hashing? For SRP, ...


2

Whether a password system stores your password in plaintext has NO CONNECTION to if it is case sensitive or not. Plenty of badly designed systems require case sensitive passwords but store them in plaintext. As to whether or not you should be concerned, any system that does not require case sensitive passwords has greatly cut the amount of unique passwords ...


2

First, don't store the SHA256 of your master password! See this answer for how to store the hash of the master password. Onto your question... Salt is used to prevent the attacker precomputing the hashes for many/all possible inputs. In the specific case of storing the hash of the master password, a sufficiently large and random salt will prevent an ...


2

There are multiple pieces of information in this output which could be of use to a security/penetration tester. Version of Apache used and the Operating system involved. This version of Apache has a number of known security issues, so as a tester you could research those to understand whether they are exploitable. The two robots.txt entries (/internal/ ...


1

Regarding your specific questions around SHA1 and weak cipher suites: SHA1 is considered weak signing algorithm now. Great long run down can be read here. Basic googling can help beyond this: https://konklone.com/post/why-google-is-hurrying-the-web-to-kill-sha-1 *Nmap example does not confirm nor contain a certificate showing SHA1 weakness. Weak cipher ...



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