6 ms·

This has some desirable security properties, but I would like to see more analysis on the security side (not just: is secure or is not secure). Passwords: - E

This has some desirable security properties, but I would like to see more analysis on the security side (not just: is secure or is not secure). Passwords: - Easy to memorize. Pro: Does not rely on a device, can be recovered if devices stolen. - Easy to phish. Con: Attacker can use a look-a-like page, click-jacking, and pixel extraction (frame stealing) attacks to get password & secret. - Easy to brute force. Con: Relies on human adherence to password best practices to maintain sufficient entropy. Learning from industry that this does not work in widespread adoption. This will work for certain power users. Cryptography: - Uses current state of art algos. Pro: Resistant to access by known methods. - Will become obsolete. Con: Eventually the secrets will become exposed due to advances in crypt-analysis. Mitigation: Don't store anything to remain secure for decades, shorter lived is okay. - Secrets are encrypted once. Con: Any issue (there have been many) in WebCrypto implementation at time of encryption can not be fixed by browser upgrade (because of secret caching). - Secrets can be extracted from page and cracked elsewhere offline. Note: Security features such as timers, throttling, guess limits can not be enforced. They must be implemented e.g. in PBKDF. Client Side Security: - Cached objects. Note: For example a web page with browser vulnerability can walk JS objects and get existing secrets. Browser may also cache secrets, passwords, inputs, images to disk where they are not protected. - Web Browser WebCrypto and Same Origin Bypasses. Pro: Browsers have updates and are constantly being improved to enforce security model. Con: The direction the W3C goes in future (tens of years) is not certain and security model may change. Implementation issues in browser web APIs and Same Origin (common) can put secrets at risk. - Secret hosting. Con: Hosting content on other servers (e.g. github) may not allow management of access control. For example hosting on one subdomain could now or in future allow JS on sister pages to interact with page and the resources loaded, enabling side-loading attacks in JS. This may not be in control of victim if they uploaded their secret to be hosted by another party. - Trusted hosting. Con: Any untrusted source of HTML can steal the secrets, e.g. by serving malicious javascript along with the secret. This means the security of the hosting party and trust in the hosting party is required. (Note: this con was added in an edit)

admax88qqq 4y ago
> Con: Eventually the secrets will become exposed due to advances in crypt-analysis You can claim this con for literally any crypto. And I'm not actually sure it's a reasonable assumption. Block ciphers seem to be pretty unbreakable so far. Even good ol Triple-DES is secure in practice barring some caveats (don't encrypt more than a certain amount of data) I'd wager if I gave you a real world message encrypted with AES with a strong key it won't be broken in our lifetimes.
- createdapril24 4y ago
  That's a good point, I wasn't very specific about this (trying to keep it concise). To be specific here, the con is that there isn't what the industry calls Cryptographic Agility. https://en.wikipedia.org/wiki/Cryptographic_agility https://en.wikipedia.org/wiki/Cryptographic_agility. It is not true this con applies to all cryptography (e.g. look at TLS). It has more to do with how cryptography is configured, parameters are negotiated and keys are managed, than with point-in-time choices about algorithms. The con here is that unlike other deployments of cryptography, this one doesn't have parameter negotiation and key management - and therefore doesn't have cryptographic agility. Re: "I'd wager that... AES..." is a also a good point. Modern cryptography has shown to be robust for decades and past their deprecation point. However, as you said, it IS a wager. There have been catastrophic failures of cryptographic primitives in the past. The con of this system is you will need to make a wager and tie yourself to the fate - you can't mitigate the risk if the catastrophic event comes or appears to be coming to pass.
  - woodruffw 4y ago
    Contrary to what Wikipedia says, I don't think agility is considered a desirable property by most cryptographers: you still have the "attacker stored encrypted material" problem, and now you have to worry about downgrade attacks. Many of the most interesting/effective attacks on SSL/TLS have been downgrade attacks that stem directly from the protocol's (historically) agile design.
    - createdapril24 4y ago
throwaway0x7E6 4y ago
> Con: Any issue (there have been many) in WebCrypto implementation at time of encryption can not be fixed by browser upgrade (because of secret caching). has there ever been an issue that made WebCrypto produce invalid ciphertexts/hashes/PBKDF output?
mprime1 4y ago
Thank you for the comment and thoughts. Agree with most, disagree with some (easy to brute-force?), but I wanted to comment on this in particular: > Easy to phish. Con: Attacker can use a look-a-like page, click-jacking, and pixel extraction (frame stealing) attacks to get password & secret This to me is the most glaring "vulnerability". i.e. I use this to exchange letters with my friend Bob. Now someone impersonates me and sends a fake 'PortableSecret' to Bob that siphons out the actual password. Clearly this is a valid vector of attack, and one I made no attempts at defending from. The thing is... this won't happen. If I'm dealing with an attacker so sophisticated to pull this off, it's likely they have 1000 other vectors that are more effective and dangerous. I have to keep reminding myself this is a real vector, but the fear is irrational. As they say at DEFCON to people too concerned using their devices: "Nobody is wasting their 0day on you". I don't think I'm a target valuable enough to attract this kind of attacker.
- createdapril24 4y ago
  I agree that each person/organization should look at the security properties of a system and assess their risk against what technology is appropriate. It's entirely reasonable that as a non-targeted person with low value secrets, many of the attacks here don't have ROI for a potential attacker and as a result are neither likely or impactful. What's important is that other persons and organizations who may be targeted - that they choose what technology to use, knowing what kinds of attacks are possible. For example a human rights activist might very well be targeted by phishing attacks and choose not to store secrets by this method. I am just trying to enumerate the properties so that persons/organizations can evaluate a match to their use case. I don't believe any system is perfect for all use cases and I don't hold any system to such a standard.
- createdapril24 4y ago
  mprime1 feel free to use or alter any of the content you agree with to update the documentation for your project.
- pwg 4y ago
  The GP comment about "easy to brute force" must be read in context with the remainder of the comment about "easy to brute force": "Relies on human adherence to password best practices to maintain sufficient entropy. Learning from industry that this does not work in widespread adoption" The GP's statement can be boiled down to: "users will choose poor passwords" (as in Password1!) because it has been shown time and again that "users will choose poor passwords" if left to their own devices to do so. The 'easy to brute force' part then comes in as "for those users who choose poor passwords, this rig linked below will brute force their passwords pretty quickly": https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27... Note that the above performance page is a few years old, updating it for 8x of a newer Nvidia GPU should result in even more impressive performance numbers. And in all fairness, any cryptography where a user chooses a poor password is then vulnerable to "easy to brute force" by a rig such as the one above. Not because the encryption algorithm is easy to brute force (usually it is not) but because the user picked a poor password, and that poor password itself is easy to brute force.
maqp 4y ago
>Uses current state of art algos. Pro: Resistant to access by known methods. AES-GCM is fine sure, but the password hashing function PBKDF2-HMAC-SHA1, i.e. what turns the user's weak password into the AES-key, is the opposite of state-of-the-art in this case.
- SgtBastard 4y ago
  Argon2-HMAC-SHA512 more like it? Or something else?
  - maqp 4y ago
    Argon2 is built on top of BLAKE2 but the hash function isn't what's making it so effective, it's memory hardness, i.e. it fills the RAM when deriving a key from password, which makes massively parallel attacks impractical because GPUs / ASICs don't have petabytes of RAM just lying around.
    - SgtBastard 4y ago
      Cool thank you - thought so, but always good to check :)
- bobkazamakis 4y ago
  Please share this silver bullet pake with the rest of the class?

admax88qqq 4y ago

> Con: Eventually the secrets will become exposed due to advances in crypt-analysis You can claim this con for literally any crypto. And I'm not actually sure it's a reasonable assumption. Block ciphers seem to be pretty unbreakable so far. Even good ol Triple-DES is secure in practice barring some caveats (don't encrypt more than a certain amount of data) I'd wager if I gave you a real world message encrypted with AES with a strong key it won't be broken in our lifetimes.

createdapril24 4y ago
That's a good point, I wasn't very specific about this (trying to keep it concise). To be specific here, the con is that there isn't what the industry calls Cryptographic Agility. https://en.wikipedia.org/wiki/Cryptographic_agility https://en.wikipedia.org/wiki/Cryptographic_agility. It is not true this con applies to all cryptography (e.g. look at TLS). It has more to do with how cryptography is configured, parameters are negotiated and keys are managed, than with point-in-time choices about algorithms. The con here is that unlike other deployments of cryptography, this one doesn't have parameter negotiation and key management - and therefore doesn't have cryptographic agility. Re: "I'd wager that... AES..." is a also a good point. Modern cryptography has shown to be robust for decades and past their deprecation point. However, as you said, it IS a wager. There have been catastrophic failures of cryptographic primitives in the past. The con of this system is you will need to make a wager and tie yourself to the fate - you can't mitigate the risk if the catastrophic event comes or appears to be coming to pass.
- woodruffw 4y ago
  Contrary to what Wikipedia says, I don't think agility is considered a desirable property by most cryptographers: you still have the "attacker stored encrypted material" problem, and now you have to worry about downgrade attacks. Many of the most interesting/effective attacks on SSL/TLS have been downgrade attacks that stem directly from the protocol's (historically) agile design.
  - createdapril24 4y ago

throwaway0x7E6 4y ago

> Con: Any issue (there have been many) in WebCrypto implementation at time of encryption can not be fixed by browser upgrade (because of secret caching). has there ever been an issue that made WebCrypto produce invalid ciphertexts/hashes/PBKDF output?

mprime1 4y ago

Thank you for the comment and thoughts. Agree with most, disagree with some (easy to brute-force?), but I wanted to comment on this in particular: > Easy to phish. Con: Attacker can use a look-a-like page, click-jacking, and pixel extraction (frame stealing) attacks to get password & secret This to me is the most glaring "vulnerability". i.e. I use this to exchange letters with my friend Bob. Now someone impersonates me and sends a fake 'PortableSecret' to Bob that siphons out the actual password. Clearly this is a valid vector of attack, and one I made no attempts at defending from. The thing is... this won't happen. If I'm dealing with an attacker so sophisticated to pull this off, it's likely they have 1000 other vectors that are more effective and dangerous. I have to keep reminding myself this is a real vector, but the fear is irrational. As they say at DEFCON to people too concerned using their devices: "Nobody is wasting their 0day on you". I don't think I'm a target valuable enough to attract this kind of attacker.

createdapril24 4y ago
I agree that each person/organization should look at the security properties of a system and assess their risk against what technology is appropriate. It's entirely reasonable that as a non-targeted person with low value secrets, many of the attacks here don't have ROI for a potential attacker and as a result are neither likely or impactful. What's important is that other persons and organizations who may be targeted - that they choose what technology to use, knowing what kinds of attacks are possible. For example a human rights activist might very well be targeted by phishing attacks and choose not to store secrets by this method. I am just trying to enumerate the properties so that persons/organizations can evaluate a match to their use case. I don't believe any system is perfect for all use cases and I don't hold any system to such a standard.
createdapril24 4y ago
mprime1 feel free to use or alter any of the content you agree with to update the documentation for your project.
pwg 4y ago
The GP comment about "easy to brute force" must be read in context with the remainder of the comment about "easy to brute force": "Relies on human adherence to password best practices to maintain sufficient entropy. Learning from industry that this does not work in widespread adoption" The GP's statement can be boiled down to: "users will choose poor passwords" (as in Password1!) because it has been shown time and again that "users will choose poor passwords" if left to their own devices to do so. The 'easy to brute force' part then comes in as "for those users who choose poor passwords, this rig linked below will brute force their passwords pretty quickly": https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27... Note that the above performance page is a few years old, updating it for 8x of a newer Nvidia GPU should result in even more impressive performance numbers. And in all fairness, any cryptography where a user chooses a poor password is then vulnerable to "easy to brute force" by a rig such as the one above. Not because the encryption algorithm is easy to brute force (usually it is not) but because the user picked a poor password, and that poor password itself is easy to brute force.

maqp 4y ago

>Uses current state of art algos. Pro: Resistant to access by known methods. AES-GCM is fine sure, but the password hashing function PBKDF2-HMAC-SHA1, i.e. what turns the user's weak password into the AES-key, is the opposite of state-of-the-art in this case.

SgtBastard 4y ago
Argon2-HMAC-SHA512 more like it? Or something else?
- maqp 4y ago
  Argon2 is built on top of BLAKE2 but the hash function isn't what's making it so effective, it's memory hardness, i.e. it fills the RAM when deriving a key from password, which makes massively parallel attacks impractical because GPUs / ASICs don't have petabytes of RAM just lying around.
  - SgtBastard 4y ago
    Cool thank you - thought so, but always good to check :)
bobkazamakis 4y ago
Please share this silver bullet pake with the rest of the class?