View Issue Details

IDProjectCategoryView StatusLast Update
0001283bareos-coreGeneralpublic2023-09-11 17:35
Reporterrugk Assigned Toarogge  
Status acknowledgedResolutionopen 
Product Version19.2.8 
Summary0001283: Remove insecure MD5 hashing
DescriptionYou use/provide CRAM-MD5 hashing:

However MD5 is easily brute-forcable nowadays, vulnerable to an (active) MITM attack and has many more weaknesses:

And it has been deprecated since 2008.
Additional InformationThe linked RFC recommends e.g. SCRAM as an alternative.

AFAIK you use TLS, which should mitigate this problem, but then such an additional authentication is also quite useless here.
You may consider, if appropriate for your use case and not already done. using password stretching hashes (PBKDF, Argon2 etc.) on the server for a secure storage or possibly some kind of private-public-key authentication scheme.
These are only ideas for the future though. For now, just remove legacy and insecure algorithms, or – at least – mark them as deprecated as you should have done in 2008! At most, they can give a false sense of security.
TagsNo tags attached.




2023-09-11 17:35

manager   ~0005409

Right now Bareos has two protocol modes to operate in.
The legacy one is what we inherited from the predecessor project. It uses CRAM-MD5 on plaintext connnections (even if you have TLS enabled).
The modernized protocol does immediate TLS and then authenticates using CRAM-MD5 inside that TLS-session.
While this is still obviously legacy, we chose to keep it for a few reasons:
- the legacy clients require that type of authentication
- in Bareos context it isn't worse than sending a plain password
- it is still considered safe when used via a TLS connection (which is the default nowadays)

Having said that, the document from 2008 that you're referencing is a draft and was never made a standard.

If we decide to implement another incompatible protocol change, we will definitely get rid of CRAM. We will probably not get rid of the shared secrets, so password stretching won't work.
Concerning PKI we decided against it, as PSK seems to be sufficient for our use-case.

Issue History

Date Modified Username Field Change
2020-12-05 13:03 rugk New Issue
2023-09-11 17:11 bruno-at-bareos Assigned To => arogge
2023-09-11 17:11 bruno-at-bareos Status new => assigned
2023-09-11 17:35 arogge Status assigned => acknowledged
2023-09-11 17:35 arogge Note Added: 0005409