4 ms·

I have a couple scripts, 'add' and 'get', which respectively add or get an entry associated with some keys to a text file. An example line in the text file loo

by natch 9y ago

I have a couple scripts, 'add' and 'get', which respectively add or get an entry associated with some keys to a text file. An example line in the text file looks like this: facebook password: [base64:U2FsdGVkX1/T8CoWmfDOoaapE5lGj/fqHE3s8NohnriGajnPrCzWikCneU/u7] Anyone thinking of trying to crack that, well good luck. I removed and twiddled a few characters from it, as if it wasn't hard enough already. Oh but here's how to decrypt if you really want to try: echo "$data" | openssl enc -d -aes-256-cbc -a -salt -pass env:MY_PASS That's not a script, it's just an excerpt. You'll have to guess the password. You should probably do something else with your time. Since the text file is encrypted, I store it on Dropbox. Then I can access this from any computer where I log into Dropbox, provided I know my main password for decryption. Later I can type 'get facebook pass' on the command line and the get script will retrieve the best matching entry, decrypt the value, and put it in my copy paste buffer ready to paste. The biggest problem with this system is sometimes when two or more entries are a close match to whatever keywords I input, it may pick the wrong match. I need to improve it to show a list to pick from in those cases, or work on better ways to remember the right keywords for each item. Also my matching heuristics could be improved. I use this in conjunction with a command line script for generating strong passwords. Most accounts have different passwords at this point and they are all strong. One problem with the script is I sometimes have to tweak the resulting password by hand to match whatever (generally dumb) rules are in place at a new site... when I say dumb, I mean for example, '!' not allowed, etc. For sharing web passwords with my phone, I just allow Safari to remember them and then trust iCloud, for better or worse. Overall this is not a pain, and pretty successful. But if someone got terminal access in my account on my computer, it would be game over... so I try not to allow that.

kqr 9y ago
Why generate symbols that are not permitted anyway? You'd lose nothing by emitting the base16 encoding of the symbol.
- notacoward 9y ago
  The problem is that there is no character-type pattern - most especially not your base16 suggestion - that will satisfy every site. Many sites require special characters. Others forbid them. It's literally impossible to satisfy both with a single non-parameterized generator, and as soon as you start adding parameters those effectively become hidden parts of the domain name. Worse, many sites don't even tell you what the requirements are on normal entry (only on change). If you can't remember what particular tweaks were necessary then it's back to the good old "forgot my password" dance - making your email password your effective password for all such sites. It's easy for app developers to be careless or "clever" about their password rules, but it's a pain for users and it's bad for security.
- natch 9y ago
  Have you even used the internet much? Some sites do require symbols. And some sites have ridiculous rules that your suggestion would also not help with. Also, restricting yourself to the 16 characters in hex encoding makes your passwords that much easier to guess.
  - kqr 9y ago
    > Also, restricting yourself to the 16 characters in hex encoding makes your passwords that much easier to guess. No. Entropy does not change by adding redundant bits.
    - natch 9y ago
      The bits are not redundant. When you have a larger alphabet, you get more possibilities for the same length of password. Sure you could also have a password that consists only of 1 and 0, but then you would have an unreasonably long password. Just as you would also have for a hex password, to a lesser degree. To carry it to an extreme you could have your password consist of just one character repeated a secret number of times, and yeah, sure, in your little theory world the amount of entropy could still be the same, but practically speaking it's a stupid idea, just like using hex characters. You really are confused about this stuff. You also seem completely unaware that many sites have password rules that require special characters that don't exist in your scheme... lol!
notacoward 9y ago
I do something similar: passwords created by a script, stored in an encrypted file that's only unwrapped when I'm fetching or storing something. It's important that the entire file is protected, requiring a password every single time. Like you, my biggest gripe is sites with special snowflake "make it hard to remember but keep it low entropy" password policies that preclude the original generated password. IMO we as a community need to start shunning such sites the same way we do for rogue SSL/TLS cert providers. As long as they exist, it's harder for even security-aware sites to move forward.

by natch 9y ago

kqr 9y ago

Why generate symbols that are not permitted anyway? You'd lose nothing by emitting the base16 encoding of the symbol.

notacoward 9y ago
The problem is that there is no character-type pattern - most especially not your base16 suggestion - that will satisfy every site. Many sites require special characters. Others forbid them. It's literally impossible to satisfy both with a single non-parameterized generator, and as soon as you start adding parameters those effectively become hidden parts of the domain name. Worse, many sites don't even tell you what the requirements are on normal entry (only on change). If you can't remember what particular tweaks were necessary then it's back to the good old "forgot my password" dance - making your email password your effective password for all such sites. It's easy for app developers to be careless or "clever" about their password rules, but it's a pain for users and it's bad for security.
natch 9y ago
Have you even used the internet much? Some sites do require symbols. And some sites have ridiculous rules that your suggestion would also not help with. Also, restricting yourself to the 16 characters in hex encoding makes your passwords that much easier to guess.
- kqr 9y ago
  > Also, restricting yourself to the 16 characters in hex encoding makes your passwords that much easier to guess. No. Entropy does not change by adding redundant bits.
  - natch 9y ago
    The bits are not redundant. When you have a larger alphabet, you get more possibilities for the same length of password. Sure you could also have a password that consists only of 1 and 0, but then you would have an unreasonably long password. Just as you would also have for a hex password, to a lesser degree. To carry it to an extreme you could have your password consist of just one character repeated a secret number of times, and yeah, sure, in your little theory world the amount of entropy could still be the same, but practically speaking it's a stupid idea, just like using hex characters. You really are confused about this stuff. You also seem completely unaware that many sites have password rules that require special characters that don't exist in your scheme... lol!

notacoward 9y ago

I do something similar: passwords created by a script, stored in an encrypted file that's only unwrapped when I'm fetching or storing something. It's important that the entire file is protected, requiring a password every single time. Like you, my biggest gripe is sites with special snowflake "make it hard to remember but keep it low entropy" password policies that preclude the original generated password. IMO we as a community need to start shunning such sites the same way we do for rogue SSL/TLS cert providers. As long as they exist, it's harder for even security-aware sites to move forward.