In an uncharacterstic move, I type now not to my future self but to the entire world. The importance of my announcement justifies this decision: If you use LastPass, your conception of security is wrong. Expert knowledge is not necessary to understand why, and the only postulate to which you must agree is that of chains only being as strong as their weakest links.
I do not use LastPass, though I consider its accessibility and ease of use a boon to the security ecosystem. I even recommend LastPass to others (family and friends with little inclination toward computers, for example). In recommending LastPass, I do not reveal that its foundation is flawed. Such knowledge is irrelevant to the people to which I recommend LastPass, as these people are not able to customize their window managers. If you are not able to customize your window manager to the point of emulating keypress events from menu items, the remainder of this article will be of little use to you. If, on the other hand, you are, we will be using the following tools:
The end result looks like this (using Openbox):
The window manager’s main menu is opened, and the password menu (P) is selected. A category is chosen (A), followed by the actual item for which a password is retrieved (A). The final item is an encrypted password file that is decrypted by GNU Privacy Guard, with the resulting password output by xdotool to whatever program currently accepts input. Already, we have uncovered three advantages over LastPass and friends…
- Works with any program, not just with forms displayed in web browsers with password plugins installed.
- Fewer entry points. Fewer links in the chain lower the chances of one being weak (the unknown unknowns).
- Customizable and extendable.
… and one quality that LastPass would like to claim a disadvantage:
- Limited to terminals with access to encrypted password files.
I claim this an advantage, because once again, I know that chains are only as strong as their weakest links. Today, it is raining outside. I look outside, and I see clouds overhead. My neighbor sees the same clouds. My neighbor might think those clouds can hold critical documents, but I keep mine locked in a file cabinet in the basement. This is not an issue of trust so much as one of common sense and convenience–because the file cabinet is closer, and tomorrow could very well be a sunny day.
Then again, the whole point of having clouds hold documents is for people to be able to go one town over and still see those documents hanging in the sky. I have had enough of this analogy. If you require access to a critical document on a terminal to which you cannot trust to store an encrypted password file, you are managing passwords wrong. Use “12345” for those. They are not secure, and no quantity of helmets will protect you from sharks while diving. I am an analogy machine.
Critical documents should only be accessed from terminals you are able to claim as your own. You might think you need your online banking password available on any computer with Internet access, but I bet you could count on one hand the number of computers you actually use. Send money, record secrets, and store nude photographs on your own computers, not on some cloud on a cloudy day.
Then when you have separated cruciality from “12345,” make some noise:
uLength="24"
uCount="50"
for (( u = 0 ; u < uCount ; u++ )) ; do
# Output is concatenated to maintain continuity of demonstration.
# For the real deal, use gpg's --output option and forego looping.
gpg --armor --gen-random 2 "$uLength" >> /mnt/hdd_not_ssd/entropy.txt
done
Look at the randomness. These are your passwords. Break them into variable-length chunks, and store them in files. Don’t let your editor back them up, and remember that extra caution during the setup procedure lasts forever:
echo "set nobackup" >> ~/.vimrc
echo "set nowritebackup" >> ~/.vimrc
vim /mnt/hdd_not_ssd/entropy.txt
# Saved to these:
/mnt/hdd_not_ssd/gmail.txt
/mnt/hdd_not_ssd/japan_net_bank.txt
/mnt/hdd_not_ssd/freenode.txt
Gnome-keyring, python-keyring, and libsecret would only be redundant links in your chain. Do not bother assessing their strengths, because they are superfluous. Instead, concoct a good master passphrase and generate a key from GNU Privacy Guard:
gpg --full-gen-key
Encrypt your password files as soon as possible:
gpg --list-keys
> /home/nosuck/.gnupg/pubring.gpg
> ------------------------------
> pub rsa2048/DEADBEEF 2015-04-01 [有効期限: 2016-04-01]
> uid XXX
> sub rsa2048/LIVEBEEF 2015-04-01 [有効期限: 2016-04-01]
sKeyId="DEADBEEF"
gpg -ear "$sKeyId" /mnt/hdd_not_ssd/gmail.txt
gpg -ear "$sKeyId" /mnt/hdd_not_ssd/japan_net_bank.txt
gpg -ear "$sKeyId" /mnt/hdd_not_ssd/freenode.txt
shred /mnt/hdd_not_ssd/gmail.txt
rm /mnt/hdd_not_ssd/gmail.txt
# ... and so on.
Finally, output passwords through your window manager, using xdotool. Though this link is arguably stronger than even physically typing a password on a keyboard, it is still the weakest in our short and sturdy chain:
pGmail="/mnt/no_longer_matters/gmail.asc"
xdotool type --clearmodifiers --delay 5 "$( gpg -qd "$pGmail" )"
You can also use passwords with programs clever enough to take input from places other than GUI toolkits:
cat ~/.muttrc
> set smtp_pass = `gpg -qd /mnt/no_longer_matters/gmail.asc`
cat ~/.offlineimaprc
> remotepasseval = Password ( "/mnt/no_longer_matters/gmail.asc" )
When you’ve memorized your master passphrase, adjust time-to-live settings for its prompting. The following settings will make gpg-agent require master passphrase input only once per day–not as often as it should, but I have little faith in you. Specify in seconds:
echo "default-cache-ttl 43200" >> ~/.gnupg/gpg-agent.conf
echo "max-cache-ttl 86400" >> ~/.gnupg/gpg-agent.conf
You can also force re-prompts for any subsequent password accesses. This is good to do before leaving your computer unattended. Make this command accessible. Mine is never more than four keystrokes away (the “R” item in the animated demonstration). It is a good idea to force a reprompt on system idle and sleep events, as well:
echo RELOADAGENT | gpg-connect-agent -v
… and that is the optimal convenience you can get out of a truly secure password management system. Password entropy level is high; password retrieval is convenient, with the master passphrase only required as often as configured; lastly, the chain of software from password request to password retrieval is as short as feasibly possible.
.. and I didn’t even mention LastPass being closed-source as a deal-breaker from the get-go.
No Suck 
• Yet again.
• “We don’t think so.”
• Outage.
This is turning into ducks in a barrel. I likely missed a few incidents, and there will likely be more in the future—but those will go unreported here, as LastPass’s deficiencies have been sufficiently demonstrated.
Until next time, Internet stranger.
Again (via Slashdot).
LastPass has been hacked.
“Hacked” is a characterization, to be generous. It hasn’t been hacked any more than every bank with an online presence is continuously being “hacked” by lookalike emails.
That doesn’t mean this attack isn’t dangerous – phishing certainly is, as evidenced by the fact that LastPass quickly implemented mitigations for this attack, and this is a particularly convincing phish due to LastPass’s in-browser nature
But in the end, it’s a per-user attack affecting only users who are snared by the phish. LastPass’s infrastructure hasn’t been compromised, which is what “LastPass has been hacked” implies to most people.
I agree with much of what you say. Thank you for the comment.
I oftentimes use sensationalist wording, but where “hack” is concerned, I use a definition that resembles Eric Raymond’s.
“Expert knowledge is not necessary to understand why, and the only postulate to which you must agree is that of chains only being as strong as their weakest links.”
Sorry – but claims require evidence and substantiation.
What is behind your claim that LastPass is “wrong”?
Remember, that while LastPass does incorporate cloud storage, the only item traveling between cloud and local system is an ENCRYPTED BLOB.
You seem to be objecting based on the unsubstantiated claim “cloud storage MUST be inherently less secure”.
The “weakest link” here is likely to be someone with a weak master password and/or not utilizing two-factor authentication for blob decryption, or security holes in the browser extension handling the blob, not in the basic concept itself.
In short, I don’t care if someone dumps my encrypted password file blob onto pastebin, so long as my encryption is strong. Add that I keep a local backup of that blob, and I’m OK even I’m offline, or the service itself crashes and “goes away”.
I’m curious to see if you’ve uncovered some security flaw that even Steve Gibson missed.
I apologize for taking so long to approve this comment, especially because you seem to understand the concept of LastPass so well (well enough to have answered your own question, really).
Sure, postulates may be referred to as “unsubstantiated claims.” The former are a subset of the latter. I did not bother mentioning other postulates like “passwords can provide security” or even “security is good,” just the one postulate that people seem to forget when making the jump to cloud-based services: Increasing the length of a security chain increases the unknown unknowns. (In hindsight, this may be a step above Postulate Land.)
“The ‘weakest link’ here is… security holes in the browser extension handling the blob…”
Bingo. You list others. The list goes on. Also, you fail to poke any holes in the password management scheme described in the original post, and appeals to authority–even if I love his books–have no place here.
I reiterate that LastPass is more or less good, and I continue recommending it to everyday users. It is easy. It is not perfect, however, and users who hold security above convenience should not use LastPass.
It may not be that big of a deal, but your password will show up in the xdotool process. Right now for web stuff I’m just using pass and https://github.com/jvenant/passff which will automatically fill password forms based on the url. More convenient than having to navigate a menu (you don’t have to do anything at all). That said, it would be pretty easy I assume to bind a key in qutebrowser to execute the right xdotool action for the right password based on the url.
Thank you for the insightful comment.
In hindsight, perhaps I should have mentioned zx2c4’s pass utility, as I wholeheartedly agree with its stance concerning the UNIX philosophy. The problem is, I can’t tell what it’s trying to do. Without plugins, it doesn’t seem to bring much to the table–and with plugins, it only becomes more obvious that the plugins didn’t need pass in the first place. Why not cut the middle man and design plugins with a generic gpg installation in mind?
The key binding you describe for qutebrowser would probably be the next logical step. I would stay away from xdotool, though, and allow qutebrowser to pipe gpg’s output directly to an input form. Admittedly, I do not know whether qutebrowser currently allows for something like that, but I give more importance to removing xdotool from the chain of software than to gaining a few keystrokes of convenience.
When that happens, I’ll have an update.