Add Dreamhost to this list.
Plain Text Offenders - Did you just email me back my own password?
121–130 of 147 posts
Re: Plain Text Offenders - Did you just email me back my own password?
#122Earlier quoted context omitted.
Capturing that information in a sign-up page that is served over https sounds an awful lot like the plaintext password is going to reach the server at which point the server will be mathematically capable of displaying it. That happens to defeat the entire purpose of this little subthread.
Your understanding of this subthread is very different from mine. I'm talking about practical security options for practical websites. In that case you don't care about information that was transiently present in the server for a fraction of a second once, you care about information that has been persistently stored. But if you want such a ridiculous requirement, you can have JavaScript on the signup form that comput…
We may actually be in agreement. I don't want such a requirement, it came from here http://news.ycombinator.com/item?id=2414550 and the link I first replied to, http://news.ycombinator.com/item?id=2414859
Your reply, coming where it did in the thread, gave the impression you thought digest auth somehow avoided ever sending a plaintext password to the server.
Re: Plain Text Offenders - Did you just email me back my own password?
#123Earlier quoted context omitted.
Not necessarily, if I understand the situation correctly. In this notation, -> represents communication between components, and | represents the boundary between local and remote communication, which we assume is encrypted/decrypted appropriately. On account creation, password -> hash -> | -> stored Upon account creation, I provide my password, which is hashed locally. The hashed version of my password is passed over…
That only protects you at account creation time. How about this: Password hash function is h. Client creates password p, hashes it 1000 times. Account creation: Client sends h^1000(p) to server in the clear. Server stores h^1000(p) in plain text. Attacker eavesdrops h^1000(p), which is useless. Log in: Client either looks up h^999(p), or calculates it from scratch starting at p. Client sends h^999(p) to server in the…
I believe you have just reinvented OTP, one time passwords.
Re: Plain Text Offenders - Did you just email me back my own password?
#124By far the worst example I can think of here is Yodlee, the bank aggregator. Their product, Moneycenter, has this convenient "feature" which lets you display your bank password in plaintext! It's unthinkable that someone you trust with your bank credentials would let their website be a two-way street for plaintext bank passwords. Things like this remove any confidence I may have had in their product. The fact that a…
How are they supposed to log in your sub-accounts without the password? They have no choice except to store the plain text password. And they don't just show you the password - they make you enter your login password first. What exactly do you want them to do? You aren't thinking this issue through. Do you just want them to hide the password from you ? What would be the point? They still have it. They also have a one…
I'm sorry but you're really not (a) paranoid enough and (b) thinking defensively (c) accepting the reality that users will make poor security decisions (d) recognizing that a service should do everything in their power to mitigate threats to their customers. Yodlee does a good job in many areas (security questions, special phrases and images, secondary password prompt for "riskier" operations) but still falls short here.
I realize that my credentials need to be efficiently convertible to plaintext at runtime within their service. They still shouldn't be stored in plaintext (it shouldn't be easy for engineering and operations staff to see my bank password by just looking at a database dump) though. In any case, I took the leap of faith that I trust Yodlee to keep my bank credentials secret when I signed up for their service in the first place. This is not what I was talking about.
I realize they force you to enter your password first. This is good but doesn't mitigate the threat I had in mind in the first place. It's Yodlee's responsibility to minimize the risk their service poses to their customers. Unless they can be 100% sure that the person signing in with my Yodlee credentials actually is me they need to consider the implications if it's not. Off the top of my head here are two obvious situations where Yodlee's "display plaintext password" feature puts users at higher risk:
1. User accesses Yodlee from a computer (maybe theirs, maybe their friend's, maybe a public terminal) which has a keylogger installed on it.
2. User is not security-conscious and doesn't realize the implications of this feature. Thinking Yodlee is read-only (like most other competing services) they use a weaker password than they should or even use the same password for Yodlee as on other sites. They shouldn't but it's a fact of life that they do.
In both cases the attacker can get the user's Yodlee password and then all of their bank passwords. They steal all of the user's money. Banks are generally willing to play ball and cover users for their losses if their account at that bank is hacked. Will they step up in the same way if they're hacked via Yodlee? I'm inclined to believe the answer is no. I don't even know if the bank should be expected to.
When choosing whether or not to build a feature, you need to consider whether its benefits outweigh its risks.
Trusting Yodlee with my bank credentials to aggregate financial data is a risk but doing so is the entire basis for their service and provides me with a huge amount of value. It enables scenarios which are otherwise completely impossible.
This "show plaintext password" feature is a small convenience which doesn't enable any new scenarios and has some pretty significant risks.
EDIT: I'm aware of the auto-login feature but didn't bring it up because it's almost the same as displaying plaintext passwords. Practically speaking it's a tiny bit less bad because an attacker can't directly view the password and use it on other services (assuming again that users make poor decisions and use the same password everywhere). Either way I think both should be gone.
Re: Plain Text Offenders - Did you just email me back my own password?
#125Earlier quoted context omitted.
How are they supposed to log in your sub-accounts without the password? They have no choice except to store the plain text password. And they don't just show you the password - they make you enter your login password first. What exactly do you want them to do? You aren't thinking this issue through. Do you just want them to hide the password from you ? What would be the point? They still have it. They also have a one…
I'm sorry but you're really not (a) paranoid enough and (b) thinking defensively (c) accepting the reality that users will make poor security decisions (d) recognizing that a service should do everything in their power to mitigate threats to their customers. Yodlee does a good job in many areas (security questions, special phrases and images, secondary password prompt for "riskier" operations) but still falls short h…
> They still shouldn't be stored in plaintext
So how are they supposed to get your data from your bank if they can't login to it?
> User accesses Yodlee from a computer (maybe theirs, maybe their friend's, maybe a public terminal) which has a keylogger installed on it.
Just change "Yodlee" to "your bank" and the same exact problems happen. There is nothing special about Yodlee here.
> User is not security-conscious ..... they use a weaker password than they should [on Yodlee]
And when Yodlee asks them for their bank's password they don't realize what's going on?
I personally _like_ that Yodlee is explicit in saying to you "We have your bank password, be careful with your login". As opposed to making it seem like they have some backdoor, or authentication token to your bank, which they don't.
It's exactly the opposite of what you think - by letting you know they have the password you will be more security conscious with them. If that feature did not exist you might think that they were a "read only view".
> .... auto-login feature .... Practically speaking it's a tiny bit less bad because an attacker can't directly view the password and use it on other services
Do you think it works by magic? How do you think it logs you in to the other site? It uses your password! It makes an auto submitting form that has your password in it, in plain text, right there in the javascript!
Re: Plain Text Offenders - Did you just email me back my own password?
#126Earlier quoted context omitted.
Your understanding of this subthread is very different from mine. I'm talking about practical security options for practical websites. In that case you don't care about information that was transiently present in the server for a fraction of a second once, you care about information that has been persistently stored. But if you want such a ridiculous requirement, you can have JavaScript on the signup form that comput…
We may actually be in agreement. I don't want such a requirement, it came from here http://news.ycombinator.com/item?id=2414550 and the link I first replied to, http://news.ycombinator.com/item?id=2414859 Your reply, coming where it did in the thread, gave the impression you thought digest auth somehow avoided ever sending a plaintext password to the server.
I was skimming the whole discussion and had missed that context. In that case I think we are in agreement.
Re: Plain Text Offenders - Did you just email me back my own password?
#127Earlier quoted context omitted.
I'm sorry but you're really not (a) paranoid enough and (b) thinking defensively (c) accepting the reality that users will make poor security decisions (d) recognizing that a service should do everything in their power to mitigate threats to their customers. Yodlee does a good job in many areas (security questions, special phrases and images, secondary password prompt for "riskier" operations) but still falls short h…
> They still shouldn't be stored in plaintext So how are they supposed to get your data from your bank if they can't login to it? > User accesses Yodlee from a computer (maybe theirs, maybe their friend's, maybe a public terminal) which has a keylogger installed on it. Just change "Yodlee" to "your bank" and the same exact problems happen. There is nothing special about Yodlee here. > User is not security-conscious .…
> So how are they supposed to get your data from your bank if they can't login to it?
Like I said, there's no requirement for credentials to be STORED in plaintext. They just need to be readily convertible to plaintext when they pull your data. I'm thinking about a system where credentials are encrypted and access to the keys are locked down (either via software or hardware) so that engineers and operations don't have unimpeded access.
> Just change "Yodlee" to "your bank" and the same exact problems happen. There is nothing special about Yodlee here.
Two things:
1a. Like I already said, many banks protect their users from losses incurred if someone gets hacked while using the bank's online portal. They'll bail me out if someone gets access to my account and takes all my money. Will they bail me out if Yodlee is used as an attack vector? That would be nice but I'm not convinced that banks/brokerages/etc. will step up and help me out in that situation. Ideologically I don't even know if banks should be expected to.
1b. Will Yodlee bail me out if an attacker uses them to steal all my money? Nothing on their website indicates that they will. Even if they did, implementing these risky features just adds more risk and uncertainty to their business for a feature which isn't ultimately that worthwhile.
2. Yodlee is special because they're an aggregator. That makes them a significantly more valuable target than one bank alone. I have various accounts at various places, if someone got access to one of them at least the damage is contained. With Yodlee they get everything at once.
> And when Yodlee asks them for their bank's password they don't realize what's going on?
You'd hope so but can't assume, you're not just selling to technical and security-conscious users. Most of Moneycenter is looks like it's dedicated to read operations. There are just a few innocuous-looking links in the account management section which opens up this whole can of worms. I came to Yodlee from Mint, who doesn't expose anything in their UI which would allow writes. That was my expectation because write access via this kind of service is unthinkable to me. After I explored a bit and realized this I removed all my accounts.
> It's exactly the opposite of what you think - by letting you know they have the password you will be more security conscious with them. If that feature did not exist you might think that they were a "read only view".
I get where you're coming from but I think this is a stretch. If they're really trying to be upfront with their users about what can and can't be done they would be more explicit than two links for "auto-login" and "show my password".
Maybe the disconnect is that I want a read-only financial aggregator (i.e. Mint) whereas Yodlee tries to do more... but from my brief experience with Yodlee I didn't really even see many things that directly did writes. Most of the value I saw was in the reading/reporting.
> Do you think it works by magic? How do you think it logs you in to the other site? It uses your password! It makes an auto submitting form that has your password in it, in plain text, right there in the javascript!
Sorry, I wasn't really clear in my haste to edit the last reply. I know auto-login is only trivially and superficially different from showing a plaintext password. That's why I didn't even mention it at first.
EDIT: Actually I think the current implementation of auto-login may be worse than showing the password in cleartext. IIRC the user doesn't have to provide Yodlee credentials a second time like they do to view their bank password.
Re: Plain Text Offenders - Did you just email me back my own password?
#128Earlier quoted context omitted.
If they use the same codebase that is on opensource wordpress they store the password as an md5 hash which isn't much better. Take a look at the wordpress source code one day, you'll be horrified.
I spent around two years working on some of the highest traffic Wordpress sites out there and I came to the Winston Churchill-like conclusion that Wordpress is the worst blogging platform out there, except for all of the others that have been tried.
I totally disagree, Habari's code base is far superior to wordpress in every regard it simply needs a larger user base. Try it if you are looking for a new blogging platform you'll be pleasantly surprised. http://habariproject.org
Re: Plain Text Offenders - Did you just email me back my own password?
#129Earlier quoted context omitted.
That only protects you at account creation time. How about this: Password hash function is h. Client creates password p, hashes it 1000 times. Account creation: Client sends h^1000(p) to server in the clear. Server stores h^1000(p) in plain text. Attacker eavesdrops h^1000(p), which is useless. Log in: Client either looks up h^999(p), or calculates it from scratch starting at p. Client sends h^999(p) to server in the…
I believe you have just reinvented OTP, one time passwords.
Geez, you're right. I went all the way through the Wikipedia article on cryptographic hash functions looking for something similar to what I'd just described, but there was no link to THIS:
http://en.wikipedia.org/wiki/Hash_chain
The resemblence is actually spooky. I swear I've never read that article before now.
Re: Plain Text Offenders - Did you just email me back my own password?
#130Earlier quoted context omitted.
If someone creates and conversation and re-uses a password, that password is emailed to everyone they invited. There is no way to avoid that and still use a group password. Edit: Furthermore, the password is not associated with a specific email address or user name. Even if someone has access to a conversation's password, they don't know who the password belongs to.
I don't know your use cases, so pardon me if this is naive, but couldn't you create a token that is unique for each user, and is consumed after use?
I'm not sure what you have in mind.
Our use case is explained on freeversation.com/about. Let me know if you have any questions.