Dear @keepass team,
Can you add supports of :
"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".
SCRAM-SHA-1(-PLUS):
-- https://tools.ietf.org/html/rfc5802
-- https://tools.ietf.org/html/rfc6120
SCRAM-SHA-256(-PLUS):
-- https://tools.ietf.org/html/rfc7677 since 2015-11-02
-- https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA
SCRAM-SHA-512(-PLUS):
-- https://tools.ietf.org/html/draft-melnikov-scram-sha-512
SCRAM-SHA3-512(-PLUS):
-- https://tools.ietf.org/html/draft-melnikov-scram-sha3-512
SCRAM BIS: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms:
-- https://tools.ietf.org/html/draft-melnikov-scram-bis
https://xmpp.org/extensions/inbox/hash-recommendations.html
-PLUS variants:
IMAP:
LDAP:
HTTP:
2FA:
IANA:
Linked to:
Why?
The current encryption methods are not broken and are not likely to be.
cheers, Paul
SCRAM is a challenge-response authentication mechanism. This is primarily intended for client/server systems, but it might be possible to encrypt/decrypt database files with a construction similar to OtpKeyProv. I'm currently not planning to develop a plugin for this, but maybe someone else does, thus I'm moving this to the open feature requests.
Thanks and best regards,
Dominik
Ticket moved from /p/keepass/bugs/2291/