Should I be concerned if my Git hosting provider stores passwords in plaintext?

0

I found a comment on Reddit suggesting that ProjectLocker, a free Git host, stores their passwords in plain text.

I don't know

  • (a) if this is true
  • (b) how to verify it or
  • (c) how worried I should be if it's correct.

Could this mean that it would be trivially easy for someone to get into one of my private code repositories?

S. Michaels

Posted 2009-09-25T14:24:59.577

Reputation: 185

Anybody with the database access to see your password, whether it's hashed and salted or not, probably has the access to read your private code anyway. – Phoshi – 2009-09-25T14:50:18.340

Phoshi: That's what I was thinking too. Someone working at any Git hosting company is probably able to peek into its users code if they want to. – S. Michaels – 2009-09-25T14:58:44.160

Pretty much. The only bad thing about plaintext passwords is if somebody more malicious gets their hands on the database - that could be bad. – Phoshi – 2009-09-25T15:01:12.017

It would be awesome if someone could edit the title to not make false accusations about ProjectLocker. Thanks! – runako – 2009-09-25T19:02:45.413

Titled edited as requested. And thanks for responding to this question. I appreciate hearing from someone who works at ProjectLocker. Also I posted a follow-up question earlier that is not specific to ProjectLocker to try to understand the technicalities of this issue better: http://superuser.com/questions/46877/if-a-forgot-your-password-page-emails-your-old-password-is-that-definitive-pr

– S. Michaels – 2009-09-25T19:28:41.197

Answers

8

I work at ProjectLocker, and I'd like to add some clarity to this thread. First, to answer the OP's questions:

a) This rumor is not true. ProjectLocker doesn't store passwords in plaintext.

b) You can't verify this for ProjectLocker or any other website without access to their backend systems.

c) I'd be fairly worried. However, I would be pretty surprised to find that any of the major Subversion hosting or Git hosting sites store plaintext passwords. It's just a bad idea.

Incidentally, all Git access at ProjectLocker uses public-key authentication and no passwords.

As others have pointed out, ProjectLocker does allow users to retrieve lost passwords. We do this by storing passwords encrypted with a two-way function. (If you ever check the "save this card for later" box on an ecommerce website, your credit card is stored that way. Same thing goes for subscription sites that bill periodically, such as Netflix.) In general, we treat passwords as sensitive data, like credit cards or customer artifacts (code, etc.). There's a fair philosophical debate about whether sites should store passwords in retrievable format, but feedback from our users indicated that they prefer retrievable passwords.

As to the post on Reddit, I can say that the poster has never worked at ProjectLocker and has no actual knowledge of our authentication systems. The poster most likely is not familiar with two-way functions, and is mistakenly confusing "reversible" with "plaintext."

Finally, if you are considering hosting your code with a third party, and you do not trust their answers to a question like this, you should definitely not store your code there. If you don't trust your host, you shouldn't use them at all, regardless of how they store your password.

runako

Posted 2009-09-25T14:24:59.577

Reputation: 205

2

If it's true then it is a security risk as anyone with access (or able to gain access via some means) will be able to read your password.

You could always ask ProjectLocker if the comment on Reddit is true. Whether you believe their answer is up to you.

However, I don't know if it's true or not.

ChrisF

Posted 2009-09-25T14:24:59.577

Reputation: 39 650

Oh, so it's referring to whether people with access on ProjectLocker can read my password, not external users. I misunderstood where the risk was coming from. I would think there would always be a risk of an employee at a hosting provider taking a peek at your stuff. If it's not in plaintext, then I would imagine it's more difficult but still possible. Yes, I could ask them but I don't know how much weight I would give their assurances. – S. Michaels – 2009-09-25T14:33:31.930

The question then becomes is this plain text storage secure. – ChrisF – 2009-09-25T14:33:34.770

You mean there could be different levels of security even while using plain text storage? – S. Michaels – 2009-09-25T14:34:35.813

1Well the file/database itself could be password protected, but I was more thinking about whether someone from outside could gain access to the database (by whatever means). Given that this has been publicised I would assume that hackers are now trying to gain access. – ChrisF – 2009-09-25T14:36:47.073

3A plain text password stored on dead trees and buried deep within Vault 106 in an unmarked, locked, and guarded filing cabinet with a sign posted on the door "Beware the leopard" is more secure than a UserPasswords.txt file stored in /var/www/passwords/, for example. – Grant – 2009-09-25T14:49:57.733

@Grant: Good example. Thanks for illustrating. – S. Michaels – 2009-09-25T14:57:18.000

1

One way to verify if this is true is to pretend you forgot your password. If the host tells you your current password instead of resetting it and giving you a temporary password, you have proof that they store it in plaintext.

edit: Joshua's comment is right: this isn't definitive proof that they're storing your password in plaintext, but it is proof that they are storing your password in a reversable format.

It is most secure to store a salted one-way hash of the password. It's trivial to hash your input and compare it to the stored hash, but impractical for anyone to reverse-engineer the hash to obtain your password. This is why most sites send you a weird random password when you lose it: they no longer know what your password is so they have to reset it to something they do know.

If ProjectLocker does store your password in a reversable format, there's varying degrees of worry you should have. Disgruntled employees aren't the only danger; if an attacker is able to obtain a database dump and can determine the way to decode the passwords (if they can get a DB dump, they can likely get the source code) they'll have plenty of passwords. If you use a username and password that you don't use anywhere else for that site, the worst they can do is mess up your ProjectLocker account. However, many people use the same username and similar passwords for many different websites; if you do so then storage of the password in a reversible format puts you at a great risk.

In my opinion, if the password you use at ProjectLocker isn't similar to the passwords you use at other sites, you shouldn't worry too much. However, it would be worth voicing a complaint with them because it makes it much more likely that a small lapse in security could lead to someone getting access to your account.

OwenP

Posted 2009-09-25T14:24:59.577

Reputation: 1 400

I've always been fond of storing passwords as the hash of it, plus the hash of a known string, plus the hash of a random number based on several factors from a user's data. Probably overkill, but still. – Phoshi – 2009-09-25T15:12:30.683

1I hope those 'several factors' don't include user changeable data. I'd hate to have my password validity dependent on my phone number never changing. – Grant – 2009-09-25T15:16:10.863

Well, I figured seeing as you need your password to actually change any of the userchangable data, that was irrelevant, as I can update it then. – Phoshi – 2009-09-25T15:20:12.353

1

Good test. They do in fact mail you a copy of your old password from this link: https://portal.projectlocker.com/login/lost_password

– S. Michaels – 2009-09-25T15:30:13.703

4I wouldn't only say if you get it back it is stored in plaintext. They could use encryption instead of hashing, which would allow them to decrypt it and send it to you. Encryption is still somewhat secure when storing in a database and is vulnerable when an attacker can get the encryption key to read the passwords. Personally, I prefer a salted sha1 hash right now (since it's easy to implement in javascript, the users password never goes over the wire). – Joshua – 2009-09-25T15:42:50.857

Hashing in js before sending is useless - just means that the onus is on finding the hash, rather than the password. – Rich Bradshaw – 2009-09-25T17:56:23.317

Why not edit the answer to remove the incorrect 2nd sentence? Why annotate instead? It's clear that some people do not understand two-way functions; why confuse them with information that is definitively incorrect? – runako – 2009-09-25T18:23:23.013

@Rich Bradshaw: Hashing in JS doesn't secure the password on the clients computer, but what it does do is prevent the password from being sent to the server in plaintext. This is vital for authentication over HTTP without SSL. Doing it this way allows me to actually say that my database never sees the actual password. – Joshua – 2009-09-25T23:02:46.210