Tag Info

New answers tagged

1

For the intended purpose, the practical answer is "Yes, of course", although for reasons of prestige you should also publish a more recent hash (such as SHA-3). If it didn't have so much "stench", you could in principle still use MD5 (apart from people yelling at you, even MD5 will work fine for this application). Using SHA-1 to verify downloads has never ...


0

Tom Leak has a beautiful answer (which is why it is accepted). It is concerned with the mathematically provable facts behind the use of SHA-1. There is a second approach which is less fact based but may provide valuable heuristic information. I learned this approach from reading Bruce Schnier's opinions, but I cannot find the links off hand, so Bruce will ...


45

I suppose you "use sha1sum" in the following context: you distribute some software packages, and you want users to be able to check that what they downloaded is the correct package, down to the last bit. This assumes that you have a way to convey the hash value (computed with SHA-1) in an "unalterable" way (e.g. as part of a Web page which is served over ...


2

Even if you are not doing work for the federal government, the link to the document below is a good reference to how long people should use hash key lengths until future dates for specific tasks like authenticating a signature. For package authentication, I would also include a size which makes it much harder to create a collision (Changed package that ...


7

You should use SHA-256 or SHA-512. If you are only signing packages you have created yourself, then technically SHA-1 is still secure for that purpose. The property that is now weakened is "collision resistance" which you are not strictly relying on. However, the security of SHA-1 is only going to get worse with time, so it makes sense to move on now.


1

Can you still use it?..Yes you can, but sha-1 is vulnerable to collision attacks and has been deprecated by a number of browsers. If the question was should you still use it, then I would say no you shouldn't, you should move to sha-2 and sha256sum type program.


17

FIPS 140-2 does not cover the topic of password hashing. Thus, there is no password hashing function which would be "FIPS-approved" in that sense. Using SHA-512 "as is", with or without some salt and regardless of how you inject the said salt in the engine, would not grant you the NIST approval. NIST simply does not approve (or disapprove of) password ...


5

FIPS 140-2 does not list password hashing algorithms. If you actually need to use FIPS 140-2 validated algorithm, you need to find solutions that were validated by NIST for your required compliance level. You probably need to verify this with a FIPS auditor, but PBKDF2 has implementations like PBKDF2-HMAC-SHA256 or 512 for instance. That could be regarded ...


5

From the first paragraph of the link you've provided: As a result, apps that don't support SHA-2 certificate signatures will no longer be able to connect to Facebook starting on October 1, 2015. I would read this differently to your interpretation. This is not a requirement to the apps to have certificates signed with SHA-2 but it is a requirement to ...


0

There are unfortunately still many large sites that still make use of an SHA-1 cert, and chrome / firefox don't complain because the cert expires before the end of this year. See this question about the same situation on Google. That being said, don't concern yourself too much. I can see the same thing: I'm sure they'll upgrade it soon. (Not soon enough!) ...


1

The general response to this is correct - if your server is storing a copy of a key that's used to encrypt something in memory, there is a chance that an exploit will allow it to be stolen. (See: heartbleed) I think it's definitely worth asking in this case why you need to store a hash and an encrypted version of the password. I can see a system in which ...


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


0

What I can see, is that the main difference is not about "SHA1" but about the certificate chain. See the icons. Both "SHA1" messages are locked with a green icon, but the part about about the identity of the website is different. GOOD: *.mail.live.com . Certification owned by Microsoft, verified by Symantec Class 3. According to digicert.com, no error or ...


1

In reply to the Added 2 part. Yes. It will be the same after 1 Jan 2016 and even after 1 Jan 2017. You can always click through this warning and tell the browser to ignore it (it is somewhat harder with HSTS, but thats another story).


2

The article you linked to is only relevant for CAs participating in the Windows Root CA Program, not self-signed certs. Self-signed certs only work if you put them as a trusted CA root in OS or browser. These will continue to work indefinitely. Windows Root CA Program certs signed with SHA1 are good to 1 Jan 2017. 1 Jan 2016 is the last issue day that ...


0

You will need to replace it before January 2017 with a SHA-2 in order for Windows/browser clients to accept the certificate.


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



Top 50 recent answers are included