Basics
Terms
- Identity: unique characteristics of an individual.
- Authentication: who is this ?
- Authorization: what are they allowed to do ?
- Non-repudiation: can it be proved/audited that a person did an action ?
- Privacy: who can see what this person does ?
- Security: are these answers/attributes maintained over time ?
Authentication Scenarios
- Local: local user to local machine or application.
- Client to Application Server: local user/app to an application/web server.
- Application Server to Authentication/Authorization Server: back-end server-to-server communication.
- Single Sign-On: local user/app to authentication/authorization server to multiple application/web servers.
Ways to access or attack an account (attack surface)
Access:
- Normal login (maybe password, maybe with 2FA)
- Password reset
- Account recovery
- Persuading Customer Support (social engineering)
- Phishing (to get credentials)
- Denial of service (report account as violating TOS, trigger "suspended because too many bad login attempts",
flood account with messages or comments or confirmations)
- Impersonation (look-alike account or domain)
- Cause misuse (get user to click on a link that does something in the account, provoke user into violating TOS,
get user to join group that gets banned)
Password security
Use the password and security features of your device and software; many people don't even bother to set a password !
It's especially important on smartphones, because a lot of smartphone apps don't even have a "log out" feature. They assume that if you have the phone and were able to log in once, a while ago, you must be the account owner, no account password needed.
But some passwords are fairly easy to bypass; don't expect them to protect you from every threat:
Computer Hope's "How to clear an unknown BIOS or CMOS password"
Mark Wilson's "How to crack Windows and OS X passwords"
Hack Cave's "Hack Windows 10 Login Password In 2 Minutes [Works For All Windows Versions]"
Hack Cave's "Hacking/Bypassing Android Password/Pattern/Face/PIN"
Don't use the same password on multiple sites. If one site is breached, all the others become vulnerable.
Qualities of a good password
[From most important to less important:]
- Unique (not used anywhere else, doesn't appear in any breaches).
- Long (at least 16 chars, probably).
- Complex (not just lowercase and numbers).
Good things along with the password
- Unique username for each site (not just the same email address everywhere).
- Two-factor authentication (on important accounts).
Really, you should have only 2 or 3 passwords you remember; the rest should be in a password manager. And in general, length is more important than complexity (but having both is even better).
When to change a password
- If the service has a data breach.
- If you realize the password is weaker than it should be for that kind of account.
- If you realize you've used the same password on other sites.
- If you've shared the credentials with someone else or some other service, and want to stop their access.
If a password you're sure is correct stops working, maybe your keyboard is in a mode such as caps-lock or function-lock, or maybe a key has failed. Test it by typing the password into a document or some visible field.
Another form of password is an SSH key. Advantage: it's very long and random. Disadvantage: few connection types support it, usually just command-line text login connections, or network operations such as a git commit or VPN login.
"Password inertia": I'm discouraged from changing some passwords because I'd have to update them in multiple places. For example, an email password would have to be updated in the email site, my password manager, my desktop email client, and my phone email client.
Password Manager
AKA a "password vault".
For best security, I recommend a local-only password manager application, not storing data in the cloud, and with no browser extension or browser integration. I use the KeePass family of applications.
If you want more convenience, or need to support non-techie users, or need to share among several devices and/or people, probably use Bitwarden.
On Linux, consider running the password manager either in a container (snap or flatpak) or in a security context (Firejail or AppArmor).
Reasons to use a password manager
- Avoids forgetting passwords and other info.
- Avoids writing down passwords on Post-It's and other insecure places.
- Makes it easy to use a different password for every web site.
- Makes it easy to use long random passwords.
- Makes it easy to use two-factor authentication such as software-TOTP.
- Makes it easy to see/report duplicate passwords.
- Makes it easy to see/report accounts that don't use 2FA.
- Makes it easy to look at list of accounts and delete ones you don't want any more.
- Makes it easy to group and share info across multiple family members.
- Some will check for your info appearing in data breach lists.
- Great place to store other important info such as photo of passport ID page,
info for reporting lost credit card, etc.
Some passwords they can't apply automatically: your PC's BIOS and OS login info, encrypted boot drive's password, game-console password, phone password, ATM and credit-card PINs. You can store those passwords in the password manager, but not drag/copypaste them out to apply them. [Except see InputStick, which lets a password manager on your phone drive a keyboard on your computer.]
A quirk: every now and then, I find I have to type a password manually. Maybe I'm reading it out of the password manager in my laptop, and typing it into someone's phone. In that case, having a long password that mixes lots of letters and numbers and special characters is a real pain. And having similar-looking characters such as "1" and "l" and "0" and "O" is a pain. So I try to avoid generating passwords with that last problem. Some managers have a setting to control this. Maybe also group the types of characters together inside the password: start with N uppercase letters, then M lowercase letters, then P special characters.
Arguments against password managers
- Single point of risk for ALL your information.
If the database is stolen and cracked, you're in big trouble.
- Single point of failure for ALL your information. If you lose the database or forget the
master password, you're in big trouble.
- Making it too automatic maybe is a bad idea. If someone can sit down at your computer,
open a web page, and your password manager immediately logs them in, that's bad.
If malware on one page can open another page, and your password manager immediately
logs it in, that's bad.
- A password manager may be too complicated for some people. But some password managers are pretty simple.
And it's not clear that any other safe method would work for such people unless they have very few accounts.
And if they use paper, are they going to back it up, and protect it from being stolen or copied ?
- One major risk: if you store your bank login info in a password manager, and it gets hacked, and the
thief empties your bank account, neither the password manager company nor (maybe) your bank will compensate you.
Both will deny any liability, according to their terms of service. Your money will be gone.
Stuart Schechter's "Before You Use a Password Manager"
Dan Goodin's "'Severe' password manager attacks steal digital keys and data en masse"
Martin Vigo's "Even the LastPass Will be Stolen, Deal with It!"
Linus Sarud's "Thinking outside of the password manager box"
Michael Horowitz's "The world's BEST password advice"
With enough effort, and maybe good starting guesses, password manager databases are crackable. See for example: My "keepasscrack" project
devio's mod0keecrack
ElcomSoft blog
ISE's "Password Managers: Under the Hood of Secrets Management"
Ruby Devices' "How to Hack KeePass Passwords using Hashcat" (not sure works on KDBX 4)
Rickard's "Cracking KeePass Database" (not sure works on KDBX 4)
But of course you could store the database inside an encrypted VeraCrypt or LUKS container or something, to add another layer of protection.
Crack a KeePass version 3.1 database ?
# Use KeePassXC to create a test database version 3.1.
# Submit database file to https://hashes.com/en/johntheripper/keepass2john
# or:
sudo snap install john-the-ripper
john-the-ripper.keepass2john test.kdbx >hash.txt
# Paste hash into https://crackstation.net/
# Didn't work !!! unrecognized hash
john-the-ripper --help
# Create a hash: https://md5calc.com/hash/sha256/1234
# Paste into https://crackstation.net/
If you're worried about someone gaining access to your password database, you could do "peppering", which means adding or omitting a standard part to each password. For example, if the real password for a site is "password123", in the database store "XXpassword123" or "password". Then when logging in, remove the "XX" or add the "123". Probably you'd use the same "pepper" string for all sites. This would make auto-type less convenient. And it seems overkill to me. But you could do it.
If someone could gain write access to your system disk, they could replace the password manager app with a poisoned version that steals your master password. Or they could modify the app's configuration files to do various bad things.
Types of password managers
- Vault: store passwords.
- Generator: generate passwords based on a master password.
- Built into browser.
- Separate application that does paste or auto-type to browser.
- Separate application that uses a browser extension.
- Local-machine-only.
- Synced to a cloud account.
- Synced peer-to-peer.
Features to consider
- Price.
- Type:
- Online: your passwords are stored online, which is bad (have to trust that place; what if they go bankrupt) and good (accessible from any device; backed up). Usually there will be a synchronized local copy of your password database, too.
- Local application: your passwords are stored only on your device. You have to do backups.
- Feature of a security suite: same as local application.
- Browser feature: first implementations of this had some holes/bugs, no way to sync across different brands of browsers, maybe no way to sync across multiple devices.
- Browser add-on, or bookmarklet (JavaScript): maybe same issues as browser-feature type.
- Devices supported (PC, smartphone, tablet, etc).
- OS's supported.
- Browsers supported (almost all managers use a related add-on in your browser).
- Syncing devices to each other.
- Cloud backup.
- Handles application passwords.
- Supports two-factor authentication to web sites.
- Handles credit card info.
- Handles bank account info.
- Supports fingerprint (biometric) or 2FA to open the password manager itself.
- Miscellaneous: form-filling, import from other managers, automatic login capture, profile info, notes, credit report monitoring, data breach monitoring, etc.
Don't use your OS's "keyring" features: it's not cross-platform, maybe not shareable across multiple machines, may be hard to back up and restore, probably has a primitive UI. Use a dedicated password manager application.
Wikipedia's "Password manager"
Slant's "What are the best offline password managers?"
Alan Henry's "Five Best Password Managers"
Hannah Stryker's "The Best Password Managers of 2023"
Some free password managers
KeePass (many forks: I use KeePassXC on Linux, Keepass2Android Offline on Android)
Bitwarden (uses server, either cloud or self-hosted [article; free version now called vaultwarden])
IronVest (formerly Blur) (more than just a password manager)
Dashlane (free plan limited to 50 passwords)
LastPass (not open-source; lots of trackers)
Buttercup
MYKI (not open-source; must have phone for login ?)
pass (article1, article2)
Password Safe (pwsafe / pwsafe)
gopass (more team-oriented)
Heard on a podcast: With Bitwarden, only the whole encrypted database goes to/from the cloud. Your master passphrase or individual passwords never go to/from the cloud. The whole encrypted database gets copied down to your local machine, and then all operations are done on that local database.
I don't use any 2FA on the login to my password manager, just a password. I don't want any accident (loss of phone, loss of hardware token) to lock me out of my password database.
I don't want a password manager tied to a cloud account. I don't want any accident (account locked) to lock me out of my password database.
I don't want a manager with a browser add-on that watches every web page I load; that increases the attack surface of both apps. And an offline manager is more secure.
Tavis Ormandy's "Password Managers"
[But having a browser add-on gives one great feature: it can check that you're putting the creds into only the site that they belong to.]
Ctrl blog's "Why KeePass instead of self-hosting Bitwarden"
I chose KeePass.
Android
Some strange things on Android: there is no "log out" in the Yahoo Mail app; you have to "remove" your email account, and then when you add it back later, you're asked for your phone's PIN, not your Yahoo Mail password. Similar for GMail app, but even worse: removing your GMail account could affect many other services on the phone. Proton Mail app also has no logout; after password is given at installation time it never asks for password again. Reddit app has a "log out" button, but then when you log back in, it doesn't ask for a password, you're just back in ! The Tripadvisor, AirBNB, and FaceSlim apps do have a proper sign-in/sign-out behavior. The WhatsApp app has no sign-out at all. I guess you could use the browser and web sites instead of installing these apps, but then you lose a lot of functionality and nice UI.
Reasons to use a password manager on a smartphone, despite the app issues I listed:
From /u/VividVerism on reddit:
Logging into web pages. Signing into apps for the first time. Signing into apps after deleting data and/or reinstalling and/or factory reset. Banking apps and similar high-security apps that do require a password either to log in or confirm a purchase/transfer/etc. Storing Wi-Fi passwords. Having your passwords handy for manually logging into sites on computers you don't own, or while traveling. Storing things other than passwords, such as credit card information, social security numbers, or library card information. Installing plugins to let you transfer passwords via QR code or to plug your phone into a computer via USB to type your passwords for you. Using the TOTP features to generate 2FA codes instead of a dedicated app. Storing passwords for any new accounts you set up on your phone. Keeping a database backup with you.
I'm probably missing a few use cases. In short, yes: there are plenty of reasons a password manager can be useful on a phone.
My organization inside the password manager
Organization:
- One top-level group for each person in my family for whom I manage data.
- A top-level group for my bookmarks.
- Inside the group for my bookmarks, sub-groups for categories of bookmarks.
- Top-level group created by the password manager: Recycle Bin.
- I store many things in the password manager: accounts, software TOTP codes, recovery codes, photos of passports and healthcare cards and bank cards etc, bookmarks, info about equipment such as phones and routers, Wi-Fi network info, phone numbers, etc.
- I back up the password manager database to many places, but none of them online/cloud. Encrypted external hard disks, mainly. Encrypted thumb drives which I give to relatives to store in their houses.
- Every few weeks, I copy the password manager database to my phone, for use there. I don't like this; some app or Google code could copy it up to the cloud.
- Every month or two, I copy the whole database, then modify the new copy to strip out my personal top-level group and my bookmark group, then move the new database to my wife's computer. So if I die suddenly, she'll have all the important info.
Don't let Windows store passwords and apply them automatically. If someone cracked your Windows password, they would get automatic access to those things. I set my backup application to not "remember" me, so I have to log in to it manually every time I run it. If you have an encrypted external hard disk, don't let Windows hold the password and apply it automatically (auto-unlock); you should type it in manually each time you plug in the disk drive.
Don't let your browser store passwords and apply them automatically. The quality of their security is unclear, and that method works only inside that browser. Not sure how backup and restore would work. Much better to use a dedicated password manager application.
Passwords, from article by Jacob Bernstein in The New York Times, June 24 2012:
... it is less clear to cybersecurity experts that having a password with extra numbers or special characters actually makes customers safer.
"People's choice of passwords is not the real problem today", said Dr. Joseph Bonneau, a University of Cambridge researcher who studies cyber security. "The real problem is typing in passwords to the wrong Web site, which is stealing them."
So why are Web sites suddenly requiring users to add special characters or numbers ? "It's security theater", Dr. Bonneau said. "So people feel safe. It makes the Web sites seem like they're taking things more seriously, when in fact most of them have no control if you have malware. In absence of a way to tackle bigger problems, it's easy to add restrictions. They don't want to seem less secure than competitors."
New feature idea: handle name+address info, credit-card info, bank-acct info
Does any password manager support this already ? Maybe an idea for one to do:
- Ability to have entries that could be tagged as "postal info", "credit-card info", "bank-acct info",
in addition to the usual "login info" entries.
- When you copy-and-paste or auto-type such an entry from the password manager to a web page,
it would have to use web form-field names, or text labels next to form-fields, to put the
right data in the right fields. Tricky.
New feature idea: handle hierarchical info
Does any password manager support this already ? Maybe an idea for one to do:
Some sites, such as Privacy.com, "contain" a second level of information, such as a list of virtual credit-cards. It would be nice to have one entry (e.g. for Privacy.com) that then contains N sub-entries (e.g. one for each virtual credit card). I'd like to have an easy way to paste a credit card's info into a web page.
Similar for a bank where you have multiple accounts: one entry for the bank site, then a sub-entry for each account, and an easy way to paste an account's info into a web page.
Maybe in a current password manager, you can do something similar by using Groups. I have a Group for each person in my family. Suppose I also had a Group for "my Privacy.com cards" ? Then each entry in the Group would be for one card inside my Privacy.com account.
What is a password generator ?
A password manager stores passwords (and TOTP secrets, and recovery codes, and URLs, and anything else you wish). A master password unlocks the whole database. If the database is copied and cracked, the attacker gets everything.
A password generator generates (calculates) passwords on the fly by combining master password with various info (username, site name, URL, stored secret/salt). If the database is copied and cracked, the attacker doesn't have enough information to generate passwords (is missing the master password).
Take a simple case for password generator: each site password is formed by concatenating site domain and master password, then hashing it. So if your master password is "1234", password for "facebook.com" will be hash of "facebook.com1234". "1234" and "facebook.com1234" and the hash value are not stored in the database anywhere. Actual password for facebook.com web site is generated (calculated) each time you need it.
What happens if you change your master password ? Maybe not a problem, if master password just unlocks access to a master key, and master key is used to generate all site passwords. But then that master key will have to be stored in the generator's database, not good.
Can you import existing creds from your current password manager ? I think probably not.
LessPass
Spectre
There's no perfect solution
- Remember all your passwords ? There are too many to remember, and will encourage
using short simple passwords.
- Use a paper notebook ? Vulnerable to physical theft, inconvenient to backup,
inconvenient to search, doesn't have features such as TOTP, and will encourage
using short simple passwords because of all the typing.
- Use browser's password manager ? Level of security is unclear,
doesn't work for other browsers and applications (except on Android), probably can't store other
data such as pictures of ID cards or 2FA cards.
- Use browser extension from external password manager ? Extensions are sort
of inherently unsafe (compromise browser's sandbox), and I don't want a live
connection between my entire password database and a networked app (browser) that is running
tons of untrusted code (JavaScript).
- Copy passwords from external password manager to browser ? Now your passwords
are visible (briefly) in the clipboard.
KeePass
I chose
- On Linux, KeePassXC 2.x.
- On Windows, KeePass 2.x.
- On Android, Keepass2Android Offline.
General choices and use
- In database security encryption settings, change file format to latest version, and
increase the decryption time for more protection.
- In my cloud backup application, I disabled backup of the KeePass database file.
I want to back it up to my own devices (external hard drive, etc) only.
- The master database is on my Linux machine. Periodically, I copy
the database through USB cable to my Android phone, and copy a modified database via flash drive to
my wife's Windows machine.
- I keep almost all bookmarks in KeePass, not in my browsers. That way they're stored encrypted,
one copy instead of separate copies in each browser, no way for rogue JavaScript or browser extension
to copy all my bookmarks. So I'm using KeePass as both a password manager and a bookmark manager.
- I do software TOTP via KeePass, not in a separate dedicated app. This is less secure (if someone
cracks my KeePass database, they get everything), but more convenient than dealing with two apps,
especially on two devices.
On Linux
Tried various versions, ended up with Keepassxc (2.3.1+dfsg.1-1) from Mint's Software Manager, for a while:
Installed and ran Keepass2 password manager (2.3.8) from Mint's Software Manager, opened the database I brought over from Windows, works.
But the usual key-shortcuts (Ctrl+F, Ctrl+U, Ctrl+V) don't work in Keepass. Looked at updating from 2.38 to 2.39,
and the procedure looks ugly. Had to do "sudo apt install xdotool" to get auto-type to work.
Later tried FlatPak version (2.3.3) of KeepassXC. There is a Search field in upper-right but no way to limit search to just Title field, Ctrl+F and drag-and-drop a password don't work, Ctrl+U and Ctrl+V do.
Also there is a Snap version of KeepassXC. Keepassxc.org web page says install via "sudo snap install keepassxc", but had to do "sudo apt install snap" first, and then "sudo snap install keepassxc" failed anyway, said "sudo: snap: command not found".
Installed Keepassxc (2.3.1+dfsg.1-1) from Mint's Software Manager; there is a Search field in upper-right but no way to limit search to just Title field, Ctrl+F puts focus in the Search field, Ctrl+U and Ctrl+V work, drag-and-drop a password doesn't.
Installed Keepassx (2.0.3-1) from Mint's Software Manager; Ctrl+F makes a Search field appear but no way to limit search to just Title field, Ctrl+U and Ctrl+V work, no way to drag-and-drop a password.
Someone on reddit said to install "mono-complete" and then try Portable 2.39.1 from Keepass.info. It looks to be Windows-only, but after extracting it, run "mono KeePass.exe". But most things don't work: Ctrl+F, Ctrl+U, Ctrl+V, drag-and-drop.
Ended up staying with Keepassxc (2.3.1+dfsg.1-1) from Mint's Software Manager. Not happy: search is awkward, drag-and-drop doesn't work, no plug-ins. But one bonus: TOTP works. And someone on GitHub says searching will be fixed/better in next major release, 2.4.
Added "ppa:phoerious/keepassxc" to PPAs in Software Sources app.
Later I changed from Mint to Ubuntu, and to snap version of KeePassXC
Works fine for me. I'm not using any of the fancy integrations (with browser, or SSH, or supplying
secrets to apps, or global auto-type). I use manual auto-type from KeePass to other apps (usually browser).
Later I installed Eric's "Add URL to Window Title" browser extension. This is not KeePass-specific; it modifies tab titles in the browser so they include URL as well as human-readable title, which is useful for "global auto-type".
To enable "global auto-type", go to Tools / Settings, go to Auto-Type tab, click mouse into "Global Auto-Type Shortcut" field, then type ctrl+shift+alt+A (or some other key-sequence that is unused). Save. Later, if you want to disable it, put mouse in field and type Esc.
I auto-type username and password from KeePass application into login web page.
Several ways to do auto-type
- Auto-type [I use this]:
- In KeePassXC, find entry for the site you want.
- Ctrl+shift+U to switch to browser and tell it to open that site.
- Alt+tab to switch back to KeePassXC.
- Ctrl+shift+V to switch to browser and auto-type username and password and Enter.
- Get web page that asks for TOTP.
- Alt+tab to switch back to KeePassXC.
- Ctrl+T to put TOTP in clipboard and switch to browser.
- Ctrl+V or similar to paste TOTP into web page field.
- Enter or click button on web page to complete login.
- Global auto-type (with bookmarks in browser):
- In browser, Alt+B and select bookmark for the site you want.
- Web page opens.
- Ctrl+shift+A to start global auto-type.
- See small KeePass window telling you which entries match the current web page.
- Click an entry in the window.
- See KeePass auto-type username and password and Enter.
- Get web page that asks for TOTP.
- Alt+tab to switch back to KeePassXC.
- Ctrl+T to put TOTP in clipboard and switch to browser.
- Ctrl+V or similar to paste TOTP into web page field.
- Enter or click button on web page to complete login.
- Global auto-type (with bookmarks only in KeePass):
- In KeePassXC, find entry for the site you want.
- Ctrl+shift+U to switch to browser and tell it to open that site.
- Ctrl+shift+A to start global auto-type.
- See small KeePass window telling you which entries match the current web page.
- Click an entry in the window.
- See KeePass auto-type username and password and Enter.
- Get web page that asks for TOTP.
- Alt+tab to switch back to KeePassXC.
- Ctrl+T to put TOTP in clipboard and switch to browser.
- Ctrl+V or similar to paste TOTP into web page field.
- Enter or click button on web page to complete login.
In KeePassXC, you can see which passwords are being used in multiple accounts by going to the main table view of accounts, right-clicking on "Password" column header and un-checking "Hide Passwords", and then sorting by "Password" column.
Someone says their KeePassXC started behaving a bit erratically when they put some large documents into the database and it got near 50 MB in size. Sizes below 20 MB at least work fine.
KeePassXC
Keyboard Shortcuts
Bug reports: keepassxreboot / keepassxc
securityguideme's "KeePassXC Advanced Usage // 8 features you might have not heard about" (video)
KeePassXC can supply SSH keys to an SSH agent
[I got this working, but later decided it wasn't worth it, I only have one SSH target I use, easy enough to copy and paste the password.]
See instructions in setevoy's "SSH: RSA keys, and ssh-agent for SSH keys and their passwords management"
Also setevoy's "KeePass: an MFA TOTP codes, a browser's passwords, SSH keys passwords storage configuration and Secret Service integration"
Jack Wallen's "How to integrate SSH key authentication into KeePassXC"
VaLouille's "How to use KeePassXC with ssh-agent to secure private key access"
Marco Sarti's "Managing credentials with KeePassXC"
kvaps' "Store SSH Keys Securely"
Carl Tashian's "SSH Agent Explained"
- Set keys for a remote host:
- Maybe pick a free remote host for testing. https://shells.red-pill.eu/ ? I tried https://sdf.org/ but it didn't work right.
- On CLI, run "ssh remote_username@remote_host" to connect to remote host. Get warning that this is an unknown host, want to connect ? Type "yes". Get prompted for password. Type password. Get logged in. Type "exit" to get out.
- See that SSH has updated ~/.ssh/known_hosts to include an encrypted entry for that remote host.
- Run "ssh remote_username@remote_host" to connect to remote host. Get prompted for password. Type password. Get logged in. Type "exit" to get out.
- Now create keys to use with that host. On CLI, "ssh-keygen -t rsa". Get prompted to pick base filename for the key files (default: id_rsa gives files ~/.ssh/id_rsa.pub and ~/.ssh/id_rsa, but it's clearer if you pick another name NAME_rsa). Get prompted to pick a passphrase for the private key. I just hit Enter, no passphrase. Files ~/.ssh/NAME_rsa.pub and ~/.ssh/NAME_rsa will be created.
- Copy the public key to the remote server: "ssh-copy-id remote_username@remote_host". Type password to log in.
- Run "ssh remote_username@remote_host" to connect to remote host. You should not be asked for the password. (Fails on sdf.org, still wants password. Works on another system.) Get logged in. Type "exit" to get out.
- Set KeePassXC as a key server (is that the right term ?):
- In KeePassXC, go to Tools / Settings / SSH Agent and check "Enable SSH Agent". Click Okay button. Quit KeePassXC and launch it again.
- On CLI, run "systemctl status | grep ssh-agent" to see if ssh-agent is running. It should show that "/usr/bin/ssh-agent" is running.
- If not running, do "eval $(ssh-agent)" ?
- Run "ssh-add -l" or "ssh-add -L" to see all keys available through ssh-agent. The key created in the previous section should NOT be present.
- Store private key in KeePassXC:
- In KeePassXC, create an entry "NAME SSH" or something (name doesn't matter).
- Leave the username field empty (important).
- If the key is passphrase protected, put passphrase in the password/repeat fields.
- Go to the "Advanced" section of the entry and upload the NAME_rsa file as an attachment (file NAME_rsa.pub is the public key and file NAME_rsa is the private key). You probably have to navigate to your home directory and then type ".ssh/NAME_rsa" in the filename field, it won't show dot-directories.
- Go to the "SSH Agent" section of the entry and select the private key NAME_rsa in the Private Key / Attachment drop-down list.
- Click the "Add to Agent" button. (Fails if you still have GNOME Keyring installed.)
- Check the two check-boxes for "add key to agent when database is opened / unlocked" and "remove key from agent when database is closed / locked".
- Check the check-box for "Require user confirmation when this key is used". Not necessary, but it will help show that the key is coming from the right place, later.
- Save the entry.
- Run "ssh-add -l" or "ssh-add -L" to see all keys available through ssh-agent. The key created in the previous section should be present now.
- Rename files ~/.ssh/NAME_rsa.pub and ~/.ssh/NAME_rsa to same names with ".saved" appended. Do that for all *_rsa* files in ~/.ssh directory.
- Run "ssh-add -l" or "ssh-add -L" to see all keys available through ssh-agent. Should see no keys.
- Log in to remote host using key in KeePassXC:
- Have KeePassXC running.
- On CLI, run SSH to connect to associated server.
- Run "ssh remote_username@remote_host" to connect to remote host.
- The key stored in KeePassXC has the server name encoded inside itself, so the appropriate key will be found automatically.
- You'll see a "okay to use key ?" dialog. [A bit strange: it will say "id_rsa" although that is not the name of any file or key ?] If you set a passphrase on the key, you'll have to type it. Click Okay.
- Get logged in. Type "exit" to log out.
- If ~/.ssh/*rsa* files don't exist, and KeePassXC is not running:
you'll be prompted for the password. - If ~/.ssh/*rsa* files don't exist, and KeePassXC is running:
you'll see a "okay to use key ?" dialog, click Okay, key from KeePassXC will be used. - If ~/.ssh/*rsa* files do exist, and KeePassXC is not running:
you'll be logged in with no dialog and no password prompt. - If ~/.ssh/*rsa* files do exist, and KeePassXC is running:
you'll see a "okay to use key ?" dialog, click Okay, key from KeePassXC will be used.
Dialog not shown if you un-check "Require user confirmation ..." in KeePassXC entry.
I think the advantages/disadvantages of the cases are:
- If you store everything in KeePassXC, it's encrypted and password-protected.
- If you store everything in ~/.ssh/*rsa* files, you don't have to type password each time you do SSH, but an attacker only has to copy those files to get access.
- If you have neither ~/.ssh/*rsa* files nor KeePassXC, you have to type a password every time you do SSH.
KeePassXC as 'secret service' to give password to app or service over D-Bus
[Got it working a bit, but haven't found an app that uses it, no naming standards, etc.]
See instructions in setevoy's "What is: Linux keyring, gnome-keyring, Secret Service, and D-Bus" (also Arseny Zinchenko (setevoy)'s "What is: Linux keyring, gnome-keyring, Secret Service, and D-Bus")
Also setevoy's "KeePass: an MFA TOTP codes, a browser's passwords, SSH keys passwords storage configuration and Secret Service integration"
Later: setevoy's "Linux: gnome-keyring setup as Freedesktop SecretService"
Set KeePassXC as a key server:
- In KeePassXC, use Group / New group to create a new top-level Group called "SecretService". Quit KeePassXC and launch it again.
- In KeePassXC, go to Database / Database Settings / Secret Service Integration. Click radio button for "Expose entries under this group" and select group "SecretService". Click Okay button. Quit KeePassXC and launch it again.
- Someone says: in that group you've exposed, "never clone an entry there, libsecret will crash somehow!"
sudo apt install libsecret-tools
secret-tool store --label=SecretToolExample UserName username1 service secret
# it will prompt for the password you want to save
# should show up in KeePassXC group "SecretService" with Title "SecretToolExample"
# but instead shows up in Mint's "Passwords and Keys" app (Seahorse) under Passwords / Login
# retrieve the password
secret-tool lookup username username1 service secret
# get PID of process acting as secrets server:
qdbus --session org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.secrets
ps -f --pid THEPIDHERE
# this should NOT remove the data (under ~/.local/share/keyrings),
# but back it up first anyway
apt remove seahorse
apt remove gnome-keyring # doing this removed skypeforlinux !
# gnome-keyring-daemon process still running; reboot
# [Much later, I re-installed Skype, which re-installed gnome-keyring,
# which seems to take priority over KeePassXC's secret service,
# can't get any info out of KeePassXC.]
# get PID of process fails; expected to see KeePassXC
# In KeePassXC Tools / Settings / Secret Service Integration I see no groups "exposed"
dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames | grep 'org.freedesktop.secrets'
# gives nothing
sudo aa-disable /etc/apparmor.d/usr.bin.keepassxc
# NOW I can see keepassxc running as server
secret-tool search Title test1
# gives password and then core-dump !
# capture DBUS debug log output
dbus-monitor "interface='org.freedesktop.Secret.Service'" "interface='org.freedesktop.Secret.Collection'" "interface='org.freedesktop.Secret.Item'" "interface='org.freedesktop.Secret.Prompt'" > dbus.log
# if no server is running and I run
secret-tool search ... service secrets
# I get
secret-tool: ...ServiceUnknown: The name org.freedesktop.secrets was not provided ...
# all of these should result in entry found:
secret-tool search Title test1 # gives entry, then core-dumps
secret-tool search username user222 # gives nothing
secret-tool search Username user222 # gives nothing
secret-tool search label user222 # gives nothing
secret-tool search Label user222 # gives nothing
secret-tool search Password pass222 # gives entry, then core-dumps
secret-tool search URL test1.com # gives entry, then core-dumps
secret-tool search URL test1.com service secret # gives nothing
secret-tool search URL test1.com service secrets # gives nothing
# all of these should result in entry found:
secret-tool lookup Title test1 # returns password
secret-tool lookup username user222 # gives nothing
secret-tool lookup Username user222 # gives nothing
secret-tool lookup label user222 # gives nothing
secret-tool lookup Label user222 # gives nothing
secret-tool lookup Password pass222 # returns password
secret-tool lookup URL test1.com # returns password
secret-tool lookup URL test1.com service secret # gives nothing
secret-tool lookup URL test1.com service secrets # gives nothing
# if in KeePassXC, in a SecretService entry's Advanced tab, you add a new unique
# attribute such as "attr111" with value "value111", later you can do:
secret-tool lookup attr111 value111 # returns password
# these work
secret-tool store --label=test4 UserName user444 service secret # set password to pass444
secret-tool store --label=test5 UserName user555 # set password to pass555
# list all aliases
dbus-send --session --type=method_call --print-reply --dest=org.freedesktop.secrets /org/freedesktop/secrets/aliases org.freedesktop.DBus.Introspectable.Introspect
# the devs for secret-tools told me to try the newest version, but
# I can't figure out how to get it. They say there's no standard for
# field names. Searching by password is not supposed to be possible.
# what apps use libsecret ?
# https://wiki.gnome.org/Initiatives/GnomeGoals/LibsecretMigration
# network manager applet, disks utility
# I don't use the others.
# But I can't see anything on my Mint 19.2 system that is using it.
# Could install KeePassXC browser extension (Keeshare) to put info into
# web pages, but I don't want to do that, I like auto-type.
# Apps I'd like to have using libsecret: MEGAsync client, Skype, Thunderbird,
# VeraCrypt, OpenVPN client, Windscribe client,
# network manager (nm-applet, NetworkManager, NetworkManager.conf)
KeePassXC run on the CLI
man keepassxc-cli
keepassxc-cli open PATHOFDATABASEFILE
# now in interactive mode
db-info
ls
ls GROUPNAME
search ENTRYPATTERN
show ENTRYPATH
close
quit
How to run keepassxc-cli when it's inside the KeePassXC Flatpak:
flatpak run --command=keepassxc-cli org.keepassxc.KeePassXC open /home/user1/myinfo.nocloudbackup/KeePassDatabase.kdbx
search reddit # case-insensitive
show /Bill/Reddit # use backslashes to escape any spaces in path
clip -a username /Bill/Reddit 45 # copy username to clipboard, clear after 45 secs
clip -t /Bill/Reddit 45 # copy TOTP to clipboard, clear after 45 secs
close
quit
Other URL protocols
In an entry, the URL can be of form:
cmd://bash -c "ls >/home/user1/111.txt" cmd:///bin/bash -c "ls >/home/user1/111.txt" cmd:///home/user1/tor-browser_en-US/Browser/start-tor-browser SOMEONIONADDRESSCmd is hard-coded into KeePassXC; all other protocols are just handed to xdg-open.
KeePass Help Center's "URL Field Capabilities"
Config file is ~/.config/keepassxc/keepassxc.ini
I want the ability to store an Onion URL in KeePassXC and launch Tor Browser if I say "open URL". There is a Tools / Settings / Browser Integration section, which knows something about Tor browser, but I don't think that's what I want. Only way to do what I want is to write the URL as a cmd:// URL ?
https://askubuntu.com/questions/514125/url-protocol-handlers-in-basic-ubuntu-desktop/739199
~/.config/mimeapps.list
On Windows
I installed KeePass Password Safe 2.x.
KeePass Plugins and Extensions
Firefox add-on to support global auto-type and maybe allow additional checking: Eric's "Add URL to Window Title"
/u/Rafficer's "How to set up automatic login with 2FA and Two-Password mode with KeePass 2"
On Android
I installed Keepass2Android Offline.
Connect cable to PC and copy KeePass database file to phone to get the file into Internal Storage / Android / Data, then have Keepass2Android Offline access it from there.
I worry that having the database on my Android phone means that any malicious app could copy it and send it to a server. Which defeats my "never put the database in the cloud" policy. One tactic that may help: rename the database file from "KeePassDatabase.kdbx" to something like "garbage.txt". KeePass doesn't care what the name is. Maybe avoid names that would trigger anti-virus or compression software, if you're using those.
Brandon Lee's "Sync KeePass for Windows with Android and iOS"
Ctrl blog's "Be wary of file sync conflicts with KeePass apps on Android"
KeePassXC as a 'Bookmark Manager'
Instead of storing bookmarks in the browser, where potentially a malicious extension or a security hole or the browser vendor could grab them, store them in KeePass.
I have a top-level group for each person in my family. I added another top-level group for "MynameBookmarks".
Limitations: JavaScript bookmarks ("bookmarklets") have to stay in the browser. Also Firefox "keyword" bookmarks such as being able to type "w michigan" in the address bar and having it automatically do a Wikipedia search on "michigan".
Exporting bookmarks from Firefox to KeePassXC:
- Export bookmarks from browser (Firefox) to an HTML file:
ctrl+shift+O, Import and Backup / Export bookmarks to HTML. - Copy or rename HTML file to input.txt.
- Hand-edit input.txt to delete first lines, from file start through "</H1>".
http://sed.sf.net/grabbag/tutorials/sedfaq.txtsed 's/ ICON="[^"]*"//' <input.txt \ | sed 's/ ICON_URI="[^"]*"//' \ | sed 's/ ADD_DATE="[^"]*"//' \ | sed 's/ LAST_MODIFIED="[^"]*"//' \ | sed 's/ LAST_CHARSET="[^"]*"//' \ | sed 's/<DT>//' \ | sed 's/<\/DT>//' \ | sed 's/<DL>//' \ | sed 's/<\/DL>//' \ | sed 's/<HR>//g' \ | sed 's/<p>//' \ | sed 's/<H3 PERSONAL_TOOLBAR_FOLDER="true">/<H3>1/' \ | sed 's/<H3 UNFILED_BOOKMARKS_FOLDER="true">/<H3>1/' \ | sed 's/<H3>/"/' \ | sed 's/<\/H3>/"/' \ | sed 's/<A HREF=/,/' \ | sed 's/">/","/' \ | sed 's/<\/A>/"/' \ | sed 's/ / /g' >output.txt- Hand-edit output.txt to copy "groupname" to beginning of each bookmark's line.
Format of each data line: "groupname", "url", "title"
Remove any stray junk, blank lines, bookmarks that are JavaScript bookmarklets.
Can't have any leading spaces on lines. - Quit KeePassXC and save a backup copy of the KeePass database file.
- Launch KeePassXC and open your normal database.
Select Database / Import / CSV file.
Choose the output.txt file.
It will say creating a new DATABASE.
Select a temporary name and password (you will delete this database later).
Get to an "Import CSV Fields" dialog.
Set the pull-downs to match the CSV file: 1st column is Group,
2nd column is URL, 3rd column is Title, other columns are "not present in CSV file".
Do the import.
See the new database.
Tweak any group names.
Maybe move them all under a single new top-level group called "Bookmarks" or something.
Save the database.
Quit out of KeePassXC. - Launch KeePassXC again.
Open your normal database.
Select Database / "Merge from database".
Select the new temporary database.
Enter the password for that database.
Groups get merged into your normal database. - Make sure the data is there in KeePassXC, tweak names, test.
- Delete the new temporary database file.
- Delete the bookmarks out of Firefox.
Abhishek Prakash's "Soon You'll be Able to Convert Any Website into Desktop Application in Linux Mint"
Martins Okoi's "Web App Manager - Convert Any Website into an App"
Where are they stored ? How do you back them up, or copy to a fresh install ?
Hardware 2FA: must use same key to open database and to save database. Can't switch in middle of session.
Almost Secure's "Documenting KeePass KDBX4 file format"
Site verifying itself to the user
To prevent phishing, a site should identify itself to the user. But very few sites do this today, maybe because it complicates login a little.
I have one bank that does this:
- Site prompts for username, user gives it, site verifies it.
- Site displays an image associated with the account (stored on server).
- User looks at the image and verifies it's valid for this account.
- Site prompts for password, user gives user gives it, site verifies it.
- Site and user do 2FA.
A phrase could be used instead of an image.
If usernames are public or easy to guess, the display-image step could be moved to be after the password is verified. If it's a phishing attempt, the user has given away the password, but would be saved by 2FA. And if the user realizes no valid image has been displayed, the user knows they just got phished, time to change the password.
The current equivalent is that the user has to check the domain shown in the address bar, and verify that it is the correct domain. But that can be easy to skip, or hard to do or confusing, or can be faked in a few ways.
TOTP (Time-based One-Time Password)
[In this section I include codes sent to you through email or SMS or voice call, as well as codes you generate yourself from an app such as Google Authenticator or a hardware token.]
These kinds of codes almost always are used as a second factor, not a primary/sole password.
Scams still are possible
Note that any system that requires the user to type in a code still is vulnerable to phishing or scamming. A keylogger could record the code as it is typed in, or the user could be typing it in to a bogus web page, or the user may be fooled into reciting the code to a "tech support" scammer on the phone. Time-based two-factor is less vulnerable, since the thief would have to use the code within 60 seconds or so. Tokens or software that connect directly (USB, NFC, etc) to the computer/phone are less vulnerable than typed codes, because a cryptographic challenge-response would be used, and the user is not in the loop (no phishing).
Note that software TOTP two-factor still is vulnerable to a breach at the server. If the company loses its database of passwords and two-factor secret starting codes, the hacker can get into your account. But software two-factor TOTP does defend against you reusing passwords across multiple sites, and against a keylogger listening to your typing (the hacker would have to use the code within 60 seconds or so), and against brute-forcing.
Terence Eden's "That's not how 2FA works"
SMS is evil ?
Some people say SMS is horribly insecure and never should be used. Some corrections to this:
- SMS can be subverted, via fooling the phone service provider into
porting the phone number (SIM-swapping) or otherwise redirecting the messages (e.g.
Sakari).
- There is a difference between using SMS for 2FA
and using SMS for
account recovery or password reset.
When used in 2FA, attacker has to have password as well as subverting the SMS.
For account recovery or password reset, maybe attacker only needs to subvert the SMS.
- Using SMS for 2FA is better than having no 2FA at all, even if it's possible (not easy)
to subvert the SMS.
- Using SMS as the sole means of
account recovery or password reset
is a bad idea. Better to use security questions and (made-up) answers, or recovery codes,
or some other mechanism.
Need US phone number while living outside USA
I'm a US citizen residing in Spain. Some US sites support only US phone numbers, either for registration or voice call or SMS.
There are many services that will give a temporary phone number for receiving an SMS message. But I need a permanent number.
Google Voice only gives numbers if you're in US and already have a US phone number, I think. And is not free. Someone said "you can buy already-verified Google Voice accounts online. You'll need to use a VPN showing your location in the US though." But I don't know if that's a good idea.
See Virtual phone numbers section of my Computer Security and Privacy page
Hardware Tokens
These kinds of devices could be used as the sole means of identification (replacing username and password), or as a second factor.
From PrivSec's "Multi-factor Authentication":
U2F and FIDO2 refer to the Client to Authenticator Protocol, which is the protocol between the security key and the computer, such as a laptop or phone. It complements WebAuthn, which is the component used to authenticate with the website (the "Relying Party") you're trying to log in on.
FIDO, FIDO2, U2F
Neil Jenkins' "How U2F security keys work"
FISO Alliance's "Specifications Overview"
[From people on reddit:]
FIDO (the group) or U2F (one of their specs) is the same thing. After typing your password, you touch your security key as 2FA.
FIDO2 is passwordless. You type the PIN or show your fingerprint to the FIDO2 security key and touch it to directly unlock access. The 2 factors are the PIN on the device or fingerprint and the device itself. It requires more recent dongles.
My understanding: U2F requires use of a server. So you can't use it in situations where you don't have a network connection, or don't have one yet.
"CTAP1 is a new name for FIDO U2F." CTAP == "Client to Authenticator Protocol".
Richard Ma's "Deprecation from U2F API to WebAuthn"
WebAuthn
From ekr's "A look at password security, Part IV: WebAuthn":
WebAuthn provides a JavaScript API that a site can use to do public key authentication via the browser.
...
[Public key is stored on the server; private key may be stored on user's disk, in browser, in hardware token] ... each server gets its own public key so WebAuthn is harder to use for cross-site tracking ...
...
... WebAuthn can be used as a second factor in addition to a password or as a primary authenticator without a password.
...
... because WebAuthn requires user interaction prior to authentication it is much harder to use for tracking.
...
[Public key is stored on the server; private key may be stored on user's disk, in browser, in hardware token] ... each server gets its own public key so WebAuthn is harder to use for cross-site tracking ...
...
... WebAuthn can be used as a second factor in addition to a password or as a primary authenticator without a password.
...
... because WebAuthn requires user interaction prior to authentication it is much harder to use for tracking.
From Richard Ma's "Deprecation from U2F API to WebAuthn":
WebAuthn is an API that allows web services to seamlessly integrate strong authentication into applications.
With WebAuthn, web services can offer the user a choice of authenticators, such as security keys (Yubikeys, Titan Keys, for example) or built-in platform authenticators (biometric readers).
With WebAuthn, web services can offer the user a choice of authenticators, such as security keys (Yubikeys, Titan Keys, for example) or built-in platform authenticators (biometric readers).
My understanding: WebAuthn requires use of a server. So you can't use it in situations where you don't have a network connection, or don't have one yet.
PassageNick's "How Does WebAuthn Work?"
Wikipedia's "WebAuthn"
MDN's "Web Authentication API" (JavaScript in web page)
Passkey
Enter a PIN into your device, it unlocks a keyring full of prvate keys, which then can be used via WebAuthn to log in to servers.
From Yubico's "What is a passkey?":
... passkeys aren't a new thing. It's just a new name starting to be used for
WebAuthn/FIDO2 credentials that enable fully passwordless experiences.
These types of credentials are also called discoverable credentials, or sometimes resident credentials.
...
Passkeys refer only to WebAuthn/FIDO credentials, and not to the many other keys and protocols, such as PIV, OTP, or OpenPGP Card, available in the YubiKey 5 Series.
...
Passkey is a term that the industry is rallying around for FIDO credentials that can fully replace, rather than only augment, passwords. ...
...
Passkeys refer only to WebAuthn/FIDO credentials, and not to the many other keys and protocols, such as PIV, OTP, or OpenPGP Card, available in the YubiKey 5 Series.
...
Passkey is a term that the industry is rallying around for FIDO credentials that can fully replace, rather than only augment, passwords. ...
From someone on Lobste.rs thread 5/2023:
FWIW, PassKeys is essentially just a profile of WebAuthn - the requests and responses
are essentially the same, you can reuse essentially all of the code for both.
PassKeys is just how Apple and Google decided to market their phones being able
to act as WebAuthn authenticators.
My attempt to ELI5 passkeys 9/2023:
A pair of keys are generated on your machine. They are like large passwords. One is private, and is used by you (your machine)
to encrypt data you send out, and decrypt data that comes in. The other key is public, and is used
by someone else (some other machine) to encrypt data to send to you, or decrypt data that comes from you.
The keys are established any time after you log in, or the first time you connect to a remote machine. That session could have your login authenticated some other way, or it's just "create a new account".
Passkeys use some mechanism, usually on your phone, to allow access to the keys. The mechanism could be biometric (face scan, fingerprint) or a PIN or just possession of the unlocked phone.
The keys are established any time after you log in, or the first time you connect to a remote machine. That session could have your login authenticated some other way, or it's just "create a new account".
Passkeys use some mechanism, usually on your phone, to allow access to the keys. The mechanism could be biometric (face scan, fingerprint) or a PIN or just possession of the unlocked phone.
In some sense, a 256-bit private key is equivalent to a 32-char password (32 chars * 8 bits/char) where all values of each char are possible, But people generally pick from a smaller subset of char values for passwords, maybe about 70 values of each char. So really a 256-bit key might be equivalent to say a 117-char password (32 == 117 * 70/256).
MojoAuth's "What is Passkey?"
MojoAuth's "Passkeys: FIDO's new mission to completely remove passwords"
Neal Fennimore's "Passkeys: What the Heck and Why?"
Dan Goodin's "Google passkeys are a no-brainer"
Dan Goodin's "Passkeys may not be for you, but they are safe and easy"
Jonah Aragon's "Passkeys: Good or Bad?"
Simon's "I am concerned about Passkeys"
Passkeys.io
Passkeys.directory (what sites support passkeys)
OAuth
From Wikipedia's "OAuth":
OAuth is an authorization protocol, rather than an authentication protocol.
Using OAuth on its own as an authentication method may be referred to as pseudo-authentication.
From people on Super User:
> How is OAuth more secure than userid/password authentication ?
[In context of Google requiring OAuth for login to email account.]
The technical benefits are:
[In context of Google requiring OAuth for login to email account.]
The technical benefits are:
- As the "initial authentication" part of OAuth is done through a website, it can more easily
ask for other authentication factors than just a password. For example, it could ask for a
TOTP one-time code or an U2F key. (It could also have reCAPTCHA if needed.)
- Generally this also means that the password you're entering is only visible to the
web browser - it is never actually seen by the mail app.
- Using a website also allows the UI to be more consistent with actual web-based services
and somewhat simpler to implement in apps than inventing a new custom multi-step authentication method.
- The token issued to your mail client only has access to specific services (scopes),
in this case IMAP and SMTP - for example, it cannot be used to access your Drive files or your YouTube history.
- Generally this also means that the password you're entering is only visible to the
web browser - it is never actually seen by the mail app.
- The actual service never receives your actual password (nor even the refresh
token - only the short-lived access token), so even if one service is compromised,
it cannot collect credentials for accessing other services ("lateral movement"?).
- It reduces the chance of password re-use. The more places you type in a password the
higher the chance of a critical leak and if you reuse passwords then other sites are at risk too.
- It provides a central authority capable of quickly revoking access to a large number
of sites in one go. Since sites are only given an "access token" by Google they can all
be unique and revoked individually or all at once.
- It removes the need for sites to handle password changes and to securely store passwords.
If they never receive a password then they can't store it insecurely.
They should still handle the token securely, but it's a simpler process in the case of a breach. Inform OAuth provider of breach, and they revoke your token until you get a new one next time the user authenticates.
Koen Buyens' "OAuth 2.0 Security Cheat Sheet"
SoByte's "OAuth 2.0 Authorization Authentication Explained"
Daniel Lindau's "The OAuth Flows You Need for Modern Security"
Virag Mody's "How OIDC Authentication Works"
SQRL (proposed):
"It improves on protocols such as OAuth and OpenID by not requiring a third party to broker the transaction, and by not giving a server any secrets to protect, such as username and password."
Wikipedia's "SQRL"
Smart card
[WORK IN PROGRESS, PROBABLY MUCH WRONG]
Hardware device that connects to computer via USB or NFC or something, and talks crypto to the client (HMAC-SHA1 challenge/response) ? Passwordless authentication. User may have to touch a button on the device, and/or type a PIN into the device or into the system.
Microsoft's "Smart Card Architecture"
Mozilla Wiki's "Thunderbird:OpenPGP:Smartcards"
Red Hat's "Smart Card support in RHEL8+"
Ubuntu's "CommonAccessCard"
PAM-PKCS11 User Manual (2005)
Wikipedia's "CCID (protocol)"
Sectigo's "Self Signed Certificate: What It Is & How to Create"
Yubico's "About the YubiKey and smart card capabilities"
Hugo Barrera's "Using a Yubikey for both GPG and TOTP"
man pcscd
man pcsc-tools
pcsc_scan
sudo systemctl status pcscd --full --lines 1000
opensc-tool -- list-readers
man card_eventmgr
man pam-pkcs11
# add pam_pkcs11.so to cat /etc/pam.d/login ?
p11tool --list-tokens
p11-kit list-modules
sudo gpg --card-status
sudo gpg --edit-card
man scdaemon
Hardware device possible features
- One or more of USB, NFC, Bluetooth.
- Do crypto interaction with computer/phone.
- User has to type a PIN into the computer/phone, or type a PIN on a keypad on the key, or just tap a single button on the key.
- Contains a password manager, and appears as a keyboard to the computer to type usernames and passwords.
- Can do OATH TOTP (time-based ?).
- Can do HOTP (counter-based).
- Supports SSH authentication.
- Supports OpenPGP.
- Provides general-purpose encrypted storage (USB drive).
Andrew Lytvynov's "What I Wish I Knew About U2F and Other Hardware MFA Protocols"
Wikpedia's "HMAC-based one-time password" (HOTP)
OneLogin's "What's the Difference Between OTP, TOTP and HOTP?"
Hardware devices
- YubiKey
Very large, confusing product line.
Costs $40 or $50 per key.
Models:- YubiKey 4 Family: newest, multiple form factors to choose from, all support U2F, OTP, Smart Card, PGP, etc,
all support up to a 4096 bit key length, no NFC.
- YubiKey NEO: only keychain form factor, all support U2F, OTP, Smart Card, PGP, etc, only up to a 2048 bit key length, support NFC.
Yubico NEO-n: no longer sold.
- Yubico Security Key: only keychain form factor, only supports U2F, but cheapest YubiKey.
Yubico's "Compare Products"
Naomi Brockwell video
[From /u/SoCleanSoFresh on reddit.]
My questions:[I'm a Windows 10 Home user, a normal home PC user.]
- How do I recover from a lost YubiKey ?
Easiest way is to have a second YubiKey. But it has to be registered to all the same accounts and logins as the first key. No way to just clone a YubiKey, or declare two YubiKeys to always have equal credentials.
If you don't have a second YubiKey, you'll have to exercise whatever "account recovery" options there are for all of your accounts, one at a time. There are no "emergency codes" or "recovery codes" you can save and use to generate a new YubiKey that is equal to the lost one, or bypass the requirement to have your YubiKey. But many accounts will use your email and/or phone as primary means of recovery, and if those are locked by the lost YubiKey, you're stuck. - Can a YubiKey be required for my PC's system/BIOS login ?
But this wouldn't really protect my information on disk, if that disk is unencrypted. A thief could just take out the disk and attach it to another PC to get access to the data.
Answer seems to be no, unless you install some custom boot-loader. - A YubiKey can be required for my Windows 10 user login, in addition to the password.
But this wouldn't really protect my information on disk, if that disk is unencrypted. A thief could just take out the disk and attach it to another PC to get access to the data.
Would the Yubikey protect upon login when waking up from sleep or hibernation, or only upon initial user login ? - Can a YubiKey be required for my Android phone's system login ?
I have a Samsung Galaxy S4 I9505 (does have NFC) running LineageOS 14.
- Can a YubiKey be required to mount a hardware-encrypted WD Passport Ultra external hard disk onto my computer ?
Answer seems to be no. - Can a YubiKey be required to mount a software-encrypted container
(using VeraCrypt or LUKS or Bitlocker, for example) onto my computer ?
Answer seems to be yes for LUKS: "man systemd-cryptenroll".
Windows:Apparently there are two ways to use YubiKey with Windows login:
- If you use YubiKey for Windows Hello app, the YubiKey enables login
without entering the Windows user password:
article2.
Does not operate with system/BIOS login, only Windows user login.
Works with a local Windows account or a cloud account.
Uses CCID mode on the YubiKey.
- If you use YubiKey with Yubico's Windows Logon app, the user must have both the password
and the YubiKey to login:
article3.
Does not operate with system/BIOS login, only Windows user login ?
Works with a local Windows account only.
Uses challenge-response using HMAC-SHA1 mode on the YubiKey.
Willi Mutschler's "Security steps with Yubikey" (Linux)
Cal Bryant's "How to get the best out of your Yubikey with GPG" (mostly Linux-only)
drduh's "Guide to using YubiKey as a SmartCard for GPG and SSH" (mostly Linux-only)
Hugo Barrera's "Using a Yubikey for GPG"
Vivek Gite's "How to install YubiKey Manager GUI on Linux"
Veres and Wellbrock's "How to use a YubiKey with Fedora Linux"
kmille's "How to Yubikey: a configuration cheatsheet"
- YubiKey 4 Family: newest, multiple form factors to choose from, all support U2F, OTP, Smart Card, PGP, etc,
all support up to a 4096 bit key length, no NFC.
- Feitian.
Chinese company.
- Solo (formerly U2F Zero)
solokeys / solo1
Kim Schulz's "Using SoloKey for Linux Login"
Kim Schulz's "Password-less linux login with SoloKeys"
/r/Solokeys
Open-source. And can buy a developer version "Solo Hacker".
No button or keypad on the key; have to type a PIN into the computer/phone when you use the key. [But now there are multiple models, some support tap ?]
- OnlyKey
Open-source.
Does FIDO/U2F 2FA, is a password manager (24 accounts), and does TOTP.
Can do encrypted backup of its internal password manager database.
Self-destruct feature.
- Nitrokey
Nitrokey Start is open-source; Nitrokey Pro is not fully open-source.
USB-only.
Does FIDO/U2F 2FA, is a password manager (16 accounts), and does TOTP.
Provides general-purpose encrypted storage.
- Thetis
USB-only.
- Google Titan
USB/NFC/Bluetooth.
U2F only.
article1, article2, article3
It seems U2F is the newest, best protocol, but not supported everywhere quite yet.
Nick Parlante's "The Unofficial FIDO U2F FAQ"
USB is needed for PCs; NFC is needed for phones.
Kim Schulz's "Security keys - everyone should have at least one!"
Question about a hardware device: can you get N clones of the same device, or is each device unique ? Having N clones would be more convenient: register once on each account, and then all N keys work for that account, and one key could be kept in deep storage (safe-deposit box) to guard against catastrophe. But maybe a "clone" capability represents a vulnerability, or prevents audit trail. With unique devices, you'd have to register all N of them with each account, and I think you'd have to retrieve a key from deep storage to register it on a new account.
[I'm told: clones are explicitly outlawed in the U2F standard, and there is a counter in each key that can be used to detect duplicates, and maybe invalidate the key. So not possible. But then I'm told there may be a dodge around this: Dmitry Frank's "Reliable, Secure and Universal Backup for U2F Token" ]
Also: Emil Lundberg's "Yubico proposes WebAuthn protocol extension to simplify backup security keys"
Mid-2020 apparently KeePass does not yet support using U2F FIDO to unlock password database.
Ctrl.blog's "The trouble with decommissioning a used FIDO security key"
From Hugo Barrera's "How I secure my setup with a YubiKey" and comments on reddit:
- Use for 2FA on supported web sites.
- I use a YubiKey to generate my SSH keys. ... This generates a key on the YubiKey device itself.
The key itself cannot be extracted, but also requires the on-disk file to be used.
This means that if someone snatches my YubiKey, they still can't use my SSH key.
And if someone extracts the file from disk, they still need the YubiKey.
- I've set up sudo to use my YubiKey ... The "Confirm user presence" prompt
indicates that one should press the YubiKey's button.
- Logging into the system or unlocking the disk with a hardware key alone is a
terrible idea ... [because hardware key is likely to be next to system, and a thief can steal both]
- Configuring a screen locker to use a YubiKey is also a kinda bad idea ... [same reason as previous item]
- Password manager: prefer to use a passphrase ... [no reason given]
Dmitry Frank's "Reliable, Secure and Universal Backup for U2F Token"
I've been thinking about whether I want to use a hardware device for accounts that support it (which is very few of my accounts), and coming out to "no". I'd have to have 2 or 3, in case I lost one; I'd have to register all 2/3 of them to each account; any time I wanted to register them to a new account I'd have to get the 3rd key out of deep storage; if I lost one while traveling the backup would be back home; and a laptop thief probably would get hardware key along with laptop.
I'd rather have some software mechanism, some kind of key-based challenge-response, that I can do via password manager. With maybe software TOTP in some cases (BIOS login, disk decryption, OS login, if those ever support it).
Two-Factor Authentication (2FA)
Some sites offer two-factor authentication: you can't log in unless you possess both knowledge (username and password) and a particular device (phone or dongle or token).
[Some additional pieces that really are just more types of knowledge: secret code to generate a TOTP, code-card, signature, security questions/answers, knowledge-based answers (KBA), recovery codes.]
[Some additional factors that could be used to make multi-factor authentication: what you are (biometrics), where you are (location), what you can do (whistle a tune or write a signature ?), what time it is, some confirming authority (another person or account who is authenticated already, or a cookie from previous login). In fact, I wonder why no sysadmin-type services support location as a factor: let me set my account to "allow login only from IP addresses 23.n.n.n/8" ?]
Forms of 2FA
[Some of this may be wrong; not sure about FIDO, U2F, and HOTP.]
[Mostly from most-secure to least-secure:]
- Hardware device that connects to computer via USB or NFC or something, and talks
crypto through client to a server (U2F, or FIDO2-WebAuthn-CTAP2).
- Hardware device that connects to computer via USB or NFC or something, and talks
crypto to the client (HMAC-SHA1 challenge/response). Smart card ?
- Software app on protected device (such as smartphone) that uses Bluetooth to connect
to computer, and talks crypto through client to a server (FIDO2-WebAuthn-CTAP2).
Dan Goodin's "How Apple, Google, and Microsoft will kill passwords and phishing in one stroke"
- Software app that uses network as a back-channel to communicate between devices.
WebAuthn-enabled, such as Windows Hello, Apple's Face ID/Touch ID, and Chrome WebAuthn ?
Camera-and-QR-code such as desktop WhatsApp login ?
- Hardware device that gives you a time-limited number (OATH TOTP) or counter-based number
(HOTP) to type in.
- Software app that gives you a time-limited number (OATH TOTP) to type in.
- Site uses custom app on your phone to send you a time-limited code to type in.
- Site uses email or WhatsApp to send you a time-limited code to type in or a link to click on.
Dmitry Frank's "Treating Email More Like a Password Manager" - Site uses SMS or voice call to your phone to send you a
time-limited code to type in or a link to click on.
- "Remember this device" via browser cookie.
- No 2FA: just username and password to type in.
- No 2FA: just username and password to type in, and username is your email address.
All of the OATH TOTP apps are compatible: Google Authenticator, andOTP, Authy, Authenticator Plus, more. I switched from Google Authenticator to andOTP because andOTP is open-source and not-Google, and Google Authenticator is specific to the phone (number) it is installed on. Also andOTP has a password protecting the app. Still I don't put sitenames and usernames and passwords into the app, so if someone gets the database they don't have enough info to find the accounts.
Some systems call themselves two-factor but really are just two-step, they don't require that you have a device such as a phone. They just send a code to your email or ask you more questions or something.
What sites support what kinds of 2FA ?
2FA Directory
Fido2, Webauthn and U2F Supported Sites
Chris Siebenmann's "What I understand about two-factor/multi-factor authentication (in 2023)"
Naomi Brockwell video
Daniel Miessler's "Not All MFA is Equal, and the Differences Matter a Lot"
The more I think about it, I'd just like to have software TOTP 2FA for everything (even BIOS login, disk decryption, OS login, web sites, etc). More secure than just a password, but can have the TOTP app on multiple devices, no hardware device to lose or phone that might stop working. Maybe key-based challenge-response for web sites, but again software-based.
A response I made to a "passwordless" system proposal:
I like passwords. They're standard strings, cross-platform, easy to back up. Unlike a hardware device, they're free, and you can make N backup copies. They don't depend on having phone service or internet access or access to a server; I can store them in a local-only password manager. No central server can see all the places I log in to.
Use a password manager and create good passwords. And set the password manager to paste creds only into the proper domain, to resist phishing.
No, I think passwordless and hardware tokens and SMS are bad ideas. Give me passwords and software TOTP 2FA.
Anticipate problems
With two-factor, check ahead of time to see what happens if:
- Your phone loses service (no SMS, no voice calls).
- You lose your device.
- You lose your device while traveling, and the backup device is at home.
- The device is stolen.
- The device dies or is destroyed.
- The device battery runs out.
- You have to change your phone number.
- You have to reinstall the security application (which may change the security ID).
- You want to log in through some other computer (if using the no-phone option).
- The security app vendor (such as Google) disables your account.
- The security app vendor goes out of business.
Eric Ravenscraft's "What Happens If I Use Two-Factor Authentication and Lose My Phone?"
Jack Stuart's "How my personal security backfired on me"
(Found these instructions for VeriSign VIP Access: "You need to save the VIP.tok from \Application Data\VIPAccess. You also need to save the registry keys HKLM\Comm\Security\Crypto\UserKeys\Microsoft Enhanced Cryptographic Provider v1.0\VipAccessKeyContainer and HKCU\Software\VIPAccess".)
None of the phone-number-specific solutions seem to work for cases where multiple people would be sharing the same account, or where you switch around a lot and carry only one of your multiple devices (phone, tablet, laptop) at a time. If you use a computer (non-phone) app, how would that work with multiple computers (home desktop, work desktop, laptop) ?
Convenience vs Security, limited by Choice
Choice: Many sites only support SMS 2FA, or use a custom code-card, or have some custom 2FA app. And U2F is not widely supported as of 1/2020, I think. So you can't just pick one strategy and use it everywhere. Which is a pain.
Convenience: I use good passwords and software TOTP, and save the TOTP secret and recovery codes. But I store all of that stuff in one password manager database. That's very convenient: find one entry in the database, hit one key-combination to open URL, another key-combination to apply username and password, another key-combination to apply TOTP, and I'm in. But it's not very secure; if someone cracks that database or I leave it open, they get everything. It's not really two-factor. Tradeoffs:
I do everything (creds, TOTP, recovery codes, etc) inside KeePassXC.
It's not a "something you own" second-factor, but still it's better than no-2FA:
- It adds a time-based component to the login info going over the wire.
- I hope sites are storing the TOTP secrets separately from the password hashes (that would be best practice, wouldn't it ?).
- Might reduce the harm of someone shoulder-surfing as I use my password manager.
- Makes phishing harder (phisher has to write more code, account for more cases).
- Slows down login a bit, making me less likely to get phished (I have time to think twice).
- Makes the site less likely to fire off fraud triggers due to me using a VPN and Firefox and Linux and script-blockers etc.
Security: Would be best to:
- Store acctname/URL/username/password in one password manager database (the EVERYDAY database),
- Store OATH TOTP secrets in a hardware token that can generate OATH TOTP codes, and
- Store all of that info plus recovery codes and security questions etc in a second password manager database (the MASTER database) that is kept very secure and closed and offline.
What I want is a password manager that can:
- Store everything (MASTER database), with standardized columns/formats for TOTP secret codes, security questions and answers,
recovery codes, maybe hardware token IDs or something.
- One-button operation to export all of the entry names
(e.g. "Joe's PayPal acct") and associated TOTP secrets to a hardware token.
- One-button operation to strip out columns or export a stripped (EVERYDAY) copy of the database (strip out TOTP secrets and recovery codes and security questions/answers etc).
Alternative idea from someone: instead of storing recovery codes and security questions/answers etc in a second password manager database, store them in encrypted attachment files stored inside the (only) password manager database.
Lucian Constantin's "5 things you should know about two-factor authentication"
Stuart Schechter's "Before You Turn On Two-Factor Authentication ..."
Wes Siler's "Traveling With Two-Factor: How To Access Your Accounts Abroad"
Emily Price's "Always Carry Your Google Account's Two-Step Verification Codes With You"
Article saying that using 2FA is much more effective than complex passwords or avoiding password re-use:
Malwarebytes' "Why (almost) everything we told you about passwords was wrong"
Vivek Gite's "Use oathtool Linux command line for 2 step verification"
Important places to use two-factor authentication
- Email accounts.
- Domain/DNS account (especially if email goes through DNS MX record).
- Financial accounts: bank, credit card, PayPal, money-transfer, crypto-currency, Privacy.com, etc.
- Any item-purchasing accounts that are auto-connected to your bank account or credit card: Amazon or other retail, gaming, phone apps with in-app purchasing.
- Cloud accounts (Apple, Google, Microsoft) that could be used to remote-disable or remote-wipe your devices.
- Any account you'd really hate to lose, such as a social media account where you've built up a huge following, or a domain-registar account, or web-site-hosting account, or source-control account.
- Password manager (mainly, if cloud).
Downsides of two-factor authentication
- Maybe login doesn't work if you don't have cell service.
- If you lose your authentication device or it dies or it runs out of battery charge, now you can't access email etc through your computer too. Unless and until you have some emergency method, and it's close to hand.
- If you take your laptop somewhere, you have to take your 2FA device or phone with you too.
- Some carriers charge for SMS messages.
- Login is slower.
- Some forms of 2FA damage your privacy/anonymity, by tying account to a phone number.
- There may be a charge for the authentication device or service.
- If the authentication device plugs into a USB port, some places (internet cafe, library, etc) may not allow that.
Choosing not to use 2FA
- Don't care about the account; fast login more important than security.
- Only form of 2FA supported would damage your privacy/anonymity, by tying account to a phone number.
- Only form of 2FA supported requires something you don't have, such as phone or token.
- Need to have multiple people access one account, and the supported form of 2FA doesn't support that.
My experience with Symantec VIP hardware token starting 2/2018
Got it for free from my main bank. Push a button, it generates a 6-digit number, which changes every 30 seconds or whatever. This is called a Time-based One Time Password (TOTP).
For my bank, activated it online by logging in, going to a Security page, and then giving serial number of token and current 6-digit number. Then when logging in, just add the current 6-digit number to the end of the password. If I lose the security token, I can call the bank and answer lots of questions, and they'll deactivate it for login.
The Symantec web site says one of the sites that uses "Symantec VIP" is PayPal, but the PayPal site seems to say only SMS is supported, not the hardware token. Same thing with EBay USA, Symantec claims support but then token is not supported by the site.
Fidelity funds does support this token, but the Fidelity retirement unit where I have an account does not support it.
My credit union does not support two-factor of any kind.
None of my three email providers support this device; 2 of 3 support no hardware devices at all. Facebook and reddit don't support this kind of device. Transferwise doesn't support hardware devices. IDrive doesn't really do two-factor. VeraCrypt doesn't do two-factor.
Maybe login to the KeePass password manager can be set to use TOTP, via "OtpKeyProv" extension ? But I don't want to do this. If I lost the security token, I'd have no way to recover, other than having previously saved a copy of the database that did not require the security token.
/u/Rafficer's "How to set up automatic login with 2FA and Two-Password mode with KeePass 2"
(Using Linux) to make a software-TOTP equivalent of a Symantec VIP hardware-TOTP token
Chef-Koch's "How To use TOTP with your PayPal account".
The "This credential expires on this date" feature is worth noting.
Couldn't get it to install properly, using "sudo pip install .". Then did "sudo apt install docker.io" and that seemed to work. Did "docker run --rm kayvan/vipaccess provision -p -t VSST", and got "Command 'docker' not found". Dev said do "pip install setuptools". Got further, to some error about "oauth bdist_wheels". Did "pip install wheel".
From home directory, did ".local/bin/vipaccess provision -p -t VSMT". Worked ! Copied "otpauth://totp/VIP%20Access:VSMTXXXXXXX?digits=6&secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXX&period=30&algorithm=SHA1&issuer=Symantec". Put info (including expiration date) into my Keepass password manager, went to PayPal and activated TOTP using Symantec VIP 30-second, logged out of PayPal and back in using TOTP, worked !
Patrick Lucas Austin's "How to Boost Your Game Console's Security"
Password Reset
Password reset is not the same as Login using 2FA, although they may use the same or similar mechanism (SMS, email, TOTP, voice call).
It might be hard to figure out the password reset algorithm used by some provider. They might use whatever email address or phone number you have associated with the account, even if you didn't expect that, and that data was not listed as "for reset purposes".
Having SMS or phone number as your form of password reset is dangerous: if someone steals your phone, they could initiate a password reset and take control of your account. If you have TOTP 2FA enabled on your account, doing password reset might require use of the 2FA, preventing the stolen-SIM attack. Also, your SIM should have a PIN set on it, so a thief can't move it to another phone.
After your phone is stolen, the thieves might send a phishing email to you, appearing to be from your phone company and saying "good news, we found your phone, login here to get it back". Don't give any login information; the thieves will use it to steal your account.
Password bypass:
Alex Pastel article about PayPal
But someone on reddit: "To be clear, it has to be enabled on a per-merchant basis, but once it is, it's just as bad as claimed. All you need is an email address and an SMS code and you can proceed with the purchase. All your 2FA and password settings are ignored. ... To my knowledge, this login can only be used during a purchase, not to access the main account."
Account Recovery
Account recovery is not the same as Password reset or Login using 2FA, although all three of those may use some of the same or similar mechanisms (SMS, email, TOTP, voice call).
The best forms of account recovery use unique codes generated for only that purpose. No one but you should have those codes. But of course you have to be smart enough to generate and record them before you need them.
It might be hard to figure out the account recovery algorithm used by some provider. They might use whatever email address or phone number you have associated with the account, even if you didn't expect that, and that data was not listed as "for recovery purposes".
Having SMS or phone number as your form of account recovery is dangerous: if someone steals your phone, they could initiate an account recovery and take control of your account. If you have TOTP 2FA enabled on your account, doing account recovery might require use of the 2FA, preventing the stolen-SIM attack. Also, your SIM should have a PIN set on it, so a thief can't move it to another phone.
Apparently, for Google accounts, the recovery codes would let you log in, but not let you remove SMS 2FA from the account. So if you have lost your phone, you'd better get another with same phone number, soon.
Using an email alias or catch-all address on an account is a little dangerous, because you probably can't originate a message from that address, so Support or account-recovery may be hindered. For example, suppose your registered email address for eBay is "myname+ebay@gmail.com". You may not be able to originate a new email from "myname+ebay@gmail.com", only from "myname@gmail.com". This may get rejected by eBay, for Support or account-recovery purposes, since it doesn't match the address on your account.
This won't be a problem if account-recovery only involves receiving a link in email, and clicking on the link.
After your phone is stolen, the thieves might send a phishing email to you, appearing to be from your phone company and saying "good news, we found your phone, login here to get it back". Don't give any login information; the thieves will use it to steal your account.
Linked Applications
This is a situation where you are authenticated to an account such as Google, and a related application asks for permission to access your Google information. It will use your existing session token.
If you say yes, it gains access that is not revoked by changing your credentials or enabling 2FA. You will have to find a special "linked applications" administration page and remove the app from there.
See section "4. OAuth Consent phishing" of Zsofia Zsakai's "How Attackers Bypass 2FA"
Miscellaneous
Scams
If you are getting suspicious SMS messages from sites:
Don't click on anything in the messages.
Possible that the messages are not from the site they say they're from. Hard to tell. Assuming that the message is from the real site:
- If you have an account at the site involved, and the SMS is for password-reset,
it means someone has your username (maybe email address) or phone number, that's all.
Those essentially are public information.
- If you have an account using two-factor authentication at the site involved,
and the SMS is to confirm account login (asking for the second factor),
it means someone has your username or phone number AND PASSWORD, that's bad.
Go to the site or app (not through the message) and change your password.
- If you don't have an account at the site involved, it means someone has
your username (maybe email address) or phone number, and is trying to create
an account using them. Not much you can do. Blocking the number the SMS comes
from may block other sites too.
Multiple types of "Passwordless" login
- Use already-authenticated account to authenticate for new account.
E.g. send link to email.
- User sees biometric, but behind the scenes a password is being sent.
E.g. Apple's Face/Touch ID gating a stored password.
- Locally authenticate (with PIN or biometric) to a smartcard or token,
which then uses crypto keys to authenticate to the service.
E.g. smartcard-based authentication or FIDO2-based authentication.
Already-authenticated "Passwordless" login
Site A uses your email account E as a method of authentication. So you have no password for your account on site A. It just knows your email address.
You go to site A and enter your email address. It says "we'll send you an email containing a link; click on the link to log in". You go to your email account E, get the email, click on the link. Either your existing page on site A says "okay, logged in", or the link causes a new page to open on site A that says "okay, logged in".
Advantages: No need for a password on site A, so fewer passwords and 2FA methods. Email accounts usually offer good security such as 2FA, so pretty secure.
Disadvantages: Slower login (email transit time), with more clicks. If someone gets into your email account, they get access to every other site that uses it for login. Internet and email service are points of failure.
The point of going password-less isn't to create better software and hardware security;
everyone gets this wrong. Password-less is meant to fix human-security.
People forget passwords and write them down, people reuse same password everywhere,
people share passwords when policy says they should not, law enforcement can try
and scare the password out of someone because they know it.
Password-less is meant to reduce the human insecurity of knowing and dealing with passwords.
Password-less is meant to reduce the human insecurity of knowing and dealing with passwords.
Secure Boot (as used in Linux)
Ubuntu's "SecureBoot"
Igor Bogdanov's "Security features of the Intel/Windows platform secure boot process"
From Adam Williamson's "UEFI boot: how does that actually work, then?":
"the firmware contains a set of signatures, and refuses to run any EFI executable which is not signed with one of those signatures."
"dmesg -T | grep Secure" to see if it is enabled.
"sbctl status"
"sbctl list-files" to see what files are signed.
"sbctl list-bundles"
If Secure Boot is enabled, verify authenticity of the EFI binaries by signatures. Uses certificates and hashes, blacklist database (DBX) and whitelist database (DB) and Key Exchange Key(s) (KEK) and Platform Key (PK), Machine Owner Key (MOK) and MOK Blacklist (MOKX), Secure Boot Standard Mode-ready bootloader SHIM. Signatures generally are provided by Microsoft.
For Linux, there is a shim binary ("shim-signed"; signed by Microsoft; contains a cert from Canonical; "apt list | grep -E '^shim[^m]'" and "efibootmgr -v") and a GRUB binary (e.g. "grub-efi-amd64-signed" or "grub-efi-arm64-signed"; signed by Canonical) to get through this process.
Secure Boot has various modes including full, fast, minimal, custom. Various paths if checks fail.
Secure Boot can not be turned off on ARM-architecture machines ?
If available, TPM operates as a passive observer (creating audit trail) of all phases.
From Pid Eins's "Brave New Trusted Boot World":
Boot chain is typically:
Firmware - shim - grub - Linux kernel - initrd (dracut or similar) - root file system.
Firmware's UEFI SecureBoot protects shim, shim's key management protects grub and kernel. No code-signing protects initrd. initrd acquires the key for encrypted root fs from the user (or TPM/FIDO2/PKCS11).
shim/grub/kernel is measured into TPM PCR 4, among other stuff.
From someone on reddit 8/2021:
... Ubuntu, Fedora, Debian, openSUSE all come with signed shim out of the box, so you don't have to do anything (except for Arch, but there is Fedora's shim in AUR). IIRC Canonical and Red Hat also provide root CA to enroll in UEFI so you don't have to sign every kernel update. For Arch (and for other distros if you want to use your own keys) you have to add your signing keys to UEFI then signing everything with it for every kernel update or setup hooks for it. You need to check this for distro you want to use.
From someone on reddit:
Secure Boot does not need a TPM.
Secure Boot will ensure that your bootloader is signed by a key in your firmware (often Microsoft's key, but you're free to use your own if you want), and then the bootloader will ensure your kernel is signed by a key it knows about (usually your Linux distribution's own key). Often the initramfs isn't verified at all ...
But Secure Boot isn't sufficient to protect against all attacks. An Evil Maid could have replaced your firmware with other firmware that pretends to do Secure Boot, but doesn't, and thus is able to boot anything that Evil Maid might want to boot.
Measured Boot is different. It is actually orthogonal to Secure Boot. It feeds into the TPM a series of "measurements" of each software component used during boot. The TPM processes these measurements and comes up with a result. This result will only be the "correct" result - namely, the one that it got on the previous boot - if exactly the same sequence of measurements are fed into it.
Since one of the very first measurements is that of the system firmware itself, if the firmware is changed the result will be different. Put simply, this can actually detect an Evil Maid attack.
But just detecting the attack isn't sufficient. You as the owner of your system needs to know about it. This is why tying the TPM's result into your LUKS decryption (article) is an interesting idea: it means your storage can only be decrypted if your hardware has not been tampered with.
From a StackExchange thread:
"Note that TPM measurements are mostly independent from UEFI 'Secure Boot'. The Secure Bohttps://old.reddit.com/r/explainlikeimfive/comments/14r96q4/eli5_so_whyhow_exactly_do_we_feel_cool_when/ot state and configuration is measured into PCR 7, but that's about the extent of their interaction."
Active Directory, LDAP, FreeIPA, Zentyal.
Steve Syfuhs' "Understanding Windows Authentication"
Affinidi's "Self-Sovereign Identity"
Self-destruct:
Michael Altfield's "LUKS Header Shredder (BusKill Self-Destruct Trigger)"