Steel – Open-source command-line password manager | Hacker News Reader

Steel – Open-source command-line password manager

steelpasswordmanager.org

69 pointsnvr8243 comments

> 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.

I use pass ( 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

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.

That is the case for all password managers... A big loop hole imo but one that has to be weighed against having simpler, more similar passwords for services.

If you have a browser password manager, monitoring the clipboard will do nothing.

That only works for passwords you use on the web though.

Which includes the vast majority of exploitable passwords. Passwords that only work on my local machine are of less concern when it comes to being hacked by a random keylogger software.

Reminds me that I tried to see if Emacs did anything to input in password-reading mode, and the content was in clear, only the rendering was obfuscated.

The only workaround I can think of is: don't use the clipboard then.

With pass you can also display the password on the console so you can retype it, but if you're running in an X session you're potentially screwed anyway.

If you wanna get real paranoid, displaying it on your screen isn't the best idea.

https://en.wikipedia.org/wiki/Van_Eck_phreaking

The point of erasing the clipboard is not to protect against malicious software - as others have pointed out, this doesn't work. The point of doing this is to reduce the risk that the user accidentally pastes their password somewhere they shouldn't (e.g. an instant messaging application).

I've also been using Pass. It is excellent, however the problem is that there doesn't appear to be much in the way of support for mobile devices. Not in any solid, working way anyhow. I decided to try out dashlane (http://dashlane.com) and so far it's been excellent with support for android and iOS devices as well as a desktop app and browser support. It does all I need.

Obviously those who like to keep their passwords close to their chests and host the password database on their own server, this won't apply but for the rest of us, I've not found anything as good.

Agreed. There's definitely room for improvement.

An attacker that can read your pipes/sockets can also sniff all your keystrokes, read your clipboard and read from other processes memory. A timer to erase the clipboard is only good to prevent accidents; a malicious program targeting your password manager will simply read the clipboard once a second and watch for changes. Local security is hard.

For a more-secure solution, consider running Qubes OS with a seperate vault VM running a password manager. That way you can induvidually copy passwords to the VM where you want to enter it, without others getting any access to it. Of course, that's too hard for most people, so we end up running everything in the same context and then call it "secure" because we erase the clipboard after 5 seconds.

If you do want to use the primary selection, you can use `xclip -l 1 -quiet`, which will remain in the foreground until a single request is made for its contents (a single paste); it will then quit, and the content will no longer be available.

Not fool-proof, but helps mitigate the risk. If an attacker snoops on the selection, it'll quit before your paste and you'll know that something is wrong.

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?

Shameless self plug: 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.)

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

Steel is not rolling it's own crypto. It uses AES in cfb mode as implemented by libmcrypt.

Building your own abstractions on top of AES directly is no less dangerous or prone to error.

> 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.

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.

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.

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.

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) which provides bad implementations, namely generate_pass which seeds from timestamp and verify_hmac which is not a constant time comparison function.

Yes, it absolutely is[0] for essentially the exact examples you cite.

[0]: http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.h...).

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.

I read it the same way. Tremendously bad!

I use pass ( 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.

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

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

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?

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.

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.

I prefer using 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.

So anything that can read your disk has access to all your passwords?

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.

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?

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

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

It actually uses HMAC-SHA256 to authenticate ciphertext, although with the same key as AES encryption.

It's worth mentioning it on the homepage, it looks very scary without it.

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

Command line apps work pretty well on android, I use them every day.

Reply on news.ycombinator.com