Hacker News Reader

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.

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.

mprime1 feel free to use or alter any of the content you agree with to update the documentation for your project.

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/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.

Right, agree with all of that. I would have characterized as "user can shoot themselves on the foot (i.e. by choosing weak password)", rather than "easy to bruteforce"

It's a perspective difference.

Each individual user perspective: "It is possible I can shoot myself in the foot, and also possible I will not. It is not correct to say I will shoot myself in the foot.".

Outside observer perspective: "Empirically, many users shoot themselves in the foot using this system. It is correct to say this system does not make feet safe".

It might be phrased better in terms of safety than security? The safety of the system is left up to the users, and is - to the best of our knowledge - not safe to use _as is_ by most people.

But users choosing a weak password on a standard rate limited service login is significantly different to choosing a poor password in something that the attacker has unlimited, low latency and undetectable attempts against.

I agree with the point about unlimited and undetectable. I think there's nuance to low latency.

Here the latency the attacker is limited by the amount of parallelism they can bring to bear on e.g. PBKDF. Ultimately this is an economic consideration about the cost to protect a secret vs cost to crack it.

> 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.

Don’t delude yourself. These phishing pages with mirrored login portals happen to podunk organizations all of the time.

If someone manages to get a link to your page and is interesting in the contents, duping it and sending a phishing link to the suspected password holder is a trivial spear phishing attack (with an annoyingly high success rate).

> 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.

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.

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.

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.

I disagree with your speculation as to what most cryptographers think. Are you basing this on any data you can share?

Please also see the other thread about how this secret storage system is different from a communication protocol. Namely, communication protocols have a two step attack: first attacker must MITM and record ciphertext, then they must wait. This secret storage method is different (one step attack): attacker looks for ciphertexts on either targeted or non-targeted basis that use old standard. Persistence, caches and publication of these secrets has been done for them.

It's a good point about downgrade attacks. They have been brutal for TLS to deal with.

> I disagree with your speculation as to what most cryptographers think. Are you basing this on any data you can share?

No, just conversations. I'll admit it's just speculation.

Maybe I should qualify: there's "cryptographic agility" in the protocol sense (a single version of a protocol can accept a wide range of primitives, with the idea being that users can upgrade their primitives as old ones become insecure), and there's "cryptographic agility" in a more abstract design sense: wire formats, etc. should be devolved from the primitives in such a way that the protocol can be switched to secure primitives without requiring unrelated changes, and in a way that doesn't surface any differences to the user.

To my understanding, the first sense of "cryptographic agility" is widely discouraged: we've yet to figure out a really reliable way to provide backwards compatibility without enabling malicious downgrades. The second sense is not something I've heard people use the phrase "cryptographic agility" for, but that's possibly just ignorance on my part. If that is indeed another form of agility, I believe that's widely considered to be good design (and this design is "agile" in that sense, since existing messages do not compromise the security of an upgraded scheme).

Agility does nothing to stop the "ciphertext from the past is broken due to crypto improvements". It's just a means to shorten response time to crypto breaks for _new_ traffic.

This project is plenty agile, upgrading the primitive is very easy as it's not a communication protocol but a data at rest protocol.

> this one doesn't have parameter negotiation and key management

You're thinking in terms of live communication protocols between endpoints. There is no "parameter negotiation" when you are both the sender and receiver of a static ciphertext.

There is no existing remediation for protecting your existing ciphertexts against future cryptanalysis.

I really do hear what you're saying and think you're making a great point.

The part that I think applies is that this is a "data at rest protocol". Communication protocols are assumed (but maybe shouldn't be - a la PRISM disclosures?) ephemeral.

As an attacker, I need to have been in the middle for that specific instance of the communication, and save it for decades, to attack it. Crypto agility shortens the window from a break or weakness to a fix, forcing any adversary who has not already recorded communication traffic to do so in a hurry.

In this setting as a "data at rest" protocol, the work to persist the ciphertext has been done for the attacker. If there's a weakness or break it's up the defender to clean up all copies of the old secret ciphertext that's out there and publish new ones. In cases where the secret has been cached (e.g. Wayback Machine) that may not be possible.

I hope you agree with this nuance that there's something the defender needs to consider. I agree with you that not all defenders will find this consideration will be decisive in their decision to use this method or not.

I just think it's a misleading analysis to say "this system is vulnerable to XYZ" without including the fact that ALL systems in this class are equally vulnerable. Crypto agility is not a thing that can be applied to encryption at rest.

It's similar to criticizing an alcoholic drink by saying "this drink will cause liver damage" as opposed to saying "this drink, like all alcoholic drinks, will cause liver damage"

Without that caveat people will see that criticism as evidence that other alcoholic drinks do not cause liver damage. The absence of words can convey the wrong impression.

*Edited for better clarity.

At this point I can not edit the top comment. I would have edited with something like: "this property is not an implementation bug but a design outcome shared with any deployment of cryptography that persists ciphertext data in public."

Of course in future I will endeavour for more clarity and hope others read into this thread.

>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.

Argon2-HMAC-SHA512 more like it? Or something else?

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.

Cool thank you - thought so, but always good to check :)

Please share this silver bullet pake with the rest of the class?

> 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?