3 ms·

I 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 t

I 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 ago
Yes, 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....
- xerophtye 13y ago
  yes so why in the world is my parent calling it a major design flaw? it's the norm! Sure, it's not perfect. Sure, a better option is to encrypt it yourself, and send it to the server. but as discussed endlessly in the comments here, it can NOT be done on web-mail currently (not securely atleast). So the common authentication mechanism is that you tell the server your password. Well you have to tell it to SOMEONE to show that you know it. So how is "transmitting your password" a flaw? The only other authentication mechanism i can think of is that your password is somehow used to generate a key-pair. The server encrpyts a session password with ur public key and sends to you. You decrypt with your private key and enter it. Hmm.... not a bad idea

jtheory 13y ago

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

xerophtye 13y ago
yes so why in the world is my parent calling it a major design flaw? it's the norm! Sure, it's not perfect. Sure, a better option is to encrypt it yourself, and send it to the server. but as discussed endlessly in the comments here, it can NOT be done on web-mail currently (not securely atleast). So the common authentication mechanism is that you tell the server your password. Well you have to tell it to SOMEONE to show that you know it. So how is "transmitting your password" a flaw? The only other authentication mechanism i can think of is that your password is somehow used to generate a key-pair. The server encrpyts a session password with ur public key and sends to you. You decrypt with your private key and enter it. Hmm.... not a bad idea