181–190 of 320 posts
I just use lines of poetry for my passwords. They're long enough, complex enough, but extremely easy for humans to memorize.
I have a manually maintained database with a bash one-liner for password generation; primarily I rely on my browser's password manager.
This is my password manager. password = b64encode(hashlib.pbkdf2_hmac( 'sha256', (master_password + '/' + domain).encode(), b'', 100000 + n )).decode()[0:16] + 'Aa$1' master_password = some master password that you never write or store anywhere domain = domain name for the service in question, e.g. 'facebook.com' n = the nth password being generated for the domain (typically 0) The 'Aa$1' is to ensure satisfaction of…
`pass` is a nice command line tool that stores gpg2 encrypted password files. It's simple, super handy and doesn't require you to trust any third party with what you're storing. website: https://www.passwordstore.org/ man page: https://git.zx2c4.com/password-store/about/
My main reason to not use pass is that I can't allow multiple private keys to unlock the password store. I don't want to transfer my private key between all my machines.
In your .gpg-id file, simply list the keys you want to encrypt for on separate lines. Every file below that .gpg-id file in the directory hierarchy will be encrypted for any of those keys to unlock.
This is my password manager. password = b64encode(hashlib.pbkdf2_hmac( 'sha256', (master_password + '/' + domain).encode(), b'', 100000 + n )).decode()[0:16] + 'Aa$1' master_password = some master password that you never write or store anywhere domain = domain name for the service in question, e.g. 'facebook.com' n = the nth password being generated for the domain (typically 0) The 'Aa$1' is to ensure satisfaction of…
I also keep a list of the "domains" along with plaintext comments for each of them (username, email I used, etc) that are not strictly required (so still portable) but just make it a little more useful when it's synced.
The big downside I've found is lack of apps. Sure it would run on any phone, but I haven't managed to get it to run on the phones conveniently. So if I'm without a laptop right now for the most part I'm locked out.
[1] https://github.com/passwordly/passwordly-python/blob/master/...
Subscription to 1Password is not mandatory. Or at least it was not in the past. Without a subscription, you can create local vaults which can be synced via Dropbox, iCloud or over WiFi within the same subnet (which means over VPN too). Here is some documentation on the Dropbox sync for example: https://support.1password.com/sync-with-dropbox/
The subscription isn't really mandatory, but I've been quite disappointed at the transparency with which they've been pushing people towards that...even those of us that purchased the full version somewhat recently. For instance, the complete lack of a Windows version that isn't subscription based is a huge pain since I got a cheap Kodi box recently and my keyboard is a remote control that sucks for typing passwords.…
And shameless plug for my own cross-platform powershell-based 1Password client, which can read both formats of local vaults: https://github.com/latkin/1poshword
This is my password manager. password = b64encode(hashlib.pbkdf2_hmac( 'sha256', (master_password + '/' + domain).encode(), b'', 100000 + n )).decode()[0:16] + 'Aa$1' master_password = some master password that you never write or store anywhere domain = domain name for the service in question, e.g. 'facebook.com' n = the nth password being generated for the domain (typically 0) The 'Aa$1' is to ensure satisfaction of…
This is a long blog post that talks about some drawbacks of this approach: https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw... Before reading this I was convinced that stateless deterministic approaches like these was the ideal. But some arguments in that post changed my mind.
This is my password manager. password = b64encode(hashlib.pbkdf2_hmac( 'sha256', (master_password + '/' + domain).encode(), b'', 100000 + n )).decode()[0:16] + 'Aa$1' master_password = some master password that you never write or store anywhere domain = domain name for the service in question, e.g. 'facebook.com' n = the nth password being generated for the domain (typically 0) The 'Aa$1' is to ensure satisfaction of…
This is a long blog post that talks about some drawbacks of this approach: https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw... Before reading this I was convinced that stateless deterministic approaches like these was the ideal. But some arguments in that post changed my mind.
16 characters + 'Aa$1' has universally satisfied every website I have used to date except Baidu (which imposes a maximum of 16 characters total on passwords). The number of exceptions to this is probably miniscule.
> Deterministic password generators cannot handle revocation of exposed passwords without keeping state
That's what 'n' is for. Either you can keep 'n' as a state variable which is much easier to manage (and if you lose the file, you can try a few values of n and get yourself back into those websites without much hassle), OR sync the values of n every several months on the sites that use it.
> Deterministic password managers can’t store existing secrets
This is orthogonal to the password problem. I store sensitive files that aren't passwords in a GPG-encrypted tarball on Dropbox.
> Exposure of the master password alone exposes all of your site passwords
This is true of stateful password managers as well, if you backup your database on anywhere insecure or any device (e.g. laptop) that could potentially be mugged at gunpoint, confiscated by border control, leaked by buggy software, etc.
Earlier quoted context omitted.
I used to do something very similar to this, for around 5 years. It works fairly well, but I've moved away from it largely because: There are always exceptions that won't work (you can't have one scheme that both satisfies "you must have one special character" and "you cannot have any special characters"), and it also doesn't let you change your password for a site. I was able to come up with something that worked in…
That's what the incrementing variable is for. Of course, you have to then remember how many times you've changed your password for any given site.
"You must use one of these special characters: %^&*()"
Earlier quoted context omitted.
My main reason to not use pass is that I can't allow multiple private keys to unlock the password store. I don't want to transfer my private key between all my machines.
You absolutely can do this. In your .gpg-id file, simply list the keys you want to encrypt for on separate lines. Every file below that .gpg-id file in the directory hierarchy will be encrypted for any of those keys to unlock.
If you want more granular key strategy, look at gopass [1], which is a pass-compatible binary that gives a little more granular control over key usage (IIRC), and is written in Go.