3 ms·
that doesn't mean there's no value in options like this Actually, your proposal has negative value, because the danger is you might actually go on to implement
by sillysaurus2 13y ago
that doesn't mean there's no value in options like this
Actually, your proposal has negative value, because the danger is you might actually go on to implement the broken design and trick people (along with yourself) into believing it's trustworthy.
a roll-your-own version would shift that trust burden from a US company to you or whoever sets up your server.
You've shifted the burden, but away from commercial pressure is almost always a bad idea. Now instead of having a team of people thinking about security issues 24/7 and paying strict attention to their server configurations and minimizing their attack surface, you have only yourself. You may be capable, but most people aren't. And even the very best of us make mistakes.
Once your server is breached, the security offered by this design drops to nil. Compromising the server compromises the security. That's a fatal flaw. It's no accident that all modern cryptosystems are based around the idea of "Here's your secret key. Don't let it get stolen." It's the strongest guarantee we have. It's incredible that it's even possible to get such a strong security guarantee: "As long as you don't let your private key get stolen or get MITM'd, it's impossible for anyone to eavesdrop on you." That's incredible! Governments for thousands of years have been wishing for such a thing, and now our generation finally has it, because we live in the future... and you're going out of your way to give it up.
Your design is literally "transmit your secret key to the server while hoping it's still under control of friendlies." This kind of thinking is dangerous precisely because it tries to frame blind faith / hope / "probably won't happen to me" as a security pillar. But it's not a pillar. You can't trust hope. Your trust is the very first thing any adversary will subvert. In fact, if the cryptosystem is designed properly, adversaries won't have any realistic route of attack short of physically compromising the boxes you're receiving secret messages on. By fooling yourself into believing in the myth of "better than nothing", you've opened up an attack vector for the adversary. If you were to use a proper cryptosystem, then the adversary wouldn't be able to attack you. And since you're opening doors for the adversary, it would not be unfair to characterize that as "you're doing the adversary's job for them."
I apologize for the negativity. Usually when people pick apart an idea, they're expected to present a better alternative. In this case I don't know what the better solution is, because it hasn't been invented yet. But you're talking about a cryptosystem. Cryptosystems fail silently, because adversaries break them without informing their victim. So all it takes is one misstep to completely lose: the adversary will be able to intercept everything, and you'll be none the wiser. By transmuting the trust guarantee from "don't lose your secret key" to "trust this central server," it exposes dozens of attack vectors. Every vector that leads to a server breach is now a vector that can subvert you.
- xerophtye 13y agoI agree with your views, but i am a little confused by something (probably due to my lack of experience in web dev). When i log in to any site, don't i always transmit my password over SSL? I know good security systems match the hash of my password. But that means they store a hash, right? or does that mean i also transmit a hash? I think we transmit the actual password because this way, if someone breaks into their servers, and steals the passwords, they'd only have he hashes and not the passwords. And that point is moot if the server takes the hash as input. Please enlighten me.
- jtheory 13y agoYes, with probably no exceptions, all of the sites you currently sign into will at some point have your username and cleartext password in memory on the server. The server "averts its eyes", hashes the password and compares it to a stored hash to check it. If you're lucky. If you're less lucky, your password is just in cleartext in the database. Note: if a website can send you a "password reminder", as many of them can, this is the case. Furthermore, your data won't normally even be encrypted (or with some, e.g. Dropbox, they will be encrypted with keys that are available to the server even without your password). Hosted Lavabit was a flawed system -- they were vulnerable to the NSA forcing them to start logging passwords/private keys, and they were vulnerable to the NSA capturing all of their SSL traffic then demanding their SSL private key. They were also vulnerable to a malicious employee or other person with legitimate access to the server code who snuck in a bit of logging code. But they were still far more secure than just about any other web application you'll encounter. If they had configured their SSL for perfect forward secrecy, the NSA could have even confiscated their servers but would have been unable to get any user's emails. They could have installed any code they wanted on the servers, but still would only have been able to break into accounts where the users actively signed in beyond that point. If someone managed to steal a data backup from Lavabit, it would not have revealed any data. That's not true of almost any other site. That's part of why I find it frustrating when I try to point out the value of a private, fixed up Lavabit and am scorned for advocating an imperfect solution. Well, yeah! But it'd be miles ahead of where your email is now....
- 13y ago