3 ms·

Why aren't the site names encrypted too? Users are encouraged to store their password files publicly, and yet the files contain a plaintext list of sites that

Why aren't the site names encrypted too? Users are encouraged to store their password files publicly, and yet the files contain a plaintext list of sites that the user has logins to! Seems a serious privacy breach.

ejcx 11y ago
Not encrypting site names was a UX decision. If site names were encrypted, listing entries in your password store would require a prompt for your password.
- willvarfar 11y ago
  Its a bad default. You could make it so that site names were encrypted by default, but files with plaintext site names were supported.
  - ejcx 11y ago
    Some people may disagree with me but that's fine. There really isn't a correct answer here. It's a product decision balanced with security. I think _strongly_ wanting this is mostly FUD. I firmly believe in secure defaults (with all my heart) but I don't think there's a compelling reason to hide site names in this situation. I trust the strong cryptography (and DJB) that protects the passwords and this is plenty for keeping an attacker out. Yeah, it's more information for an attacker but I don't think it buys an attacker anything meaningful. Responding to ping or listening on specific TCP ports and responding with service banners is "more information" too, but these are accepted. Running your company on someone else's computer used to not be accepted and now it is. With strong cryptography there is no reason this information can't be public. If you're truly paranoid, you can always use a private repo or a private git server. If anyone has a compelling argument for why this information should be secret by default I would love to make the change.
    - willvarfar 11y ago
      Here are two obvious reasons for wanting to hide this meta information: 1) ejcx signs up for a porn service and is embarrassed to admit it 2) ejcx has an account on some server compromised. The attacker now wants to get a nice list of other sites that the ejcx also uses, so they can try their luck to see where ejcx has foolishly used the same or similar password and login name. This information is just a github search away. In both cases, ejcx may never be so foolish?!. But users of password management apps in general mess up all the time. I want a password manager that I have confidence in to upload my passwords somewhere I can retrieve them if I lose my home computers etc. However, I don't want to announce to the world the websites I visit.
      - ejcx 11y ago
        I don't buy your second point. Your argument is that an attacker can try the password elsewhere faster, when the list of sites an attacker is interested in is small. An attacker could try every site in the Alexa 1m before anyone knows the sites passwords were dumped anyways.
- rhgb 11y ago
  Maybe site names should be hidden in commit messages, especially when the password vault is publicly stored.
- 59nadir 11y ago
  > If site names were encrypted, listing entries in your password store would require a prompt for your password. As it should, yes. Any interaction with the password manager regarding my stored passwords should require the master password.
- creshal 11y ago
  You say "it assumes your remote git repository may be malicious", but you don't do anything to protect your users' metadata? http://www.6nelweb.com/bio/papers/pwvault-ESORICS12-ext.pdf http://www.6nelweb.com/bio/papers/pwvault-ESORICS12-ext.pdf
  - ejcx 11y ago
    Ah great find. This also needs to be checked. Thanks
    - creshal 11y ago
      This should have been checked before starting to implement and advertise your "secure" password manager. Just saying. Edit: What, expecting people to do research before they make a software that users are supposed to entrust sensitive data to is so unreasonable it deserves silent downvotes?
MindTwister 11y ago
I wouldn't call this a serious privacy breach, you could just use a private repository.
- MindTwister 11y ago
  Is the above and the replies by the author really so unworthy of discussion that they require a downvote? Or is someone just disagreeing?
- creshal 11y ago
  The software claims to be usable without private repositories¹. If it can't do that, it is a serious bug. ¹ From the readme: "it assumes your remote git repository may be malicious"
  - MindTwister 11y ago
    From the context, malicious means either "tampers with your data" or "will attempt to decrypt your data", not "may find your outdated MySpace profile" In that sense it certainly is usable without private repositories.
    - creshal 11y ago
      Unencrypted, unauthenticated metadata allow tampering with your data: http://www.6nelweb.com/bio/papers/pwvault-ESORICS12-ext.pdf http://www.6nelweb.com/bio/papers/pwvault-ESORICS12-ext.pdf
      - MindTwister 11y ago
        Ok, just to make things clear, and to make sure I understand, an attack could look like this; 1. I trick you into using my GitEvil Repository Service (GERS™). 2. After you upload your data, I swap target site information (in this case name) with the name for GERS™. 3. Next time you log in to GERS™, you accidentally send the login information for target site instead. 4. Profit In that case, keeping with the wish to keep the manager searchable without the master password, would it be possible to mitigate this by HMAC'ing the encrypted password with, for instance, the site name? As should be obvious from the above, I'm no crypto expert.

ejcx 11y ago

Not encrypting site names was a UX decision. If site names were encrypted, listing entries in your password store would require a prompt for your password.

willvarfar 11y ago
Its a bad default. You could make it so that site names were encrypted by default, but files with plaintext site names were supported.
- ejcx 11y ago
  Some people may disagree with me but that's fine. There really isn't a correct answer here. It's a product decision balanced with security. I think _strongly_ wanting this is mostly FUD. I firmly believe in secure defaults (with all my heart) but I don't think there's a compelling reason to hide site names in this situation. I trust the strong cryptography (and DJB) that protects the passwords and this is plenty for keeping an attacker out. Yeah, it's more information for an attacker but I don't think it buys an attacker anything meaningful. Responding to ping or listening on specific TCP ports and responding with service banners is "more information" too, but these are accepted. Running your company on someone else's computer used to not be accepted and now it is. With strong cryptography there is no reason this information can't be public. If you're truly paranoid, you can always use a private repo or a private git server. If anyone has a compelling argument for why this information should be secret by default I would love to make the change.
  - willvarfar 11y ago
    Here are two obvious reasons for wanting to hide this meta information: 1) ejcx signs up for a porn service and is embarrassed to admit it 2) ejcx has an account on some server compromised. The attacker now wants to get a nice list of other sites that the ejcx also uses, so they can try their luck to see where ejcx has foolishly used the same or similar password and login name. This information is just a github search away. In both cases, ejcx may never be so foolish?!. But users of password management apps in general mess up all the time. I want a password manager that I have confidence in to upload my passwords somewhere I can retrieve them if I lose my home computers etc. However, I don't want to announce to the world the websites I visit.
    - ejcx 11y ago
      I don't buy your second point. Your argument is that an attacker can try the password elsewhere faster, when the list of sites an attacker is interested in is small. An attacker could try every site in the Alexa 1m before anyone knows the sites passwords were dumped anyways.
rhgb 11y ago
Maybe site names should be hidden in commit messages, especially when the password vault is publicly stored.
59nadir 11y ago
> If site names were encrypted, listing entries in your password store would require a prompt for your password. As it should, yes. Any interaction with the password manager regarding my stored passwords should require the master password.
creshal 11y ago
You say "it assumes your remote git repository may be malicious", but you don't do anything to protect your users' metadata? http://www.6nelweb.com/bio/papers/pwvault-ESORICS12-ext.pdf http://www.6nelweb.com/bio/papers/pwvault-ESORICS12-ext.pdf
- ejcx 11y ago
  Ah great find. This also needs to be checked. Thanks
  - creshal 11y ago
    This should have been checked before starting to implement and advertise your "secure" password manager. Just saying. Edit: What, expecting people to do research before they make a software that users are supposed to entrust sensitive data to is so unreasonable it deserves silent downvotes?

MindTwister 11y ago

I wouldn't call this a serious privacy breach, you could just use a private repository.

MindTwister 11y ago
Is the above and the replies by the author really so unworthy of discussion that they require a downvote? Or is someone just disagreeing?
creshal 11y ago
The software claims to be usable without private repositories¹. If it can't do that, it is a serious bug. ¹ From the readme: "it assumes your remote git repository may be malicious"
- MindTwister 11y ago
  From the context, malicious means either "tampers with your data" or "will attempt to decrypt your data", not "may find your outdated MySpace profile" In that sense it certainly is usable without private repositories.
  - creshal 11y ago
    Unencrypted, unauthenticated metadata allow tampering with your data: http://www.6nelweb.com/bio/papers/pwvault-ESORICS12-ext.pdf http://www.6nelweb.com/bio/papers/pwvault-ESORICS12-ext.pdf
    - MindTwister 11y ago
      Ok, just to make things clear, and to make sure I understand, an attack could look like this; 1. I trick you into using my GitEvil Repository Service (GERS™). 2. After you upload your data, I swap target site information (in this case name) with the name for GERS™. 3. Next time you log in to GERS™, you accidentally send the login information for target site instead. 4. Profit In that case, keeping with the wish to keep the manager searchable without the master password, would it be possible to mitigate this by HMAC'ing the encrypted password with, for instance, the site name? As should be obvious from the above, I'm no crypto expert.