You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is potentially a security vulnerability. I am reporting it here since you neither have a security policy in your repository nor your website uses the https://securitytxt.org/ standard (I would expect https://nhost.io/security.txt to provide contact information). This is also not of a huge impact, but still.
This repo depends on [email protected] for OTP secrets generation which uses only 10 bytes of entropy for the OTP secret generation. This may allow someone who knows a few OTP tokens and the time they were generated to brute force the random value used to generate the secret and then predict future generated OTP tokens.
The hasura-auth uses the otplib for secret generation in here:
The totpSecret is generated from 10 bytes of randomness since this is the default number of bytes the [email protected] uses under the hood. This can be seen here which uses this method under the hood.
By the way, this behavior is also not compliant with some RFCs that recommend to use at least 160 bits of randomness.
Also please note that previous versions of otplib used 20 bytes of randomness instead of 10 for secret generation. I have no idea why this was changed in 12.0.0 to just 10 bytes.
This issue is also reported on the upstream otplib repository here: yeojz/otplib#671
To fix the issue, you can simply use e.g. authenticator.generateSecret(32); which would provide 32 bytes (256 bits) instead of the default (10) bytes of randomness for secret generation.
The text was updated successfully, but these errors were encountered:
Hey,
This is potentially a security vulnerability. I am reporting it here since you neither have a security policy in your repository nor your website uses the https://securitytxt.org/ standard (I would expect https://nhost.io/security.txt to provide contact information). This is also not of a huge impact, but still.
This repo depends on [email protected] for OTP secrets generation which uses only 10 bytes of entropy for the OTP secret generation. This may allow someone who knows a few OTP tokens and the time they were generated to brute force the random value used to generate the secret and then predict future generated OTP tokens.
The
hasura-auth
uses theotplib
for secret generation in here:hasura-auth/src/routes/mfa/totp-generate.ts
Lines 29 to 45 in 064b15b
The
totpSecret
is generated from 10 bytes of randomness since this is the default number of bytes the[email protected]
uses under the hood. This can be seen here which uses this method under the hood.By the way, this behavior is also not compliant with some RFCs that recommend to use at least 160 bits of randomness.
Also please note that previous versions of otplib used 20 bytes of randomness instead of 10 for secret generation. I have no idea why this was changed in 12.0.0 to just 10 bytes.
This issue is also reported on the upstream otplib repository here: yeojz/otplib#671
To fix the issue, you can simply use e.g.
authenticator.generateSecret(32);
which would provide 32 bytes (256 bits) instead of the default (10) bytes of randomness for secret generation.The text was updated successfully, but these errors were encountered: