6 ms·

Pingdom is storing passwords in plaintext

141 points by seldo 15y ago

ddlatham 15y ago
They are not necessarily storing the password in plaintext. However, they are: 1. Storing it in a recoverable format, instead of a format that only allows verification. 2. Emailing them in plain text. Both of which are bad.
- shubber 15y ago
  Just to be clear: there is no significant difference between either of these and simply storing in plaintext. "In a recoverable form" means that a) there's a single key with which to decrypt the passwords. If I can get the password list, the key isn't far away. And it might not be worth the effort to track it down, since it's practically equivalent to have the (two-way) encrypted passwords and to have the plaintext.
  - viraptor 15y ago
    Playing devil's advocate, but this still prevents lots of web-based attacks. Provided you store the encryption key on the filesystem, or in memory and the encrypted passwords in the database usually you'll get access to only one part. But it gets better! If you have access to the encrypted passwords, but not the key, then they're safer than hashes, since the attacker cannot try to bruteforce them (he could try bruteforcing a very very long encryption key of course...)
    - Xk 15y ago
      No. If an attacker gets access to the database, chances are very very good they can get access to the key as well. Very few services correctly separate privileges well enough that an attacker can not gain more access once they have database access. However ... for the sake of argument, just pretend there's only a 50% chance the attacker can get access to the key. Would you rather there be a 50% chance that you leak EVERY password in the database (regardless of strength) or would you rather lose the people who pick passwords in the 5% because you've used bcrypt?
      - cHalgan 15y ago
        If you are storing something in database which needs to be decrypted (i.e., you are storing credentials to access some other system) it is common sense not to have that key in the database. The key should be provided to your application on startup. Or sometimes, the key can be in the wallet and that wallet can open only during startup of the application: application should prompt admin to enter password needed to open the wallet. At least that how I design my systems... Maybe I'm wrong...
        theBobMcCormick 15y ago
        Prompt the admin for a password? So there's no way to do an unattended reboot of the application? That doesn't sound very practical.
        cHalgan 15y ago
        Hey... If you want to be secure that what you need to do. The keys must not be easily accessible. Anyway application which need to be secure are not the one you also would like to be restarted automatically or unattended: automatically restart can in many cases just make situation worse (i.e., data corruption) You can always pay big bucks and use Oracle Database with Transparent Data Encryption: in that case, you need to enter password to open the wallet only on startup of a database.
        deleted 15y ago
        [deleted]
        ceejayoz 15y ago
        We're required to have our sensitive data on an encrypted volume by a client (a major financial firm). Sometimes, calling the 24/7 techs to enter a passphrase is a perfectly appropriate solution, especially if you have enough capacity to let a server or two wait until the morning.
    - tptacek 15y ago
      In the most likely implementation of reversably encrypted passwords, an attacker who gets read control of the database can trivially brute-force passwords. Encryption isn't magic. But in the meantime, I'm curious about what web-based attacks relevant to password storage reversably encrypted passwords protect against. Were you thinking SQLI? Because I do not believe this to be the case. Don't store reversably encrypted passwords.
      - deleted 15y ago
        [deleted]
        tedunangst 15y ago
        I don't see how rainbow tables are relevant. How would you use a rainbow table to crack passwords encrypted with an unknown key?
        deleted 15y ago
        [deleted]
        16s 15y ago
        You couldn't. It's not possible. If you don't know, then it's not possible to pre-compute. Many people fail to understand that. Rainbow tables (while sounding magical, are not). Edit: But they are great for standard unsalted hashes. md4, md5, sha1, sha512, etc.
      - tedunangst 15y ago
        Let's assume I store base64 encoded versions of encrypted passwords in my database. The key is 128 random bits in a file in the filesystem. How does sqli get you anything useful? Why do you not believe that's "safe"? (let's ignore other attacks or better solutions. Just sqli) Update: from other posts, I'm guessing you're assuming that anyone with sqli has other problems too, and that's why you don't think it's safe from sqli?
        gkop 15y ago
    - dpark 15y ago
      > Playing devil's advocate, but this still prevents lots of web-based attacks. Provided you store the encryption key on the filesystem, or in memory and the encrypted passwords in the database usually you'll get access to only one part. Why would you assume this? It's entirely possible that a compromise will allow file system access, which will give the DB and the key. As for memory storage, you've got to have the key somewhere so that the machine can restore itself after a reboot. An in-memory-only key isn't a very practical solution. It's also entirely possible that you memory-only key will find its way to the swap file, again vulnerable if FS access is gained. > But it gets better! If you have access to the encrypted passwords, but not the key, then they're safer than hashes, since the attacker cannot try to bruteforce them (he could try bruteforcing a very very long encryption key of course...) This isn't necessarily true. Hashes are not intrinsically easier to break than encryption. Some hashes (such as bcrypt) are based on an encryption anyway.
      - tedunangst 15y ago
        I'm not aware of any operating system that allows perusal of swap through the filesystem. That'd be a pretty serious hole.
        dpark 15y ago
        I should have clarified that I was referring to accessing the swap as root. This also requires another privilege escalation, and is a separate issue I probably should have left out.
      - cdcarter 15y ago
        you've got to have the key somewhere so that the machine can restore itself after a reboot In many very secure systems, this "somewhere" is in the brains/completely secondary data stores of a group of admins who enter that key when a reboot occus.
        dpark 15y ago
        I think it's unlikely enough to ignore it here, though. Is someone who's willing to send an email in plaintext going to do this? Why bother when simply hashing would do the job more effectively? I agree it's possible for high security situations where passwords need reversibility, though. e.g. I wouldn't be surprised if Intuit used a system like this when they store passwords for external services. (They should still be hashing users' primary passwords, though.)
  - pbreit 15y ago
    Yes, there is. In most companies, the database is significantly more accessible than any encryption keys. For goodness sake, marketers typically have query access to the DB. And the issue of emailing a password is different. The problem there is that if I gain access to your email account, I can quickly search "password" to discover your private passwords that a company, not you, chose to drop into your email account. But to be clear, user-created passwords should be stored one-way hashed and never emailed.
    - shubber 15y ago
      Trying not to be pedantic, but this is something everyone should know. If I can pull a list of two-way encrypted passwords, breaking that is way faster than extracting passwords from a properly crypted list. Essentially it's a huge list of short (almost known plaintext) messages. If you know a cryptosystem that will resist attack in that circumstance, please share. Properly crypted, passwords admit to local brute forcing, which is bad for any particular account. "Recoverable" passwords, the whole list admits to statistical attacks that break the whole list.
    - AgentConundrum 15y ago
      > For goodness sake, marketers typically have query access to the DB. That's a bit of a straw man, don't you think? Even if marketers have access to the database, they shouldn't have read access to the passwords table in a properly configured system. If they do, it's time to fire your DBA. > The problem there is that if I gain access to your email account, I can quickly search "password" to discover your private passwords Sometimes it's worse than that. I recently had to do a password recovery on a site, and they sent the password not only in plain text but also as the very beginning of the email. As such, gmail helpfully showed "example.com" as the sender, with "Password: P@ssword1" right in the body preview snippet. You could see it without even having to open the email. It may not be a common exploit, but if I was checking my gmail at work, a coworker that knew I had an account on this website could just send a recovery request and glance over my shoulder at just the right time and grab my password without my knowledge. Not good. I wish Google would implement some sort of algorithm that could determine password-looking text and a) not show it in the preview, and b) require user interaction to display it when viewing the actual email body.
  - desigooner 15y ago
    I had to ask this as I am dealing with a DotNetNuke based system right now which stores authentication details in a table (aspnet_membership) with the passwords encrypted with a private key (in web.config in IIS) and a password salt. How would one go about securing such a system where there is no option but storing encrypted passwords that are reversible?!
    - deleted 15y ago
      [deleted]
    - aaronblohowiak 15y ago
      > "How would one go about securing such a system where there is no option but storing encrypted passwords that are reversible?!" Change the system.
      - desigooner 15y ago
        I wish it was that easy. Working in higher ed means dealing with legacy and proprietary systems at low budgets. "Change the system" isn't always the option in the real world a lot many times.
    - ams6110 15y ago
      You can change it so that DotNetNuke (really aspnet_membership) uses hashed passwords. They are then not recoverable, but DotNetNuke will allow a user to request a new password which is then emailed (rather than a slightly safer "reset password" link)
  - coin 15y ago
    > If I can get the password list, the key isn't far away. What makes you think the key isn't far away?
    - po 15y ago
      Because the email server (or application server or whatever is creating the text for that email) can access it to decrypt it. If that server gets hacked, then you can decrypt all of the passwords.
    - jws 15y ago
      As an example: The password list might consist of entries encrypted with a public key. The private key might only exist on an air gapped laptop with its communication ports filled with epoxy in a secured facility using trusted humans to enter the encrypted password and retrieve the decrypted plaintext. I have no reason to believe the above is true, but there is also no reason to automatically believe there is a mechanism available to attackers of a compromised machine to decrypt all encoded materials on the machine.
- ajross 15y ago
  Recoverable passwords are what everyone means when they say "plaintext". You're positing a distinction that doesn't exist.
  - ddlatham 15y ago
    That's not true. Some people say "We keep your password encrypted" instead of in plaintext, and make the dubious claim that they are then safe. It's good to help them understand the distinction that even if the passwords are encrypted, it's still a problem if they are recoverable.
  - ceejayoz 15y ago
    There's absolutely a distinction. Reversibly encrypted passwords aren't ideal, but it does at least make a database dump less useful to someone who manages a SQL injection exploit.
    - tptacek 15y ago
      No, it means that getting the actual raw passwords is now a fun little puzzle for anyone who gets SQLI. News flash for the (hopefully small) collection of people who may be kidding themselves on this point: unless you've gone to significant lengths to mitigate this specific problem, if you give up the SQL for your website, you've probably given up the box, too. How likely is it that you're THAT company, the one that hardened their database server and app architecture so that it can survive someone who compromises SQL, and that you actually have SQLI? And, if you're THAT company, how likely is it that you're storing reversably encrypted passwords? And if you're THAT company, how likely is it that you're simply mailing them back to customers on request? It's not likely.
      - ceejayoz 15y ago
        One would hope that the encryption key wouldn't be in the database. The point remains - there is a benefit to reversibly encrypted passwords versus plaintext ones. It's certainly not ideal, but it's better than nothing.
- hackinthebochs 15y ago
  What exactly is the reason emailing the password is bad (ignoring the plain-text-in-database issue)?
  - bricestacey 15y ago
    Email is traditionally transferred using unencrypted connections. Once in your mailbox, email is often saved and/or indexed for easy search, which is often unencrypted and/or outright unprotected. And worse, your email provider can discover your password by simply signing in as you.
  - ceejayoz 15y ago
    I once opened a password reset e-mail from my (former) bank while at work and wasn't hugely pleased to see my password pop up in plain view for a coworker to see.
  - parfe 15y ago
    Lets say you want to give the user a 1 step process to get back into their account. You can 1) Email the password or 2) Email a unique link which lets them reset the password for their account. If you do #1 the person likely used that password on other accounts. Now you've not only compromised access to your service, but any other that has the same password. IF you do #2 the user sets a new password and gets into his account. No record of the new password is left anywhere. An attacker with access to the email account can still compromise your service, but now he has no idea what the old password was.
    - gte910h 15y ago
      #2 is important as people share passwords like mad. Secondly, the link can expire after a certain amount of time.
- tlianza 15y ago
  > 2. Emailing them in plain text. Even if the password were irreversibly encrypted, if I can read your e-mail, I can still access your account in most systems. I can reset your password, and either follow the link they e-mail you, or see the random password they generated for you. I think #2 is more on you for accessing your e-mail securely, and less on Pingdom. Pingdom is only saving a hacker a little bit of time.
funkah 15y ago
Emailing the password is bad and they should stop, but where is the evidence that they are storing the password in plaintext?
- dpark 15y ago
  The fact that they sent it in an email in response to a user request means that they are at least storing it in a reversible format. Given that they sent the password in plaintext via email, I see no reason to believe they are competent enough to set up a reversible system that is more secure than plaintext (e.g. rot13 isn't more secure but isn't technically plaintext; storing an encrypted password with the key isn't more secure). In all likelihood, they are storing in plaintext or an equivalent.
  - coin 15y ago
    reversible != plaintext
    - dpark 15y ago
      Could you not be bothered to read my comment before replying?
- webignition 15y ago
  The story only details the sending of a password in plain text. You are right in that this provides no evidence of the password being stored in plain text. It is equally plausible, without further evidence, that pingdom is merely changing the password (a likely case if the password is not retrievable) and emailing the new password. I tested this with my pingdom account for which I know the password. The email I received contained my password and not a new password. This confirms that pingdom is storing passwords in a retrievable fashion, whether that be plain text or some form of non-one way encryption.
- 16s 15y ago
  It's not inherently bad. It's a trade-off between security and convenience. Believe it or not, most of the time, business managers are far more concerned about the user experience and the convenience of use rather than information security. It's not black and white. It's a decision with trade-offs either way.
tbeseda 15y ago
You can remove your account from the Subscription page of your account.
- fourk 15y ago
  Is there any guarantee that this actually entirely removes your data from their databases? How do you know they don't just toggle an `active` column for your row in the users table?
bdhe 15y ago
Obligatory link for those who haven't seen it before but want to know the right way to do it. http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
- delano 15y ago
  We implemented this (bcrypt) for https://www.blamestella.com/ https://www.blamestella.com/ (a web monitoring service for devs and designers)
  - rwolf 15y ago
    Your use of the word "implemented" gives me pause. I hope you mean "We've plugged the standard bcrypt library into our web app." and not "We found a pdf describing bcrypt on the internet and one of our 'rockstar ninja warlock' devs stayed up for a week writing an implementation that no one else is using and no one has reviewed."
    - delano 15y ago
      Ah yes, of course we didn't implement our own bcrypt!
hm2k 15y ago
Your bank stores passwords in plain text, but then they never email it to you.
- feydr 15y ago
  some do like discover.com (unfortuantely) truncates your password at 8 characters, downcases, and sends you in plain txt email
  - gst 15y ago
    That's what I don't understand about banks. On 99% of all websites I can use special characters in my passwords. The only exception are my online banking sites, where I'm forced to restrict myself to [\d\w] one one of the sites and to [\d] on the other site.
    - dennisgorelik 15y ago
      Government's security regulations that banks must follow make banks less agile. That in turn make banks security system weaker. These are unfortunate unintended consequences.
fourk 15y ago
It would be nice if there existed a browser extension that would warn the user anytime they are about to register on a site with password storage issues like this. Of course, there would need to be some sort of community maintained repository for tracking which sites are doing this.
- gst 15y ago
  Why should it warn the user? Either the user is using the same password on multiple sites. Then this would be a real security issue, independent of the fact if some of the sites store the password in plaintext. Or the user is using different passwords for different sites. Then you don't really need to care how a single site handles your password.
  - fourk 15y ago
    If every user used different passwords on every single site, this submission would be hardly newsworthy and barely discussion worthy. In a perfect world, sure, every user would have a unique 14+ character password for every site they register on. In a perfect world, every site would implement basic password encryption. Unfortunately, reality != perfect world.
  - axomhacker 15y ago
    Or... The user usually uses the same password, but seeing this warning and gets alarmed, making him use a different password or not use the service. I love this idea!
  - ddlatham 15y ago
    One reason is that if they are storing the password in a recoverable format, it tells you something about how much you can trust the security of that site in other ways. Even if you're using a different password, you may be much more hesitant about what other information you are willing to put into a site that doesn't take security seriously.
  - srl 15y ago
    Either the user is using the same password on multiple sites. Then this would be a real security issue, independent of the fact if some of the sites store the password in plaintext. Nevertheless, the vast majority of users do - and that's unlikely to change in the near future. It's just too easy. Many users (the majority? I've seen no statistics for this, but everybody I know falls into this group) do, however, keep several passwords, and assign them to sites based on a combination of 1) how likely the site is to compromise the password (sites that email out plaintext score very poorly) and 2) how much the user cares about the security of that particular account. Which suggests the following use case for fourk's hypothetical plugin: user wants to know what password to use, sees that fooneti.cs is one of those sites that stores easily recoverable passwords, and chooses to use one of the disposable ones.
juiceandjuice 15y ago
Also... Equifax also stores your password in plain text.
- cpeterso 15y ago
  [citation needed]
  - juiceandjuice 15y ago
    I hope it wasn't you that downvoted me. http://news.ycombinator.com/item?id=2865719 http://news.ycombinator.com/item?id=2865719 You'll have to take my word I think though... the password blacked out is my password.
    - cpeterso 15y ago
      Wasn't me. I figured it must be true; I just wanted to learn more. :)
BrandonDC 15y ago
Password security is a shared responsibility between the company storing the password and the user who chooses what password to store. As a user, you rarely know the full extent to how a company manages the storage of passwords so the responsibility truly rests on your shoulders to choose unique passwords for each service that you use.
- dpark 15y ago
  This is simply not realistic. I've got hundreds of accounts online. I cannot remember a truly unique password for each. It's not possible (not for me at least). I can't even remember all the sites I've got accounts. A lot of people implement their own hash ("I use a base password plus the second letter of the url and the number of letters in the domain: dumbe18"), but this is not unique per site, and these hashing schemes don't tend to be as unique or as hard to figure out as one might imagine. There are utilities now that try to help, but I've not found one that's even remotely convenient when it comes to accessing sites on multiple computers, my phone, and my tablet. Not to mention I'm putting my trust in a 3rd party to handle all of my passwords when I do this.
  - BrandonDC 15y ago
    Personally, I think it's more realistic to place your trust in one verifiable source (i.e. using the cross-platform KeePass with the encrypted database stored on Dropbox) than assume that "hundreds" of different organizations are all going to implement adequate authentication strategies. What seems oddly unrealistic to me is that if one company exposes your password, you now have to not only remember all of the hundreds of sites you have accounts on, but log in to each one and change that one password that you always use.
    - dpark 15y ago
      I agree the current system is broken, but asking users to remember hundreds of passwords is no less broken. As for KeePass, the problem is that I can't get integration with a browser on my phone or tablet, so I'm left jumping back and forth between apps every time I need to log into something. Not to mention there's no official KeePass implementation for the Mac (unless I want to run on Mono). I also frankly think it's unnecessarily complex, but maybe I should give it a try again. I really don't understand how you can take the stance that it doesn't matter if a site has proper password security. Why are you bothering to use KeyPass if you don't care about security in the first place?
ErikRogneby 15y ago
I'd like to see these questions added standard to VC pitch meetings: 1)How do you store passwords in your datastore? plaintext? 2)When users login to your service and provide their credentials is it over SSL?
- fourk 15y ago
  I'd be interested in seeing the correlation between return on investment and level of basic security-related competence at the point at which the company first attempted to raise VC money.
  - tptacek 15y ago
    It's probably negative. A dollar spent on security is a dollar not spent on customer acquisition. Don't put security in your slide deck.
ErikRogneby 15y ago
crunchbase has a nice list of competitors: http://www.crunchbase.com/company/pingdom http://www.crunchbase.com/company/pingdom Watchmouse appears to have some pretty high end customers. (including twitter, AT&T and verisign )
jfong 15y ago
This probably happens more than we think.
ck2 15y ago
One of many that might surprise you: http://plaintextoffenders.com http://plaintextoffenders.com
- coin 15y ago
  How do you know the "offenders" are storing in plaintext?
  - johnx123-up 15y ago
    The detection process is somewhat wrong. In many sites, they store passwords in plaintext or reversible plaintext--but they send mere link to reset. So, you don't really know, how they're storing. IMHO, most of new startups store passwords for the sake of learning. Definitely, there needs to be some disclosure on how they'll store passwords.
IgorPartola 15y ago
Shameless plug/seizing the moment: Ping Brigade (https://www.pingbrigade.com/ https://www.pingbrigade.com/) does everything over HTTPS, stores passwords using bcrypt and never emails them to you. Moreover, because I really love HN, I'm going to run a 50% off discount at https://www.pingbrigade.com/signup/hn https://www.pingbrigade.com/signup/hn. Edit: Wow, that was a quick downvote. Just wondering since when is building a better product than the giant of the industry and showing it off on HN compels people to click the downvote button?
- decadentcactus 15y ago
  I think some will consider it a _bit_ unnecessary. I upvoted you, gotta seize those moments when they come :)
  - IgorPartola 15y ago
    Thank you :)
- cookiecaper 15y ago
  I think it's cool. People are silly. Don't be afraid to leave messages like this where relevant.
lurkinggrue 15y ago
They brute force attack your password hash and then mail it to you.
drewjoh 15y ago
LiquidWeb also does this from my experience. Sign-up for a new account and have them call you for verification. Their verification question is "What is your password?".
cookiecaper 15y ago
As we see from this thread, people really need to stop assuming that a site will store their password securely. Find a system that allows you to use a unique, random password for each site and use that instead. Do not trust any site to store your password in a secure fashion as relatively few actually do. If someone can get into the password database on a site, it probably doesn't matter if they have your password or not, because they can usually still access everything directly anyway by looking up your user id and performing the relevant queries. The danger in plaintext storage is that your password to other valuable sites may be exposed by a leaked database dump or similar. This is not a concern if you use a randomly-generated unique password for each site you visit. Everything is just much safer this way. With some companies making kind of legitimate arguments for plaintext password storage, just assume that your password is NEVER secret to the admins of a site or anyone who may break in and steal their information. Things would be much nicer for everyone involved if we did this. There are systems in place that make this pretty easy. Personally I use a home-grown method: pwgen -c xx, copy and paste the coolest-looking password displayed, email to myself encrypted, and decrypt with my secret key and copy and paste any time I want to use a site. There are also things like LastPass, KeePass, websites that generate hashes of passwords salted with another phrase or target site URL (copy and paste final output), websites that output a simple character lookup table based on a user phrase, etc. I believe that an interested party could make one of these things work well enough for use among the general people (especially with automated sync platforms from Google and Mozilla). We need to stop relying on anonymous third parties for our personal safety.
- joelmama 15y ago
  You are right. But again, speaking about Pingdom...they are monitoring company...if they treat our password in that way, how do they treat our other private data...We are putting there our http passwords, right? This is a good way to find out if you should really use some service, or not.
- 16s 15y ago
  I encourage people to use SHA1_Pass. I wrote it and provide full source code under the GPL license. It's free as in freedom and beer. I use it because (as you stated) sites don't do the right thing and have other priorities. As conscientious users and devs, we have to take matters into our own hands.
j15e 15y ago
Told you so a year ago : http://news.ycombinator.com/item?id=1118012 http://news.ycombinator.com/item?id=1118012

141 points by seldo 15y ago

They are not necessarily storing the password in plaintext. However, they are: 1. Storing it in a recoverable format, instead of a format that only allows verification. 2. Emailing them in plain text. Both of which are bad.

shubber 15y ago
Just to be clear: there is no significant difference between either of these and simply storing in plaintext. "In a recoverable form" means that a) there's a single key with which to decrypt the passwords. If I can get the password list, the key isn't far away. And it might not be worth the effort to track it down, since it's practically equivalent to have the (two-way) encrypted passwords and to have the plaintext.
- viraptor 15y ago
  Playing devil's advocate, but this still prevents lots of web-based attacks. Provided you store the encryption key on the filesystem, or in memory and the encrypted passwords in the database usually you'll get access to only one part. But it gets better! If you have access to the encrypted passwords, but not the key, then they're safer than hashes, since the attacker cannot try to bruteforce them (he could try bruteforcing a very very long encryption key of course...)
  - Xk 15y ago
    No. If an attacker gets access to the database, chances are very very good they can get access to the key as well. Very few services correctly separate privileges well enough that an attacker can not gain more access once they have database access. However ... for the sake of argument, just pretend there's only a 50% chance the attacker can get access to the key. Would you rather there be a 50% chance that you leak EVERY password in the database (regardless of strength) or would you rather lose the people who pick passwords in the 5% because you've used bcrypt?
    - cHalgan 15y ago
      If you are storing something in database which needs to be decrypted (i.e., you are storing credentials to access some other system) it is common sense not to have that key in the database. The key should be provided to your application on startup. Or sometimes, the key can be in the wallet and that wallet can open only during startup of the application: application should prompt admin to enter password needed to open the wallet. At least that how I design my systems... Maybe I'm wrong...
      - theBobMcCormick 15y ago
        Prompt the admin for a password? So there's no way to do an unattended reboot of the application? That doesn't sound very practical.
        cHalgan 15y ago
        Hey... If you want to be secure that what you need to do. The keys must not be easily accessible. Anyway application which need to be secure are not the one you also would like to be restarted automatically or unattended: automatically restart can in many cases just make situation worse (i.e., data corruption) You can always pay big bucks and use Oracle Database with Transparent Data Encryption: in that case, you need to enter password to open the wallet only on startup of a database.
        deleted 15y ago
        [deleted]
        ceejayoz 15y ago
        We're required to have our sensitive data on an encrypted volume by a client (a major financial firm). Sometimes, calling the 24/7 techs to enter a passphrase is a perfectly appropriate solution, especially if you have enough capacity to let a server or two wait until the morning.
  - tptacek 15y ago
    In the most likely implementation of reversably encrypted passwords, an attacker who gets read control of the database can trivially brute-force passwords. Encryption isn't magic. But in the meantime, I'm curious about what web-based attacks relevant to password storage reversably encrypted passwords protect against. Were you thinking SQLI? Because I do not believe this to be the case. Don't store reversably encrypted passwords.
    - deleted 15y ago
      [deleted]
      - tedunangst 15y ago
        I don't see how rainbow tables are relevant. How would you use a rainbow table to crack passwords encrypted with an unknown key?
        deleted 15y ago
        [deleted]
        16s 15y ago
        You couldn't. It's not possible. If you don't know, then it's not possible to pre-compute. Many people fail to understand that. Rainbow tables (while sounding magical, are not). Edit: But they are great for standard unsalted hashes. md4, md5, sha1, sha512, etc.
    - tedunangst 15y ago
      Let's assume I store base64 encoded versions of encrypted passwords in my database. The key is 128 random bits in a file in the filesystem. How does sqli get you anything useful? Why do you not believe that's "safe"? (let's ignore other attacks or better solutions. Just sqli) Update: from other posts, I'm guessing you're assuming that anyone with sqli has other problems too, and that's why you don't think it's safe from sqli?
      - gkop 15y ago
  - dpark 15y ago
    > Playing devil's advocate, but this still prevents lots of web-based attacks. Provided you store the encryption key on the filesystem, or in memory and the encrypted passwords in the database usually you'll get access to only one part. Why would you assume this? It's entirely possible that a compromise will allow file system access, which will give the DB and the key. As for memory storage, you've got to have the key somewhere so that the machine can restore itself after a reboot. An in-memory-only key isn't a very practical solution. It's also entirely possible that you memory-only key will find its way to the swap file, again vulnerable if FS access is gained. > But it gets better! If you have access to the encrypted passwords, but not the key, then they're safer than hashes, since the attacker cannot try to bruteforce them (he could try bruteforcing a very very long encryption key of course...) This isn't necessarily true. Hashes are not intrinsically easier to break than encryption. Some hashes (such as bcrypt) are based on an encryption anyway.
    - tedunangst 15y ago
      I'm not aware of any operating system that allows perusal of swap through the filesystem. That'd be a pretty serious hole.
      - dpark 15y ago
        I should have clarified that I was referring to accessing the swap as root. This also requires another privilege escalation, and is a separate issue I probably should have left out.
    - cdcarter 15y ago
      you've got to have the key somewhere so that the machine can restore itself after a reboot In many very secure systems, this "somewhere" is in the brains/completely secondary data stores of a group of admins who enter that key when a reboot occus.
      - dpark 15y ago
        I think it's unlikely enough to ignore it here, though. Is someone who's willing to send an email in plaintext going to do this? Why bother when simply hashing would do the job more effectively? I agree it's possible for high security situations where passwords need reversibility, though. e.g. I wouldn't be surprised if Intuit used a system like this when they store passwords for external services. (They should still be hashing users' primary passwords, though.)
- pbreit 15y ago
  Yes, there is. In most companies, the database is significantly more accessible than any encryption keys. For goodness sake, marketers typically have query access to the DB. And the issue of emailing a password is different. The problem there is that if I gain access to your email account, I can quickly search "password" to discover your private passwords that a company, not you, chose to drop into your email account. But to be clear, user-created passwords should be stored one-way hashed and never emailed.
  - shubber 15y ago
    Trying not to be pedantic, but this is something everyone should know. If I can pull a list of two-way encrypted passwords, breaking that is way faster than extracting passwords from a properly crypted list. Essentially it's a huge list of short (almost known plaintext) messages. If you know a cryptosystem that will resist attack in that circumstance, please share. Properly crypted, passwords admit to local brute forcing, which is bad for any particular account. "Recoverable" passwords, the whole list admits to statistical attacks that break the whole list.
  - AgentConundrum 15y ago
    > For goodness sake, marketers typically have query access to the DB. That's a bit of a straw man, don't you think? Even if marketers have access to the database, they shouldn't have read access to the passwords table in a properly configured system. If they do, it's time to fire your DBA. > The problem there is that if I gain access to your email account, I can quickly search "password" to discover your private passwords Sometimes it's worse than that. I recently had to do a password recovery on a site, and they sent the password not only in plain text but also as the very beginning of the email. As such, gmail helpfully showed "example.com" as the sender, with "Password: P@ssword1" right in the body preview snippet. You could see it without even having to open the email. It may not be a common exploit, but if I was checking my gmail at work, a coworker that knew I had an account on this website could just send a recovery request and glance over my shoulder at just the right time and grab my password without my knowledge. Not good. I wish Google would implement some sort of algorithm that could determine password-looking text and a) not show it in the preview, and b) require user interaction to display it when viewing the actual email body.
- desigooner 15y ago
  I had to ask this as I am dealing with a DotNetNuke based system right now which stores authentication details in a table (aspnet_membership) with the passwords encrypted with a private key (in web.config in IIS) and a password salt. How would one go about securing such a system where there is no option but storing encrypted passwords that are reversible?!
  - deleted 15y ago
    [deleted]
  - aaronblohowiak 15y ago
    > "How would one go about securing such a system where there is no option but storing encrypted passwords that are reversible?!" Change the system.
    - desigooner 15y ago
      I wish it was that easy. Working in higher ed means dealing with legacy and proprietary systems at low budgets. "Change the system" isn't always the option in the real world a lot many times.
  - ams6110 15y ago
    You can change it so that DotNetNuke (really aspnet_membership) uses hashed passwords. They are then not recoverable, but DotNetNuke will allow a user to request a new password which is then emailed (rather than a slightly safer "reset password" link)
- coin 15y ago
  > If I can get the password list, the key isn't far away. What makes you think the key isn't far away?
  - po 15y ago
    Because the email server (or application server or whatever is creating the text for that email) can access it to decrypt it. If that server gets hacked, then you can decrypt all of the passwords.
  - jws 15y ago
    As an example: The password list might consist of entries encrypted with a public key. The private key might only exist on an air gapped laptop with its communication ports filled with epoxy in a secured facility using trusted humans to enter the encrypted password and retrieve the decrypted plaintext. I have no reason to believe the above is true, but there is also no reason to automatically believe there is a mechanism available to attackers of a compromised machine to decrypt all encoded materials on the machine.
ajross 15y ago
Recoverable passwords are what everyone means when they say "plaintext". You're positing a distinction that doesn't exist.
- ddlatham 15y ago
  That's not true. Some people say "We keep your password encrypted" instead of in plaintext, and make the dubious claim that they are then safe. It's good to help them understand the distinction that even if the passwords are encrypted, it's still a problem if they are recoverable.
- ceejayoz 15y ago
  There's absolutely a distinction. Reversibly encrypted passwords aren't ideal, but it does at least make a database dump less useful to someone who manages a SQL injection exploit.
  - tptacek 15y ago
    No, it means that getting the actual raw passwords is now a fun little puzzle for anyone who gets SQLI. News flash for the (hopefully small) collection of people who may be kidding themselves on this point: unless you've gone to significant lengths to mitigate this specific problem, if you give up the SQL for your website, you've probably given up the box, too. How likely is it that you're THAT company, the one that hardened their database server and app architecture so that it can survive someone who compromises SQL, and that you actually have SQLI? And, if you're THAT company, how likely is it that you're storing reversably encrypted passwords? And if you're THAT company, how likely is it that you're simply mailing them back to customers on request? It's not likely.
    - ceejayoz 15y ago
      One would hope that the encryption key wouldn't be in the database. The point remains - there is a benefit to reversibly encrypted passwords versus plaintext ones. It's certainly not ideal, but it's better than nothing.
hackinthebochs 15y ago
What exactly is the reason emailing the password is bad (ignoring the plain-text-in-database issue)?
- bricestacey 15y ago
  Email is traditionally transferred using unencrypted connections. Once in your mailbox, email is often saved and/or indexed for easy search, which is often unencrypted and/or outright unprotected. And worse, your email provider can discover your password by simply signing in as you.
- ceejayoz 15y ago
  I once opened a password reset e-mail from my (former) bank while at work and wasn't hugely pleased to see my password pop up in plain view for a coworker to see.
- parfe 15y ago
  Lets say you want to give the user a 1 step process to get back into their account. You can 1) Email the password or 2) Email a unique link which lets them reset the password for their account. If you do #1 the person likely used that password on other accounts. Now you've not only compromised access to your service, but any other that has the same password. IF you do #2 the user sets a new password and gets into his account. No record of the new password is left anywhere. An attacker with access to the email account can still compromise your service, but now he has no idea what the old password was.
  - gte910h 15y ago
    #2 is important as people share passwords like mad. Secondly, the link can expire after a certain amount of time.
tlianza 15y ago
> 2. Emailing them in plain text. Even if the password were irreversibly encrypted, if I can read your e-mail, I can still access your account in most systems. I can reset your password, and either follow the link they e-mail you, or see the random password they generated for you. I think #2 is more on you for accessing your e-mail securely, and less on Pingdom. Pingdom is only saving a hacker a little bit of time.

funkah 15y ago

Emailing the password is bad and they should stop, but where is the evidence that they are storing the password in plaintext?

dpark 15y ago
The fact that they sent it in an email in response to a user request means that they are at least storing it in a reversible format. Given that they sent the password in plaintext via email, I see no reason to believe they are competent enough to set up a reversible system that is more secure than plaintext (e.g. rot13 isn't more secure but isn't technically plaintext; storing an encrypted password with the key isn't more secure). In all likelihood, they are storing in plaintext or an equivalent.
- coin 15y ago
  reversible != plaintext
  - dpark 15y ago
    Could you not be bothered to read my comment before replying?
webignition 15y ago
The story only details the sending of a password in plain text. You are right in that this provides no evidence of the password being stored in plain text. It is equally plausible, without further evidence, that pingdom is merely changing the password (a likely case if the password is not retrievable) and emailing the new password. I tested this with my pingdom account for which I know the password. The email I received contained my password and not a new password. This confirms that pingdom is storing passwords in a retrievable fashion, whether that be plain text or some form of non-one way encryption.
16s 15y ago
It's not inherently bad. It's a trade-off between security and convenience. Believe it or not, most of the time, business managers are far more concerned about the user experience and the convenience of use rather than information security. It's not black and white. It's a decision with trade-offs either way.

tbeseda 15y ago

You can remove your account from the Subscription page of your account.

fourk 15y ago
Is there any guarantee that this actually entirely removes your data from their databases? How do you know they don't just toggle an `active` column for your row in the users table?

bdhe 15y ago

Obligatory link for those who haven't seen it before but want to know the right way to do it. http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/

delano 15y ago
We implemented this (bcrypt) for https://www.blamestella.com/ https://www.blamestella.com/ (a web monitoring service for devs and designers)
- rwolf 15y ago
  Your use of the word "implemented" gives me pause. I hope you mean "We've plugged the standard bcrypt library into our web app." and not "We found a pdf describing bcrypt on the internet and one of our 'rockstar ninja warlock' devs stayed up for a week writing an implementation that no one else is using and no one has reviewed."
  - delano 15y ago
    Ah yes, of course we didn't implement our own bcrypt!

hm2k 15y ago

Your bank stores passwords in plain text, but then they never email it to you.

feydr 15y ago
some do like discover.com (unfortuantely) truncates your password at 8 characters, downcases, and sends you in plain txt email
- gst 15y ago
  That's what I don't understand about banks. On 99% of all websites I can use special characters in my passwords. The only exception are my online banking sites, where I'm forced to restrict myself to [\d\w] one one of the sites and to [\d] on the other site.
  - dennisgorelik 15y ago
    Government's security regulations that banks must follow make banks less agile. That in turn make banks security system weaker. These are unfortunate unintended consequences.

fourk 15y ago

It would be nice if there existed a browser extension that would warn the user anytime they are about to register on a site with password storage issues like this. Of course, there would need to be some sort of community maintained repository for tracking which sites are doing this.

gst 15y ago
Why should it warn the user? Either the user is using the same password on multiple sites. Then this would be a real security issue, independent of the fact if some of the sites store the password in plaintext. Or the user is using different passwords for different sites. Then you don't really need to care how a single site handles your password.
- fourk 15y ago
  If every user used different passwords on every single site, this submission would be hardly newsworthy and barely discussion worthy. In a perfect world, sure, every user would have a unique 14+ character password for every site they register on. In a perfect world, every site would implement basic password encryption. Unfortunately, reality != perfect world.
- axomhacker 15y ago
  Or... The user usually uses the same password, but seeing this warning and gets alarmed, making him use a different password or not use the service. I love this idea!
- ddlatham 15y ago
  One reason is that if they are storing the password in a recoverable format, it tells you something about how much you can trust the security of that site in other ways. Even if you're using a different password, you may be much more hesitant about what other information you are willing to put into a site that doesn't take security seriously.
- srl 15y ago
  Either the user is using the same password on multiple sites. Then this would be a real security issue, independent of the fact if some of the sites store the password in plaintext. Nevertheless, the vast majority of users do - and that's unlikely to change in the near future. It's just too easy. Many users (the majority? I've seen no statistics for this, but everybody I know falls into this group) do, however, keep several passwords, and assign them to sites based on a combination of 1) how likely the site is to compromise the password (sites that email out plaintext score very poorly) and 2) how much the user cares about the security of that particular account. Which suggests the following use case for fourk's hypothetical plugin: user wants to know what password to use, sees that fooneti.cs is one of those sites that stores easily recoverable passwords, and chooses to use one of the disposable ones.

juiceandjuice 15y ago

Also... Equifax also stores your password in plain text.

cpeterso 15y ago
[citation needed]
- juiceandjuice 15y ago
  I hope it wasn't you that downvoted me. http://news.ycombinator.com/item?id=2865719 http://news.ycombinator.com/item?id=2865719 You'll have to take my word I think though... the password blacked out is my password.
  - cpeterso 15y ago
    Wasn't me. I figured it must be true; I just wanted to learn more. :)

BrandonDC 15y ago

Password security is a shared responsibility between the company storing the password and the user who chooses what password to store. As a user, you rarely know the full extent to how a company manages the storage of passwords so the responsibility truly rests on your shoulders to choose unique passwords for each service that you use.

dpark 15y ago
This is simply not realistic. I've got hundreds of accounts online. I cannot remember a truly unique password for each. It's not possible (not for me at least). I can't even remember all the sites I've got accounts. A lot of people implement their own hash ("I use a base password plus the second letter of the url and the number of letters in the domain: dumbe18"), but this is not unique per site, and these hashing schemes don't tend to be as unique or as hard to figure out as one might imagine. There are utilities now that try to help, but I've not found one that's even remotely convenient when it comes to accessing sites on multiple computers, my phone, and my tablet. Not to mention I'm putting my trust in a 3rd party to handle all of my passwords when I do this.
- BrandonDC 15y ago
  Personally, I think it's more realistic to place your trust in one verifiable source (i.e. using the cross-platform KeePass with the encrypted database stored on Dropbox) than assume that "hundreds" of different organizations are all going to implement adequate authentication strategies. What seems oddly unrealistic to me is that if one company exposes your password, you now have to not only remember all of the hundreds of sites you have accounts on, but log in to each one and change that one password that you always use.
  - dpark 15y ago
    I agree the current system is broken, but asking users to remember hundreds of passwords is no less broken. As for KeePass, the problem is that I can't get integration with a browser on my phone or tablet, so I'm left jumping back and forth between apps every time I need to log into something. Not to mention there's no official KeePass implementation for the Mac (unless I want to run on Mono). I also frankly think it's unnecessarily complex, but maybe I should give it a try again. I really don't understand how you can take the stance that it doesn't matter if a site has proper password security. Why are you bothering to use KeyPass if you don't care about security in the first place?

ErikRogneby 15y ago

I'd like to see these questions added standard to VC pitch meetings: 1)How do you store passwords in your datastore? plaintext? 2)When users login to your service and provide their credentials is it over SSL?

fourk 15y ago
I'd be interested in seeing the correlation between return on investment and level of basic security-related competence at the point at which the company first attempted to raise VC money.
- tptacek 15y ago
  It's probably negative. A dollar spent on security is a dollar not spent on customer acquisition. Don't put security in your slide deck.

ErikRogneby 15y ago

crunchbase has a nice list of competitors: http://www.crunchbase.com/company/pingdom http://www.crunchbase.com/company/pingdom Watchmouse appears to have some pretty high end customers. (including twitter, AT&T and verisign )

jfong 15y ago

This probably happens more than we think.

ck2 15y ago

One of many that might surprise you: http://plaintextoffenders.com http://plaintextoffenders.com

coin 15y ago
How do you know the "offenders" are storing in plaintext?
- johnx123-up 15y ago
  The detection process is somewhat wrong. In many sites, they store passwords in plaintext or reversible plaintext--but they send mere link to reset. So, you don't really know, how they're storing. IMHO, most of new startups store passwords for the sake of learning. Definitely, there needs to be some disclosure on how they'll store passwords.

IgorPartola 15y ago

Shameless plug/seizing the moment: Ping Brigade (https://www.pingbrigade.com/ https://www.pingbrigade.com/) does everything over HTTPS, stores passwords using bcrypt and never emails them to you. Moreover, because I really love HN, I'm going to run a 50% off discount at https://www.pingbrigade.com/signup/hn https://www.pingbrigade.com/signup/hn. Edit: Wow, that was a quick downvote. Just wondering since when is building a better product than the giant of the industry and showing it off on HN compels people to click the downvote button?

decadentcactus 15y ago
I think some will consider it a _bit_ unnecessary. I upvoted you, gotta seize those moments when they come :)
- IgorPartola 15y ago
  Thank you :)
cookiecaper 15y ago
I think it's cool. People are silly. Don't be afraid to leave messages like this where relevant.

lurkinggrue 15y ago

They brute force attack your password hash and then mail it to you.

drewjoh 15y ago

LiquidWeb also does this from my experience. Sign-up for a new account and have them call you for verification. Their verification question is "What is your password?".

cookiecaper 15y ago

As we see from this thread, people really need to stop assuming that a site will store their password securely. Find a system that allows you to use a unique, random password for each site and use that instead. Do not trust any site to store your password in a secure fashion as relatively few actually do. If someone can get into the password database on a site, it probably doesn't matter if they have your password or not, because they can usually still access everything directly anyway by looking up your user id and performing the relevant queries. The danger in plaintext storage is that your password to other valuable sites may be exposed by a leaked database dump or similar. This is not a concern if you use a randomly-generated unique password for each site you visit. Everything is just much safer this way. With some companies making kind of legitimate arguments for plaintext password storage, just assume that your password is NEVER secret to the admins of a site or anyone who may break in and steal their information. Things would be much nicer for everyone involved if we did this. There are systems in place that make this pretty easy. Personally I use a home-grown method: pwgen -c xx, copy and paste the coolest-looking password displayed, email to myself encrypted, and decrypt with my secret key and copy and paste any time I want to use a site. There are also things like LastPass, KeePass, websites that generate hashes of passwords salted with another phrase or target site URL (copy and paste final output), websites that output a simple character lookup table based on a user phrase, etc. I believe that an interested party could make one of these things work well enough for use among the general people (especially with automated sync platforms from Google and Mozilla). We need to stop relying on anonymous third parties for our personal safety.

joelmama 15y ago
You are right. But again, speaking about Pingdom...they are monitoring company...if they treat our password in that way, how do they treat our other private data...We are putting there our http passwords, right? This is a good way to find out if you should really use some service, or not.
16s 15y ago
I encourage people to use SHA1_Pass. I wrote it and provide full source code under the GPL license. It's free as in freedom and beer. I use it because (as you stated) sites don't do the right thing and have other priorities. As conscientious users and devs, we have to take matters into our own hands.

j15e 15y ago

Told you so a year ago : http://news.ycombinator.com/item?id=1118012 http://news.ycombinator.com/item?id=1118012