Muss ich mir Sorgen machen, wenn mein Git-Hosting-Provider Kennwörter im Klartext speichert?

1791
S. Michaels

Ich habe einen Kommentar zu Reddit gefunden, in dem vorgeschlagen wird, dass ProjectLocker, ein kostenloser Git-Host, seine Passwörter in Klartext speichert.

Ich weiß es nicht

  • (a) wenn dies wahr ist
  • (b) wie man es überprüft oder
  • (c) Wie besorgt sollte ich sein, wenn es richtig ist.

Könnte dies bedeuten, dass es für jemanden trivial leicht ist, in eines meiner privaten Code-Depots zu gelangen?

0
Jeder, der über den Datenbankzugriff verfügt, um Ihr Kennwort zu sehen, unabhängig davon, ob es gehasht oder gesalzen ist oder nicht, hat wahrscheinlich den Zugriff, Ihren privaten Code trotzdem zu lesen. Phoshi vor 15 Jahren 0
Phoshi: Das habe ich auch gedacht. Jemand, der bei einem Git-Hosting-Unternehmen arbeitet, ist wahrscheinlich in der Lage, den Code der Benutzer einzusehen, wenn er möchte. S. Michaels vor 15 Jahren 0
Ziemlich viel. Das einzig schlechte an Klartext-Passwörtern ist, wenn jemand, der böswilliger ist, die Datenbank in die Hände bekommt - das könnte schlecht sein. Phoshi vor 15 Jahren 0
Es wäre fantastisch, wenn jemand den Titel bearbeiten könnte, um keine falschen Vorwürfe über ProjectLocker zu erheben. Vielen Dank! runako vor 15 Jahren 0
Betitelt wie bearbeitet. Und danke für die Beantwortung dieser Frage. Ich freue mich, von jemandem zu hören, der bei ProjectLocker arbeitet. Außerdem habe ich zuvor eine Folgefrage gestellt, die nicht spezifisch für ProjectLocker ist, um die technischen Aspekte dieser Ausgabe besser zu verstehen: http://superuser.com/questions/46877/if-a-forgot-your-password-page- E-Mails-Ihr-alt-Passwort-ist-das-definitive-pr S. Michaels vor 15 Jahren 0

3 Antworten auf die Frage

8
runako

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.

2
ChrisF

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.

Es bezieht sich also darauf, ob Personen mit Zugriff auf ProjectLocker mein Kennwort lesen können, nicht externe Benutzer. Ich habe missverstanden, woher das Risiko kam. Ich würde denken, dass immer ein Risiko besteht, dass ein Mitarbeiter eines Hosting-Providers einen Blick auf Ihre Mitarbeiter hat. Wenn es nicht im Klartext ist, könnte ich mir vorstellen, dass es schwieriger ist, aber dennoch möglich ist. Ja, ich könnte sie fragen, aber ich weiß nicht, wie viel Gewicht ich ihnen versichern würde. S. Michaels vor 15 Jahren 0
Die Frage wird dann, ob diese Klartextablage sicher ist. ChrisF vor 15 Jahren 0
Sie meinen, dass es unterschiedliche Sicherheitsstufen gibt, selbst wenn Sie nur Textspeicher verwenden? S. Michaels vor 15 Jahren 0
Nun, die Datei / Datenbank selbst könnte durch ein Passwort geschützt werden, aber ich hatte mehr darüber nachgedacht, ob jemand von außen Zugriff auf die Datenbank erhalten konnte (auf welche Weise auch immer). In Anbetracht dessen, dass dies veröffentlicht wurde, gehe ich davon aus, dass Hacker nun versuchen, Zugang zu erhalten. ChrisF vor 15 Jahren 1
Ein Klartextpasswort, das auf toten Bäumen gespeichert und tief in Vault 106 in einem nicht gekennzeichneten, gesperrten und bewachten Aktenschrank mit einem an der Tür angebrachten Schild "Vorsicht der Leopard" vergraben ist, ist sicherer als eine in / var / gespeicherte UserPasswords.txt-Datei. www / Passwörter / zum Beispiel. Grant vor 15 Jahren 3
@ Grant: Gutes Beispiel. Danke für die Illustration. S. Michaels vor 15 Jahren 0
1
OwenP

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.

Ich habe immer gern Passwörter als Hash davon gespeichert, plus den Hash einer bekannten Zeichenfolge plus den Hash einer Zufallszahl, die auf mehreren Faktoren aus den Daten eines Benutzers basiert. Wahrscheinlich übertrieben, aber trotzdem. Phoshi vor 15 Jahren 0
Ich hoffe, diese "verschiedenen Faktoren" enthalten keine vom Benutzer veränderbaren Daten. Ich würde es hassen, wenn mein Passwort gültig ist, weil sich meine Telefonnummer nie ändert. Grant vor 15 Jahren 1
Nun, ich habe mir gedacht, da Sie Ihr Passwort benötigen, um tatsächlich die vom Benutzer veränderbaren Daten zu ändern, war das irrelevant, da ich es dann aktualisieren kann. Phoshi vor 15 Jahren 0
Guter Test. Sie senden Ihnen in der Tat eine Kopie Ihres alten Passworts von diesem Link: https://portal.projectlocker.com/login/lost_password S. Michaels vor 15 Jahren 1
Ich würde nicht nur sagen, wenn Sie es zurückbekommen, wird es im Klartext gespeichert. Sie könnten Verschlüsselung anstelle von Hashing verwenden, wodurch sie entschlüsselt und an Sie gesendet werden könnten. Die Verschlüsselung ist beim Speichern in einer Datenbank immer noch etwas sicher und anfällig, wenn ein Angreifer den Verschlüsselungsschlüssel zum Lesen der Kennwörter erhalten kann. Persönlich bevorzuge ich einen gesalzenen sha1-Hash (da er leicht in Javascript zu implementieren ist, geht das Benutzerpasswort niemals über den Draht). Joshua vor 15 Jahren 4
Hashing in js vor dem Senden ist sinnlos - bedeutet nur, dass der Hash statt des Passworts gesucht wird. Rich Bradshaw vor 15 Jahren 0
Warum nicht die Antwort bearbeiten, um den falschen zweiten Satz zu entfernen? Warum stattdessen kommentieren? Es ist klar, dass manche Leute bidirektionale Funktionen nicht verstehen. Warum sie mit Informationen verwechseln, die definitiv falsch sind? runako vor 15 Jahren 0
@Rich Bradshaw: Hashing in JS sichert das Kennwort nicht auf dem Clientcomputer. Es wird jedoch verhindert, dass das Kennwort im Klartext an den Server gesendet wird. Dies ist für die Authentifizierung über HTTP ohne SSL unerlässlich. Auf diese Weise kann ich tatsächlich sagen, dass meine Datenbank ** niemals das tatsächliche Kennwort sieht. Joshua vor 15 Jahren 0