TOTP algorithm parameter (SHA256/SHA512) appears ignored — generates SHA1 codes only

Ask the Community Password Manager
, ,
1

TOTP algorithm parameter (SHA256/SHA512) appears ignored — generates SHA1 codes only

Summary

Bitwarden documentation and prior discussions indicate support for SHA256/SHA512 in TOTP. However, in practice, Bitwarden appears to generate SHA1-based codes regardless of the algorithm parameter in otpauth:// URIs.

This results in authentication failures for services that require SHA256 (e.g. Australian Government myGov, error RFM 177).

This issue relates to the integrated TOTP functionality within the Bitwarden Password Manager (not the standalone Bitwarden Authenticator app).

Expected Behaviour

Bitwarden should:

  • Parse the algorithm parameter in otpauth:// URIs
  • Generate TOTP codes using:
    • SHA1 (default)
    • SHA256
    • SHA512
  • Behave in accordance with RFC 6238

Actual Behaviour

  • Bitwarden generates TOTP codes consistent with SHA1
  • Codes match other SHA1-based authenticators (e.g. Bitwarden and Microsoft Authenticator fallback)
  • Codes do not match SHA256-generated values
  • Services requiring SHA256 reject the codes

Reproduction Steps

  1. Add a TOTP entry using the following URI:
otpauth://totp/Test:sha256@example.com?secret=JBSWY3DPEHPK3PXP&issuer=Test&algorithm=SHA256&digits=6&period=30
  1. Generate a code in Bitwarden
  2. Generate a code using a SHA256-compatible tool for the same secret and timestamp

Verified Test Case (RFC 6238)

Using:

  • Secret: JBSWY3DPEHPK3PXP
  • Time: 59

Expected:

  • SHA1: 
    94287082
  • SHA256: 
    46119246

Bitwarden produces the SHA1 value.

Real-world Impact

This is not theoretical — it blocks use of Bitwarden for MFA on services requiring SHA256, including:

  • Australian Government myGov (returns an error indicating the authenticator is not compatible with SHA256)

Prior Discussion

There is an older thread indicating support was planned/implemented:

https://community.bitwarden.com/t/support-totp-auth-parameters/37

However, current behaviour suggests that algorithm=SHA256 is either ignored or not functioning correctly.

Key Observation

If SHA256 were correctly implemented, Bitwarden should generate a different code than SHA1 for the same secret and timestamp. Currently, it does not.

Request

  • Confirm whether SHA256/SHA512 TOTP is fully supported
  • If supported, investigate why the algorithm parameter appears to be ignored
  • If not supported, implement full RFC 6238 support for SHA256/SHA512

Environment

  • Bitwarden browser extension (Chrome)
  • Latest version (as of 2026)
  • Reproduced across multiple authenticators for comparison
2

@babstar99 Welcome to the forum!

It’s always good to also know of (potential) bugs also here on the Community Forum, but bugs have to be reported to Bitwarden on GitHub, so please open a “New issue” here: Issues · bitwarden/clients · GitHub

Bitwarden will try to reproduce and investigate these, if they do agree there is an issue/bug.

3

PS: I now was curious enough to test this myself – and I used this generator for SHA1 and SHA256 to compare, and my integrated authenticator (BW extension 2026.3.0) produced the same SHA1 and SHA256 codes as the Token2 site produced.

I used your string:

otpauth://totp/Test:sha1@example.com?secret=JBSWY3DPEHPK3PXP&issuer=Test&algorithm=sha1&digits=6&period=30

otpauth://totp/Test:sha256@example.com?secret=JBSWY3DPEHPK3PXP&issuer=Test&algorithm=sha256&digits=6&period=30

PS: In that string I only changed SHA to sha – I didn’t test though, if that makes a practical difference.

4

I am able to correctly generate TOTP codes for SHA1, SHA256, and SHA512 using the above parameters, as verified by this tool.

Have you synchronized the clock on your device?

5

Per this Bitwarden help document, Bitwarden today does parse the algorithm parameter and it does support sha1 sha256 and sha512. As such, I am moving this from “Feature Request” to “Ask the community”.

Your test string includes period=30, but your verbiage states Time: 59. You might check where that inconsistency was introduced. If the period does not match on both sides, the two sides will not interoperate. This is noted as requirement “R4” in RFC6238.

Incidentally, when it comes to reading RFCs, the words “MAY” and “MUST” have specific meaning. Bitwarden would remain RFC 6238 compliant even if it did not support sha256. RFC 6238 permits but does not compel sha256 functionality"