View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001283 | bareos-core | General | public | 2020-12-05 13:03 | 2024-05-15 15:47 |
Reporter | rugk | Assigned To | arogge | ||
Priority | high | Severity | feature | Reproducibility | always |
Status | closed | Resolution | not fixable | ||
Product Version | 19.2.8 | ||||
Summary | 0001283: Remove insecure MD5 hashing | ||||
Description | You use/provide CRAM-MD5 hashing: https://github.com/bareos/bareos/blob/819bba62ebdadd2ac0bd773ac8d26f4f60f5d39e/python-bareos/bareos/util/password.py#L51 However MD5 is easily brute-forcable nowadays, vulnerable to an (active) MITM attack and has many more weaknesses: https://en.wikipedia.org/wiki/CRAM-MD5#Weaknesses And it has been deprecated since 2008. https://tools.ietf.org/html/draft-ietf-sasl-crammd5-to-historic-00 | ||||
Additional Information | The 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. | ||||
Tags | No tags attached. | ||||
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. |
|
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 | |
2024-05-15 15:47 | arogge | Status | acknowledged => closed |
2024-05-15 15:47 | arogge | Resolution | open => not fixable |