4 ms·

The downside to this method is that since the resulting cryptographic hash and salt have to be in the resulting file, so there is nothing stopping someone from

The downside to this method is that since the resulting cryptographic hash and salt have to be in the resulting file, so there is nothing stopping someone from pulling the hash/salt out and bruteforcing it locally (as opposed to being able to ratelimit login attempts on a server) if they are so inclined and have the required resources.. which may not be that much in the way of resources as the tool uses 1000 iterations of PBKDF2[1]. This is magnitudes lower than what OWASP recommends[2]. I wouldn't personally put anything you want secure behind this. [1]: https://github.com/robinmoisson/staticrypt/blob/5dac008ba64490485db9a51b15e6b2f3adb2a145/lib/cryptoEngine/cryptojsEngine.js#LL50C35-L50C41 https://github.com/robinmoisson/staticrypt/blob/5dac008ba644... [2]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2 https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

deleted 4y ago
[deleted]
411111111111111 4y ago
The linked readme agrees with that https://github.com/robinmoisson/staticrypt#is-it-secure https://github.com/robinmoisson/staticrypt#is-it-secure
tialaramex 4y ago
Right but all that's happening here is stretching. So the difference only matters in the middle. Regardless of the strategy bad guys will guess "1234" or "sesame" (too easy) and they won't guess a random 128-bit key I just generated with my hexadecimal dice (impossible). This weakness only means it's easier than expected to guess your password is "suckitelon" or "GoCowboys1978" or whatever We put a lot of effort into teaching people to do better stretching, but it feels like the result was they put even more passwords on things, rather than using the breathing room to get off passwords. If your project for 2023 is "Use a fancier password hash" instead of "Get rid of passwords" you are Doing It Wrong™. If you wanted to do something like this seriously, consider hmac-secret extension to FIDO, which means Security Keys (so the things you'd use to log in to say Google or Facebook) can present an arbitrary always-identical secret value which would be more than adequate to secure such a thing unlike a human memorable password. Today hmac-secret is mostly used to authenticate to an off-line laptop PC or similar.
- d-z-m 4y ago
  Last I heard WebAuthn didn't have access to hmac-secret or prf outside of a Chrome canary. Has this changed recently?
- ipaddr 4y ago
  Your 128 key is difficult for users to enter manually.
  - deleted 4y ago
    [deleted]
  - franky47 4y ago
    Strong cryptographic keys should never be input using a keyboard and fingers, there are much better interfaces for that (security keys, passkeys, password managers).
deleted 4y ago
[deleted]
dakiol 4y ago
Is it a downside if the password is a 100 characters-long string?
- doodlesdev 4y ago
  A fellow cryptographer in the security board on stack exchange has shared their opinion on this: https://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pbkdf2-sha256/3963#3963 https://security.stackexchange.com/questions/3959/recommende... TLDR: No. In fact, theoretically stretching the password is more effective than increasing iterations. However, I don't see him citing the fact some password hashing functions have limited input size, which means at some point having a larger password doesn't really change anything.
- bawolff 4y ago
  Depends which characters they are. But in practise nobody uses 100 character long strings. Security is the intersection of real users with systems, not imaginary ones.
  - jsjohnst 4y ago
    > But in practise nobody uses 100 character long strings. Multiple websites I use daily have that length of password or longer.
- pmontra 4y ago
  I was thinking that I keep my secrets at hand in my password manager of the Keepass family. I sync the db from my laptop to my mobile devices. The 100 characters password would be in the password manager but the secrets I would work with fit into the password manager, so I have no need to use a separate channel. I could upload the db, download it and just remember the master password. The only use case for this technology is when the secret is the file itself and it can't fit in the password manager. An image, a file, etc.

deleted 4y ago

[deleted]

411111111111111 4y ago

The linked readme agrees with that https://github.com/robinmoisson/staticrypt#is-it-secure https://github.com/robinmoisson/staticrypt#is-it-secure

tialaramex 4y ago

Right but all that's happening here is stretching. So the difference only matters in the middle. Regardless of the strategy bad guys will guess "1234" or "sesame" (too easy) and they won't guess a random 128-bit key I just generated with my hexadecimal dice (impossible). This weakness only means it's easier than expected to guess your password is "suckitelon" or "GoCowboys1978" or whatever We put a lot of effort into teaching people to do better stretching, but it feels like the result was they put even more passwords on things, rather than using the breathing room to get off passwords. If your project for 2023 is "Use a fancier password hash" instead of "Get rid of passwords" you are Doing It Wrong™. If you wanted to do something like this seriously, consider hmac-secret extension to FIDO, which means Security Keys (so the things you'd use to log in to say Google or Facebook) can present an arbitrary always-identical secret value which would be more than adequate to secure such a thing unlike a human memorable password. Today hmac-secret is mostly used to authenticate to an off-line laptop PC or similar.

d-z-m 4y ago
Last I heard WebAuthn didn't have access to hmac-secret or prf outside of a Chrome canary. Has this changed recently?
ipaddr 4y ago
Your 128 key is difficult for users to enter manually.
- deleted 4y ago
  [deleted]
- franky47 4y ago
  Strong cryptographic keys should never be input using a keyboard and fingers, there are much better interfaces for that (security keys, passkeys, password managers).

deleted 4y ago

[deleted]

dakiol 4y ago

Is it a downside if the password is a 100 characters-long string?

doodlesdev 4y ago
A fellow cryptographer in the security board on stack exchange has shared their opinion on this: https://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pbkdf2-sha256/3963#3963 https://security.stackexchange.com/questions/3959/recommende... TLDR: No. In fact, theoretically stretching the password is more effective than increasing iterations. However, I don't see him citing the fact some password hashing functions have limited input size, which means at some point having a larger password doesn't really change anything.
bawolff 4y ago
Depends which characters they are. But in practise nobody uses 100 character long strings. Security is the intersection of real users with systems, not imaginary ones.
- jsjohnst 4y ago
  > But in practise nobody uses 100 character long strings. Multiple websites I use daily have that length of password or longer.
pmontra 4y ago
I was thinking that I keep my secrets at hand in my password manager of the Keepass family. I sync the db from my laptop to my mobile devices. The 100 characters password would be in the password manager but the secrets I would work with fit into the password manager, so I have no need to use a separate channel. I could upload the db, download it and just remember the master password. The only use case for this technology is when the secret is the file itself and it can't fit in the password manager. An image, a file, etc.