Yeah, this was a major and well publicized issue at the time, and is why most apps, sites, and services that still used it migrated to SHA-256 shortly after it was discovered (in Jan 2020). E.g....
Yeah, this was a major and well publicized issue at the time, and is why most apps, sites, and services that still used it migrated to SHA-256 shortly after it was discovered (in Jan 2020). E.g. Git migrated on Feb 3, 2020: https://lwn.net/Articles/811068/
Should I add (2020) or something similar to the topic title to prevent any further confusion? @mycketforvirrad how do you normally handle it when older, undated articles are submitted?
Most cases tend to be opinion pieces usually, so I never think it's all that important. For any factual-esque post where the title alone might cause confusion, it could be a good rule of thumb...
Most cases tend to be opinion pieces usually, so I never think it's all that important. For any factual-esque post where the title alone might cause confusion, it could be a good rule of thumb...
I mean... anybody using SHA1 or MD5 to hash passwords in 2023 is either a fresh newbie with zero programming experience who literally just discovered an old W3Schools tutorial, or if they're...
I mean... anybody using SHA1 or MD5 to hash passwords in 2023 is either a fresh newbie with zero programming experience who literally just discovered an old W3Schools tutorial, or if they're managing any kind of actual website, is a moron that may as well just be storing their passwords in plain text.
SHA1 was depreciated a long time ago and there are a lot of better algorithms available today, like Argon2, Bcrypt and PBKDF2.
It's correct that SHA1 is bad for password hashing because it's not a slow iterated hash, but that's unrelated to this issue. This issue affects SHA1's use as a hash in other non-password...
It's correct that SHA1 is bad for password hashing because it's not a slow iterated hash, but that's unrelated to this issue. This issue affects SHA1's use as a hash in other non-password contexts. This issue doesn't make it easier to crack a hash of unknown content; this issue makes it possible for an attacker to create two pieces of different content that have the same hash as each other. This is a problem when an attacker creates a good file and a bad file with the same hash, and then gets some victim to sign the hash of the good file or otherwise direct users to trust files containing the hash. An example of this would be if someone created an HTTPS certificate for a domain they owned and a domain they didn't own, and then got a certificate authority to sign their certificate. Then the attacker would be able to host a website that could verify itself over HTTPS as the domain they didn't own, which would allow a man-in-the-middle attack of an HTTPS-using website to be done successfully.
It's not really about password hashing - there's many places where SHA1 checks were used for integrity validation, like git, where it's used to maintain the merkle tree (bLOckcHAin). If it were...
It's not really about password hashing - there's many places where SHA1 checks were used for integrity validation, like git, where it's used to maintain the merkle tree (bLOckcHAin). If it were trivial to find SHA1 collisions, someone could compromise a commit tree, inject malicious code, and git clients would happily ingest the branches thinking the history is unchanged.
I suspect they'd also have to compromise the host of the repository to overwrite the existing object in the store. Or operate a malicious mirror I suppose. The colliding object also has to be the...
I suspect they'd also have to compromise the host of the repository to overwrite the existing object in the store. Or operate a malicious mirror I suppose. The colliding object also has to be the exact same length. All of that said, Git needed to transition away five years ago.
The blog post is undated, but apparently this is from 2020.
Yeah, this was a major and well publicized issue at the time, and is why most apps, sites, and services that still used it migrated to SHA-256 shortly after it was discovered (in Jan 2020). E.g. Git migrated on Feb 3, 2020: https://lwn.net/Articles/811068/
Should I add (2020) or something similar to the topic title to prevent any further confusion? @mycketforvirrad how do you normally handle it when older, undated articles are submitted?
Most cases tend to be opinion pieces usually, so I never think it's all that important. For any factual-esque post where the title alone might cause confusion, it could be a good rule of thumb...
nit: I think saying Git migrated is
a bit ofan overstatement even today.My bad, thanks for the clarification. It did seem odd to me that it referenced 2019 but I didn't do my due diligence to check the actual date.
I mean... anybody using SHA1 or MD5 to hash passwords in 2023 is either a fresh newbie with zero programming experience who literally just discovered an old W3Schools tutorial, or if they're managing any kind of actual website, is a moron that may as well just be storing their passwords in plain text.
SHA1 was depreciated a long time ago and there are a lot of better algorithms available today, like Argon2, Bcrypt and PBKDF2.
It's correct that SHA1 is bad for password hashing because it's not a slow iterated hash, but that's unrelated to this issue. This issue affects SHA1's use as a hash in other non-password contexts. This issue doesn't make it easier to crack a hash of unknown content; this issue makes it possible for an attacker to create two pieces of different content that have the same hash as each other. This is a problem when an attacker creates a good file and a bad file with the same hash, and then gets some victim to sign the hash of the good file or otherwise direct users to trust files containing the hash. An example of this would be if someone created an HTTPS certificate for a domain they owned and a domain they didn't own, and then got a certificate authority to sign their certificate. Then the attacker would be able to host a website that could verify itself over HTTPS as the domain they didn't own, which would allow a man-in-the-middle attack of an HTTPS-using website to be done successfully.
It's not really about password hashing - there's many places where SHA1 checks were used for integrity validation, like git, where it's used to maintain the merkle tree (bLOckcHAin). If it were trivial to find SHA1 collisions, someone could compromise a commit tree, inject malicious code, and git clients would happily ingest the branches thinking the history is unchanged.
I suspect they'd also have to compromise the host of the repository to overwrite the existing object in the store. Or operate a malicious mirror I suppose. The colliding object also has to be the exact same length. All of that said, Git needed to transition away five years ago.