it is still md5 in the download page

It surely matters when storing pasword hashes, but just for file checksums?

https://en.wikipedia.org/wiki/Cryptographic_hash_function

it is not a checksum, it is a message digest

I'm not much into encrypting and securing files or passwords, but what's the meaning of this post? Going from forum to forum just telling the devs what they've done wrong?

EDIT:
1) find one forum, criticise their work.
2) find new forum, --------11-----------
3) ?????
4) profit?

it is a very bad idea to continue to use md5 and/or sha1

the goal is to stop using weak and/or broken cryptography algorithms

Yes, MD5 has been broken, but what does it have to do with identifying/verifying files? Surely the chance of a collision is too small to be concerned about.

it is about best security practices

think of it like wearing a seatbelt, it does not mean that you will die in a car crash if you do not wear it, but if there is a serious collision, you would be glad that you were wearing it

If even one single bit is changed in the file, the md5 won't match. What else is there to care about in this case?

racon, the fact that md5 was used, proves that they are not aware of the security issues

the more certain we can be, the better

Are you a politician? Your sound-bite-to-questions-answered ratio is suggestively high.

What security issues are there in this particular use-case?

Quote from Racon :

If even one single bit is changed in the file, the md5 won't match. What else is there to care about in this case?

The problem is that the md5 hashes are not unique: Two files can in theory have the same md5. With some fiddling it is possible to purposely create two different files that have the same md5. See the entries on this blog:
https://natmchugh.blogspot.de/2014/10/how-i-made-two-php-files-with-same-md5.html
For practical purposes it would be more difficult though.

Quote :

think of it like wearing a seatbelt,

imo it is more like wearing a seatbelt in a car with airbags BUT not wearing a helmet. Everybody can in theory think of a serious crash scenario where the helmet might give you extra protection, but in 99% of cases the seatbag and airbags are good enough. And in the 1% cases the helmet might not even matter.

Not applicable to this use-case Gutholz - what are the chances of a random download error creating a collision?

Quote from Racon :

what are the chances of a random download error creating a collision?

zero.
random download errors are not a problem: In worst case the installer does not work and you wasted a bit time and have to re-download.

Problem would be a purposefully altered file (for ex: inserted virus) that with tricks could have the same md5 as the original. But imo as said: a very theoretical problem.

racon, i do not understand you, are you against better security?

gutholz, people download from mirrors also, mitm attacks are possible, and most people do not verify the file by comparing the hashes, it will help those that do verify the files

I'd be a lot more concerned about possible MITM since most of the mirrors don't employ HTTPS. With HTTPS in place you'd have to replace the file on the mirror to deliver it to the victim. Better checksums wouldn't hurt but people rarely check those by hand.

Quote from Gutholz :

zero.
random download errors are not a problem: In worst case the installer does not work and you wasted a bit time and have to re-download.

Problem would be a purposefully altered file (for ex: inserted virus) that with tricks could have the same md5 as the original. But imo as said: a very theoretical problem.

Actual security issue with Live for Speed downloads, if you think there is one, is not that the developers offer a checksum to go with them, but the fact that the binaries or the checksum are not digitally signed (if I remember correctly). (EDIT: the checksum and the downloads are signed in a sense because lfs.net supports HTTPS; it's much, much better than nothing, see spoiler for additional considerations.)

Spoiler - click to reveal

No software of not insignificant size is without bugs, and this includes the software used to operate the lfs.net website. A sophisticated attacker who gained access to the system could change both the download link and the checksum, and have no need to make them match the hard way around.

With additional cryptographic signing step, the attacker would first need to access the system where the signing key is stored, which is most likely considerably harder than compromising a public facing web server.

(There is of course the problem of messaging which signing key is the real developers' to any new LFS user – both Windows and web browsers rely on trusted third parties to verify the keys – but after that any future transactions can be considered secure.)

MadCatX: how does https resolve MITM attack, when you don't pin certificates?

And yes, files should be digested at least by SHA256, I don't think there's any problem to run sha256 instead of md5, you just do: sha256sum -b <file> > sha256.digest
And problem is solved. I mean... at least on any modern OS, not sure about the legacy MS Windows, which Scawen is probably still using (although not as Internet machine to service the LFS.net downloads??? :-O ).

Quote from Ped7g :

MadCatX: how does https resolve MITM attack, when you don't pin certificates?

It requires that the attacker has a certificate that appears as valid in the victims browser which raises the bar for a successful MITM considerably. As long as HSTS and HPKP works I'd say that HTTPS itself provides a good assurance that your data were not modified anywhere in flight. A hacked mirror with a modified file is far more likely that someone MITMing a HTTPS session anyway...

Interesting! What are the odds of each? in terms of "failure"

It's Victor anyway which does the website(s)

Gutholz, we have seat-belts, we must use them

cargame.nl, even so, victor is one of the team members, scawen can tell him to change it

It is not used for security purposes so it's not needed as others already pointed out and this is where the story ends.

Wait a minute now, this is just cargo cult security advice. Yes, MD5 has been broken since the 1990s and now is considered useless for anything other than file integrity checks. On the other hand, SHA1 has had theoretical breaks but it's not actively exploited in the wild and few, if any, of the attacks include being able to choose the substitution "text" at all, let alone adding a trojan.

The advice has been "don't use SHA1 in new projects" not "immediately eliminate all existing usage of SHA1." Yes, Google and others are getting rid of SHA1 but it's because of potential future risk rather than existing risk.

If the hash is intended for anything other than a simple file integrity check, it should be *at least* SHA-256 for future proofing. If not, md5 is fine to check for bit-flipping. Not that we really see that anymore.

cargame.nl, exactly, that is why that must change, also since lfs is a windows application it would be good to also start using authenticode https://msdn.microsoft.com/en-us/library/ms537359(v=vs.85).aspx

rowdog, no, i do not do anything 'cargo cult', this is for security also, not only about probable corruption