Tag Info

New answers tagged

21

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


5

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


1

It depends on what whether you really mean the "most trustworthy". As with many aspects of digital security, there is a sliding scale of strength / reliability vs usability / feasibility. I think some important questions to consider are: Who are your users? To what extent do they care about proof of file integrity? Even if the users don't care, how ...


0

It is about how you interpret what they are writing. They are not saying you should not hash and should store passwords in plain text. What it is saying is that the value you write into LDAP is not hashed or encrypted. This is like the situation you have with a normal database. You can define a column called password and you can either tell the database to ...


1

You already have your answer on methods to demonstrate integrity. Any of those techniques are as "trustable" as the entity implementing them is. Perhaps what you meant to say was "most appropriate"? Assuming this is your homework question: A user transfers several files to a destination, and wants to prove that the files have not been altered in ...


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


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


1

Since you are talking about Unix, and since you are rather talking about /etc/passwd file instead of /etc/shadaw, I presume you are talking either about a Unix system (as you said) or an old based distribution, so I prefer to quote you this directly as it answers your question: Earlier versions of Unix used a password file (/etc/passwd) to store the ...


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


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


0

Yes, shortening a hash does reduce the security of the hash. An important part of the security of a hashing algorithm is the algorithms collision resistance. This mean that if I hash ThingToHash1 the result (hopefully) won't match the hash for any other input. By truncating the hash, you're increasing the likelihood of a collision because only a subset of ...


0

You simply avoid processing raw biometric data on your server at all cost. The way Apple does it on their iDevices is a good guide line. Let specialised and isolated hardware compute and store the sensitive biometric information for you. Then fetch the already hashed data from the hardware. If possible, you should not use pictures captured by the sensor.


0

Most modern encryption algorithms are designed such that the ciphertext is indistinguishable from random noise. But if an older algorithm was used, it may be possible to glean some information about the algorithm from the ciphertext. See this post on Cryptography SE for more info.


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


-2

No, Inspect Element or something similar exists on most browsers, allowing anyone to bypass client-side code. If a hacker got access to the database, they could remove the hashing code using Inspect Element and enter the hashes as passwords, or edit the page to not hash it anyway. How about instead, a script that stops the server if it senses a page has been ...


1

I find a lot of people (especially in the PHP realm) misunderstand what hashing does. Here's the methodology User creates account and sends a username/password combo to you (securely over HTTPS I hope) Password is hashed on the server (with a random salt) and stored with the username User comes back later and enters their plain text password Server finds ...


1

You likely wouldn't be able to prevent simple server-side modification of the code sent to clients to execute if your server is totally owned. However if this is part of a pre-installed or pre-distributed software package with distinct client and server components (this could include web applications with downloaded components that stay resident on the ...


0

If the hash is sent in plain text, hashing before sending is the same as nothing; an attacker can simply intercept the hash and send a forged request to the server, granting him access. If you are using some kind of encryption scheme (which you should), then hashing twice is meaningless. What you should do is the following: every time you send the password ...


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


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


-2

PBKDF2 is not a hashing algorithm per se. It key derivation function (KDF) which "harden" the hashing algorithm you've chosen. Scrypt is also a KDF, so it does not make any additional protection to use two similar functions. As you wrote, the strength will be as good as the strongest of the chosen two. And, as Revulai said in her good answer, you shouldn't ...


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


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


0

In addition to the excellent answer given by Thomas Pornin in the linked question, I would add that for security reasons in your case you probably want to do some hashing on the client side, and some hashing on the server. The reasoning goes like this: Pros of server-side hashing: Lets' say you only do client-side hashing, then you are taking the string ...


0

I would definitely hash before the upload. If a user device is connected to a network with someone sniffing packets, a plain text password being uploaded is easily read. Not very secure.


0

You can use scrypt, bcrypt or PBKDF2 for hashing and salting your passwords before storing them. Password hashing is damage containment attitude. I do not see it useful to rehash twice or more. You can attack a secure hash by the use of a rainbow table, which you can prevent by applying a salt to the hash before storing it. I advice you to read this post ...


0

It depends on the type of attack. If the attack is of man-in-the-middle type, then it won't make sense if you hash it again before it reaches the server, because the first hash was already leaked on its way.If the attack is on the server side, then it would be better to keep password => hash => network => hash => database, as it would make the process of ...


1

There is no extra security in hashing the password before sending it over to the server, as now this hash would become the password. More important is it to send the password over an encrypted channel (SSL/TLS) to prevent it from being sent in plaintext and being read by others on the network. To store the password you should hash + salt it, again to ...


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


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


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


0

"Secure Remote Password Protocol (SRP)" isn't "pretty much client side hashing" since SRP is a candidate PAKE protocol, so with it, the alleged server shouldn't be able to learn enough to log in. Those systems don't "avoid the plaintext equivalence problem" since the login process just consists of two messages and the server's message is predictable, ...


0

Based on what you have outlined, your solution seems overly complex and I'm not sure why you wouldn't just encrypt the data rather than hashing it. There may be limitations in what you can store in the remote app that may require encoding the encrypted data (similar to what needs to be done when sending encrypted email). This would eliminate the need to ...


2

How good are your programming skills? It would not be too difficult to write a program or script that loops over all possible salt strings, take your password "123"and try sha1($pass.$salt) and sha1($salt.$pass). If the hash that comes out matches the one in the database, then you've found your salt. One possible problem is knowing exactly which hash ...


1

MD5 is known to be generally faster than SHA256. You can confirm that on this page, for example. OpenSSL for example has a built-in benchmark suit, so you can compare yourself by running: $ openssl speed md5 $ openssl speed sha256 But of course, the hardware and software you use to compare them can make difference. You can see the results this user got ...


1

It depends on the hardware and software you are running. Below are comparison results between MD5 and SHA using the openssl library on my computer. But different implementations that take into account hardware acceleration will give different results. Modern CPUs have hardware acceleration for hash functions. GPUs will have better results and specialised ...


-1

Hashes are one-way functions, which essentially means, they were constructed to make practically impossible to reconstruct their input from their output. However, there are some narrow possibilities to reconstruct the original value: If you can somehow narrow the possible values, you can hash them one by one and compare to your desired output. For ...


2

There are actually two kinds of KDFs. One kind is designed to derive a key from high-entropy input (like another key); this can be done with a fast keyed hash like HMAC. The other kind takes a password as input. Passwords are low-entropy; they're not inherently very hard to brute-force. A good password hash thus has to be slow. In your question, you said ...


2

Since PBKDF2 could be use to generate as much bytes as you want/need, you can of course use it for both master password hashing and key generation. You don't even need to use different salt, just generate a n bytes hash, then generate n+m bytes, discard the first n bytes and use the other m bytes as key.



Top 50 recent answers are included