Go to security school, GoTo – theft of encryption keys shows you need it Remote access outfit GoTo has admitted that a threat actor exfiltrated an encryption key that allowed access to "a portion" of encrypted backup files. A third-party cloud storage service GoTo uses for its own products and affiliate biz LastPass was attacked in August 2022. GoTo and LastPass revealed the incident in separate …
SInce 1976, Alice and Bob have been able to use encryption WITH NO PERSISTENT KEYS, indeed with no transmitted keys and no public keys at all.
In the scheme they use (Diffie/Hellman) a secret key is calculated (briefly) at encryption time and is calculated (briefly) at decryption time, and in both cases the key is immediately destroyed.
(See refs below)
Maybe someone here can tell us why this scheme, or some similar scheme, cannot rid us of persistent keys......and rid us of the problem of key theft at the same time.
Ref: Applied Cryptography, Bruce Schneier --- Section 22.1
Ref: Cryptography Engineering, Ferguson/Schneier/Kohno -- Chapter 11
Because cryptography is hard ?
They coded and salted the hases, which is more than many do today. Not trying to find excuses, but they did better than most already.
You can always do more, especially where security is concerned. Maybe this "no persistent key" approach would break something else, or make everything more difficult ?
By what metric?
Better than their last 5 security face plants? Better than nothing?
We don't use their password manager thank god, but we did use their remote access tools at various points. When these breeches started to come up on people's radar in the security community, we straight up asked them(via our reps) if we were impacted, and to what degree. They straight up lied to us, on multiple occasions, and continued to do so for more than 6 months after the PUBLIC disclosure. They in fact knew for some time before that.
Their current competitors used a stronger architecture, had less critical bugs, less breeches with data loss, in the case of a breech came forward faster to alert their customers, and didn't serially cover up and lie about the breech, it's extent, and the community of impacted users. It is clear that this company has a pattern and practice of denying a known breech until it has been publicly proven and their cover is blown. Utter and nearly complete failure isn't better than most. I also don't trust the story they are telling today won't change next week.
This makes them possibly the least trustworthy actor in their market space right now. At this point I trust their management about as much as I trust Suckerberg testifying to congress.
DH is an online protocol. Both parties send messages back and forth in order to agree on a shared temporary secret.
When you encrypt backups, you are sending an encrypted message to your future self. There is no way for future-you to send messages back to current-you, so the communication only goes one way and you can't implement protocols like DH.
> There is no way for future-you to send messages back to current-you
I just got a message from future-you. He told me to pass on a message to you. He says:-
"Tell me to ignore what I said there, we figured out a way to sent a message to our past selves. Also, remember to invest in chicken giblet futures and whatever you do, don't let the alpaca near the alphabetti spaghetti on Valentine's Day 2023."
No idea what that last bit was about.
"There is no way for future-you to send messages back to current-you"
From what little I understand about quantum encryption, that possibility cannot entirely be ruled out. The quote I recall reading regarding quantum experimentation is that experimenters have come to accept the possibility that current experiments may affect past results.
Firstly, you keep claiming that Alice and Bob can communicate securely "with no transmitted keys and no public keys at all." but you refer to Diffie Hellman.
In the Diffie-Hellman protocol:
- Alice generates a secret key a, and a public key A = e**a
- Bob generate corresponding b and B.
- Alice TRANSMITS her PUBLIC KEY (A) to Bob
- Bob TRANSMITS his PUBLIC KEY (B) to Alice
- Alice computers B**a == (e**b)**a == e**ab;
- Bob computes A**b and they have a shared secret e**ab which they can use to encrypt data.
(Beware: the above is a gross simplification. Do not use this to implement DH.)
Secondly, you have also missed the point that this is _storage_ encryption. Communication (data in transit) can use ephemeral keys, but data-at-rest must be encrypted by keys that persist until the data is no longer required.
And I haven't even _started_ on the issue that DH is completely unauthenticated, so Alice has no way of knowing she is communicating with Bob and not Eve.
@MJB7
You are mistaking the TOKENS which Alice and Bob exchange (in public)......
........with the secret key which Alice and Bob CALCULATE as needed......and which is not persistent.....
The TOKENS tell the listening public absolutely nothing about a) the secret (calculated) key or about b) the encryption algorithm.
The question in the original post was: "Maybe someone here can tell us why this scheme, or some similar scheme, cannot rid us of persistent keys".
The answer, clearly, is "yes". Unfortunately it was the wrong question. You should have asked whether, if someone told us, you would be capable of understanding the answer.
Because it is data at rest, or are you proposing somehow to continuously re-encrypt data at rest?
If the data is static (at rest) the key is static, you could move it, if you liked to something like a diffie/hellman approach, but all you are doing is changing how the attacker gets the key. If they were able to get the key before, they would be able to get the public/private key values (diffie/hellman is a public private key implementation) that were used to derive the encryption key for the data.
Diffie/Hellman only helps establish an encryption key between 2 parties, the 2 parties here is the data at rest and the system wanting to decrypt it. Both of which the attacker in this case compromised (being the same place).
Diffie/Hellman also has no way to ensure that the public keys shared are infact from who you think they are from (man in the middle), that needs a 3rd party (signing, like a CA) or a shared secret. So, persistent keys yet again, one implementation is STS.
Not a fan of LastPass, found it horrible to use, and I'm not suggesting for a second that they're any good (especially given the fact they didn't come clean about this stuff for a while) but at least there are no empty platitudes about "taking security seriously" in the article for once.
Probably because a chink was found in LastPass first, so the hackers simply homed in and chewed...
Suspect all the others are currently breathing a sigh of relief it wasn't them and keeping a low profile - noticed how no one seems to have jumped in and attempted to attract dissatisfied LastPass users, so suspect the majors are quietly reviewing their security and logs going back as far back in time as their records permit. ie. I suspect none of them can put a hand on the heart and say they haven't been hacked.
That is ElReg (other reputable publications are doing similar) recommending a product, it isn’t Bitwarden saying they are better than Lastpass.
I suggest given the latest disclosures about GoTo’s cloud storage and archives, I suggest any review of security products such as Bitwarden now need to include a full security audit of the service and their development and operational practises.
You find the weak spot aka chink in the armour, you then workout how to exploit it.
What is clear here is (from the GoTo disclosure on top of the LastPass disclosure) that LastPass, like many, did not have ‘walls’/clear separation between Dev and Production environments, hence why hackers found security details for the production environment in their haul from a compromised dev account.
Suspect we need something like NAMAS accreditation for vendors of security products and services, which covers such basic operational security matters.
Both in the remote access space and in the password managers space. 1pass and several of the other commercial and especially cloud password managers have been hit.
They were more up front about it though. LastPass has been right up there with WiFi security protocols for moving from one flawed security framework to another. Other than ROT13 I can't think of a mistake they HAVEN'T made. At least with most of the other password managers the clients whole vault was encrypted with a passphrase the cloud was supposed to never see.
But they have been less than honest dealing with the public, the their customers, and apparently their shareholders about this stuff. So in a few years we can expect a string of articles on the lawsuits, fines, etc.
but fair is fair.
They used to be a lot stronger, both as a product and as a company. Over the years the marketroids won and forced the implementation many of the same risky cloud features that they avoided in their earlier years. The gift to their customers was a string of hacks, leaks, and CVE's.
Even for all that at least they keep the whole vault under a client controlled master password, but I've never trusted the web based cloud access or logins as a result. They also tried to hoover up passwords from local vaults into the cloud on a couple of the client versions. It isn't cheap, but it supports shared vaults, and is cross platform, so I can't say write it off entirely, but I'd suggest one of the open source password vaults if you don't need all of those features.
Not as pretty, but much less likely to screw you over either.
We need to burn the whole space to the ground and go to something like passkeys. Passwords suck, and have for some time. There is no "fixing" them, or the innumerable ways developers will find to screw them up. (I just ran across a site that kept kicking passwords back due to a complexity requirement for a "special character" that also excluded many normal characters like - or _ without prompting what the "valid" ones were.)
Yes, passwords suck.
Passphrases suck a bit less, but they still stuck.
Biometrics suck. MFA schemes using smartphones – fragile, loss-prone, theft-prone, attack-surface-laden smartphones – suck, really hard.
Passkeys are more resistant to exposure and brute force, but they're lousy for multiple-device use, and bad for many shared-account use cases, particularly for things like emergency recovery when the primary user is not available (e.g. due to death). My wife and I have a whole bunch of shared accounts because our finances and possessions are commingled, and managing credentials for those is a real problem. Passkeys do not help with that.
The fact is that all authenticators suck. While many in the IT security field (the editors of SANS NewsBites, for example, have been bigging up passkeys and smartphone-based MFA for years) are so sick of passwords that they'd take anything else, the fact is they're exchanging one set of weaknesses and failure modes for another. That doesn't mean one of those tradeoffs isn't an improvement – but there's no silver bullet, and there will be problems with any authn scheme. Authentication is a hard problem and we have not solved it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
