6 ms·

Steel – Open-source command-line password manager

69 points by nvr82 11y ago

dmix 11y ago
I currently use Pass and two things I prefer with it over Steel are: - Steel uses a SQLite db while Pass uses a directory of .gpg files for each password, which is easier to backup using git and simple file sync systems - Pass uses GPG to encrypt files which is reliable and preferable over rolling your own crypto
- nvr82 11y ago
  Steel is not rolling it's own crypto. It uses AES in cfb mode as implemented by libmcrypt.
  - stouset 11y ago
    Building your own abstractions on top of AES directly is no less dangerous or prone to error.
    - orthecreedence 11y ago
      > Building your own abstractions on top of AES directly is no less dangerous or prone to error. You're telling me it's just as dangerous to implement a well-known library that has working AES-CFB as it is to roll your own AES-CFB implementation? That's silly. Yes, it's dangerous to do any form of crypto. But there are really good resources on how to implement it correctly, and if you're using an existing library, the risks are significantly reduced.
      - stouset 11y ago
        Yes, insofar as the likelihood of introducing an exploitable catastrophic flaw in either scenario is essentially 1. If you think you can just slap AES on something and call it a day, you're going to have a bad time.
        orthecreedence 11y ago
        This can be reduced to a simple mathematical equation: (risk of hand rolling AES * risk of poor implementation) > risk of poor implementation Also, if your assumption that the likelihood of introducing a catastrophic flaw is 1 was correct, there would be no correctly implemented crypto anywhere (although it would make the above equation false). I agree with the nature of your arguments: crypto must be treated with care, and must be vetted by experts. However the whole "DON'T DO CRYPTO EVER!!" mindset is a lot more harmful in the long run. It's a powerful and dangerous tool, but it should be documented and understood instead of making us cower in fear.
        stouset 11y ago
        Sorry, I missed your reply to this. In case you do ever read this, my point is that: (risk of an amateur hand rolling AES * risk of poor implementation by an amateur) = risk of poor implementation by an amateur + epsilon = 1 Even experts make mistakes in these things, but amateurs don't even stand a chance. An amateur will make more mistakes doing both, for sure, but there are bound to be enough catastrophic flaws that it simply doesn't even matter at that point. More real-world attackers are going to try and exploit your abstractions on top of AES than try to exploit your AES implementation itself.
- ludbb 11y ago
  While using AES-256-CFB is not "rolling their own crypto", Steel has some other functionality around (see https://gitlab.com/Rosvall/steel/blob/master/crypto.c https://gitlab.com/Rosvall/steel/blob/master/crypto.c) which provides bad implementations, namely generate_pass which seeds from timestamp and verify_hmac which is not a constant time comparison function.
  - stouset 11y ago
    Yes, it absolutely is[0] for essentially the exact examples you cite. [0]: http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.h...).
zvrba 11y ago
> Password management belongs to the command line. Not really. You don't want passwords in plain-text traveling around pipes or sockets with easy to sniff system-calls. You want a secure channel between your password manager and the application. Keepass2, for example, copies your password to the clipboard and automatically erases the clipboard after a short timeout. (True secure channels don't exist yet in any OS as far as I'm aware.) Upon reading the manual, steel can communicate with X clipboard (by xclip), but it passes the passphrase through a pipe. It never clears the clipboard. To be "secure", it'd need to be an X11 application (i.e., NOT command-line) which would participate in the X11 selection protocol and provide password only when the user actually tries to paste it. In addition, you need to "open" and "close" the steel database before using it. The manual does not explain what "opening" and "closing" does however. Does "open" temporarily decrypt the whole database? Security is more than just applying strong crypto. I don't like the general design of this application; the discussion of general security concerns (side-channel attacks) is completely missing.
- nvr82 11y ago
  Agreed. There's definitely room for improvement.
- draven 11y ago
  I use pass ( http://www.passwordstore.org/ http://www.passwordstore.org/ ) It can copy your password to the clipboard, and erases it after 45 seconds (by default.) It's still implemented as a shell script and uses xclip. Reading the shell script I can see they thought about some clipboard managers which store their entries in plain text: # Clipboard managers frequently write their history out in plaintext, # so we axe it here: qdbus org.kde.klipper /klipper org.kde.klipper.klipper.clearClipboardHistory &>/dev/null
  - swombat 11y ago
    So anything that monitors your clipboard (basically every spyware worth its salt) will have a copy of all your passwords then? That doesn't seem very secure.
sprin 11y ago
Thanks for sharing your project. What other CLI password managers did you review, and in what ways did you want Steel to be different? I noticed that, after being opened, the SQLite database appears to be stored on disk unencrypted, and must be manually re-encrypted with the "close" command. I think most password managers attempt to ensure that the unencrypted database is only ever in physical memory. The interface uses pipable commands rather than an interactive shell. The reason given is so that it can integrate with other standard Unix tools. This means that the entry context must be supplied for every command, in this case by id. Another side-effect of the pipable command interface is that using the "replace" command to change the passphrase will echo the passphrase to the screen and leave that passphrase in the shell history. The manual gives an example of piping to another utility: steel --show-passphrase 4 | xclip -selection clipboard However, this seems a bit awkward for such a common task. Why not integrate xclip in to Steel?
- creshal 11y ago
  Shameless self plug: YSPave (https://github.com/creshal/yspave https://github.com/creshal/yspave) is CLI-based too, and has an interactive mode for cases like these. (The database is also encrypted as long as possible and only decrypted on demand. Yes, it lacks a "clear clipboard" mode and shouldn't be written in Python, but other than that it addresses all the criticism this solution gets… Maybe I should give it a fancy bootstrapped homepage with an .io domain to gain attention.)
lowry 11y ago
I prefer using git-encrypt https://github.com/shadowhand/git-encrypt https://github.com/shadowhand/git-encrypt The concept is a bit different. The remote repository is always encrypted and the local is always not.
- michaelmior 11y ago
  So anything that can read your disk has access to all your passwords?
  - reitanqild 11y ago
    There is always access control (rogue users) and disk encryption (offline attack). Personally I tend to think that once you have malware running then you are basically owned.
    - zzalpha 11y ago
      Yes, so you should definitely do something that makes it infinitely easier to steal your passwords once you're compromised... why go through the trouble of installing a keylogger or other malware when they can just copy the contents of your home directory! Edit: In case folks miss the point: just because security is hard, doesn't mean you should just throw up your hands. By this very same logic, why bother with passwords on your workstation? Or filesystem permissions? Heck, if bitcoin wallet hacks have taught us anything, it's that good quality, local encryption is critical specifically because a remote attacker could take over your machine. Why make their job easier?
mataug 11y ago
I use pass ( http://www.passwordstore.org/ http://www.passwordstore.org/ ) too. I don't see any good reason why someone should use steel over PasswordStore. Its good to have competition, but without a significant improvement over the already brilliant `Pass` I don't see much value in switching over.
- Johnny_Brahms 11y ago
  I'd call storing the domain of the password in plain text a metadata leak.
demosthenex 11y ago
I use an older project called pwsafe that is careful about what memory the passwords are stored in, and uses an AES encrypted flat file database for minimum calls. I've been very happy with it.
thesorrow 11y ago
We use hashicorp vault to store password. Little bit hard to configure but works like a charm.
dchest 11y ago
If I read it correctly, it stores a bcrypt hash of passphrase in the file for verification, but then goes ahead and uses a salted SHA256 of the passphrase as the encryption key, compromising the whole idea of having computationally hard password hashing. If I'm right, it can easily win the WTF Crypto Award of the month.
- ctz 11y ago
  I read it the same way. Tremendously bad!
drostie 11y ago
After I wrote my "nermal" project (npm-installable JS authenticated-encryption container) I wrote a password manager as an example, which I called "tagaloop". Some documentation for it is available here: https://github.com/drostie/nermal/tree/master/examples https://github.com/drostie/nermal/tree/master/examples In particular, I avoided the command-line interface precisely because the other tool on that page, ncrypt, would tend to leak inline passwords and such to log files. For various reasons those options were necessary to perform the job it required (e.g. in a script which is chmod root 500, for example) but not required for its use (it will just prompt you for the info if you leave the flags off). In particular, the -a "add" option in Steel will probably save passwords to ~/.bash_history, no?
- dyladan 11y ago
  Not only that, but command line options are generally not secure from other users on the system. Just running `ps -ef` can read command line options from any user. A more secure alternative would be running the program in an interactive mode.
brohee 11y ago
Is it really using CFB mode without any kind of authentication? If so, mostly useless...
- dchest 11y ago
  It actually uses HMAC-SHA256 to authenticate ciphertext, although with the same key as AES encryption.
  - brohee 11y ago
    It's worth mentioning it on the homepage, it looks very scary without it.
jarin 11y ago
This is a pretty nice idea, but without a mobile app it would be very difficult to recommend.
- swiley 11y ago
  Command line apps work pretty well on android, I use them every day.

69 points by nvr82 11y ago

dmix 11y ago

I currently use Pass and two things I prefer with it over Steel are: - Steel uses a SQLite db while Pass uses a directory of .gpg files for each password, which is easier to backup using git and simple file sync systems - Pass uses GPG to encrypt files which is reliable and preferable over rolling your own crypto

nvr82 11y ago
Steel is not rolling it's own crypto. It uses AES in cfb mode as implemented by libmcrypt.
- stouset 11y ago
  Building your own abstractions on top of AES directly is no less dangerous or prone to error.
  - orthecreedence 11y ago
    > Building your own abstractions on top of AES directly is no less dangerous or prone to error. You're telling me it's just as dangerous to implement a well-known library that has working AES-CFB as it is to roll your own AES-CFB implementation? That's silly. Yes, it's dangerous to do any form of crypto. But there are really good resources on how to implement it correctly, and if you're using an existing library, the risks are significantly reduced.
    - stouset 11y ago
      Yes, insofar as the likelihood of introducing an exploitable catastrophic flaw in either scenario is essentially 1. If you think you can just slap AES on something and call it a day, you're going to have a bad time.
      - orthecreedence 11y ago
        This can be reduced to a simple mathematical equation: (risk of hand rolling AES * risk of poor implementation) > risk of poor implementation Also, if your assumption that the likelihood of introducing a catastrophic flaw is 1 was correct, there would be no correctly implemented crypto anywhere (although it would make the above equation false). I agree with the nature of your arguments: crypto must be treated with care, and must be vetted by experts. However the whole "DON'T DO CRYPTO EVER!!" mindset is a lot more harmful in the long run. It's a powerful and dangerous tool, but it should be documented and understood instead of making us cower in fear.
        stouset 11y ago
        Sorry, I missed your reply to this. In case you do ever read this, my point is that: (risk of an amateur hand rolling AES * risk of poor implementation by an amateur) = risk of poor implementation by an amateur + epsilon = 1 Even experts make mistakes in these things, but amateurs don't even stand a chance. An amateur will make more mistakes doing both, for sure, but there are bound to be enough catastrophic flaws that it simply doesn't even matter at that point. More real-world attackers are going to try and exploit your abstractions on top of AES than try to exploit your AES implementation itself.
ludbb 11y ago
While using AES-256-CFB is not "rolling their own crypto", Steel has some other functionality around (see https://gitlab.com/Rosvall/steel/blob/master/crypto.c https://gitlab.com/Rosvall/steel/blob/master/crypto.c) which provides bad implementations, namely generate_pass which seeds from timestamp and verify_hmac which is not a constant time comparison function.
- stouset 11y ago
  Yes, it absolutely is[0] for essentially the exact examples you cite. [0]: http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.h...).

zvrba 11y ago

> Password management belongs to the command line. Not really. You don't want passwords in plain-text traveling around pipes or sockets with easy to sniff system-calls. You want a secure channel between your password manager and the application. Keepass2, for example, copies your password to the clipboard and automatically erases the clipboard after a short timeout. (True secure channels don't exist yet in any OS as far as I'm aware.) Upon reading the manual, steel can communicate with X clipboard (by xclip), but it passes the passphrase through a pipe. It never clears the clipboard. To be "secure", it'd need to be an X11 application (i.e., NOT command-line) which would participate in the X11 selection protocol and provide password only when the user actually tries to paste it. In addition, you need to "open" and "close" the steel database before using it. The manual does not explain what "opening" and "closing" does however. Does "open" temporarily decrypt the whole database? Security is more than just applying strong crypto. I don't like the general design of this application; the discussion of general security concerns (side-channel attacks) is completely missing.

nvr82 11y ago
Agreed. There's definitely room for improvement.
draven 11y ago
I use pass ( http://www.passwordstore.org/ http://www.passwordstore.org/ ) It can copy your password to the clipboard, and erases it after 45 seconds (by default.) It's still implemented as a shell script and uses xclip. Reading the shell script I can see they thought about some clipboard managers which store their entries in plain text: # Clipboard managers frequently write their history out in plaintext, # so we axe it here: qdbus org.kde.klipper /klipper org.kde.klipper.klipper.clearClipboardHistory &>/dev/null
- swombat 11y ago
  So anything that monitors your clipboard (basically every spyware worth its salt) will have a copy of all your passwords then? That doesn't seem very secure.

sprin 11y ago

Thanks for sharing your project. What other CLI password managers did you review, and in what ways did you want Steel to be different? I noticed that, after being opened, the SQLite database appears to be stored on disk unencrypted, and must be manually re-encrypted with the "close" command. I think most password managers attempt to ensure that the unencrypted database is only ever in physical memory. The interface uses pipable commands rather than an interactive shell. The reason given is so that it can integrate with other standard Unix tools. This means that the entry context must be supplied for every command, in this case by id. Another side-effect of the pipable command interface is that using the "replace" command to change the passphrase will echo the passphrase to the screen and leave that passphrase in the shell history. The manual gives an example of piping to another utility: steel --show-passphrase 4 | xclip -selection clipboard However, this seems a bit awkward for such a common task. Why not integrate xclip in to Steel?

creshal 11y ago
Shameless self plug: YSPave (https://github.com/creshal/yspave https://github.com/creshal/yspave) is CLI-based too, and has an interactive mode for cases like these. (The database is also encrypted as long as possible and only decrypted on demand. Yes, it lacks a "clear clipboard" mode and shouldn't be written in Python, but other than that it addresses all the criticism this solution gets… Maybe I should give it a fancy bootstrapped homepage with an .io domain to gain attention.)

lowry 11y ago

I prefer using git-encrypt https://github.com/shadowhand/git-encrypt https://github.com/shadowhand/git-encrypt The concept is a bit different. The remote repository is always encrypted and the local is always not.

michaelmior 11y ago
So anything that can read your disk has access to all your passwords?
- reitanqild 11y ago
  There is always access control (rogue users) and disk encryption (offline attack). Personally I tend to think that once you have malware running then you are basically owned.
  - zzalpha 11y ago
    Yes, so you should definitely do something that makes it infinitely easier to steal your passwords once you're compromised... why go through the trouble of installing a keylogger or other malware when they can just copy the contents of your home directory! Edit: In case folks miss the point: just because security is hard, doesn't mean you should just throw up your hands. By this very same logic, why bother with passwords on your workstation? Or filesystem permissions? Heck, if bitcoin wallet hacks have taught us anything, it's that good quality, local encryption is critical specifically because a remote attacker could take over your machine. Why make their job easier?

mataug 11y ago

I use pass ( http://www.passwordstore.org/ http://www.passwordstore.org/ ) too. I don't see any good reason why someone should use steel over PasswordStore. Its good to have competition, but without a significant improvement over the already brilliant `Pass` I don't see much value in switching over.

Johnny_Brahms 11y ago
I'd call storing the domain of the password in plain text a metadata leak.

demosthenex 11y ago

I use an older project called pwsafe that is careful about what memory the passwords are stored in, and uses an AES encrypted flat file database for minimum calls. I've been very happy with it.

thesorrow 11y ago

We use hashicorp vault to store password. Little bit hard to configure but works like a charm.

dchest 11y ago

If I read it correctly, it stores a bcrypt hash of passphrase in the file for verification, but then goes ahead and uses a salted SHA256 of the passphrase as the encryption key, compromising the whole idea of having computationally hard password hashing. If I'm right, it can easily win the WTF Crypto Award of the month.

ctz 11y ago
I read it the same way. Tremendously bad!

drostie 11y ago

After I wrote my "nermal" project (npm-installable JS authenticated-encryption container) I wrote a password manager as an example, which I called "tagaloop". Some documentation for it is available here: https://github.com/drostie/nermal/tree/master/examples https://github.com/drostie/nermal/tree/master/examples In particular, I avoided the command-line interface precisely because the other tool on that page, ncrypt, would tend to leak inline passwords and such to log files. For various reasons those options were necessary to perform the job it required (e.g. in a script which is chmod root 500, for example) but not required for its use (it will just prompt you for the info if you leave the flags off). In particular, the -a "add" option in Steel will probably save passwords to ~/.bash_history, no?

dyladan 11y ago
Not only that, but command line options are generally not secure from other users on the system. Just running `ps -ef` can read command line options from any user. A more secure alternative would be running the program in an interactive mode.

brohee 11y ago

Is it really using CFB mode without any kind of authentication? If so, mostly useless...

dchest 11y ago
It actually uses HMAC-SHA256 to authenticate ciphertext, although with the same key as AES encryption.
- brohee 11y ago
  It's worth mentioning it on the homepage, it looks very scary without it.

jarin 11y ago

This is a pretty nice idea, but without a mobile app it would be very difficult to recommend.

swiley 11y ago
Command line apps work pretty well on android, I use them every day.