
Steel – Open-source command-line password manager - nvr82
http://www.steelpasswordmanager.org/
======
zvrba
> 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.

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

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

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

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

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

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

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

~~~
ludbb
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
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...](http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html)).

------
dchest
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
I read it the same way. Tremendously bad!

------
mataug
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
I'd call storing the domain of the password in plain text a metadata leak.

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

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

------
lowry
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
So anything that can read your disk has access to all your passwords?

~~~
reitanqild
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
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?

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

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

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

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

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

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

