4 ms·

NIST have an interesting history around security. One such example would be AES. They favored Rijndael over Serpent, despite Serpent clearly winning on techni

NIST have an interesting history around security. One such example would be AES. They favored Rijndael over Serpent, despite Serpent clearly winning on technical merit. Also, Rijndael is the one cipher that intel have offloaded on their chips and even called it AES-NI vs. offloading several ciphers. I agree with some comments here that size matters. It is trivial to put a series of characters in between 2 to {n} words you can easily remember. ____This____Is____Number____42!____ and I would remember it is 4 _'s around each word because there are 4 words/numbers. More sensitive content should equate to more words; and therefore, more of the buffer characters. You can even use this to defeat keyloggers. Open up a prompt that you can type in, then type a bunch of a character. Then use your mouse to select the number of characters that represents your buffer character length, or a portion of it. Then copy-paste as required. Keyloggers will capture cntr-v but they won't capture how many characters you selected. For those concerned about password managers and keyloggers, don't put your actual password in them. Leave off something, somewhere in your password. Maybe the start of your pw actually contains buffer characters that you know to type or paste. A majority of folks won't be bothered to do any of this. I am just sayin', it's super easy once you train yourself.

gruez 9y ago
Why even bother with these weird rules? just use a password manager, generate a secure (> 128bit entrop) password, and be done with it. Also, keepass has something like your keylogger foiling method, called "2 channel obfuscation".
- LinuxBender 9y ago
  Use whatever option you are comfortable with. I know people that can't bother to use more than 1 password everywhere and certainly can't use more than 6 characters.
alister 9y ago
> For those concerned about password managers: Leave off something, somewhere in your password. I like the idea. So what you suggest is to manually type, say, "7&>>", before or after every password entered by the password manager? Or to copy-paste the "7&>>" from somewhere. A password manager is essential for good security (and I use one) but I'm concerned that it can be devastating point of failure. It can be worse for highly-organized people who keep absolutely everything in there. It's a single, up-to-date database in a nice standardized format with known filenames and clearly labeled data that lends itself to automated malware that can seek it out when your password manager is open/mounted/decrypted. As you said, a majority of folks won't be bothered, but a good extra step for someone highly security conscious.
- dsacco 9y ago
  If malware has compromised your device, there is nothing you can meaningfully do to improve the security that is already offered by a password manager. This scenario is right up there with physical access to the machine - you're already screwed. To comment on this specific example - if you add the same set of characters to every item in a password manager, an attacker can deduce that it's a common obfuscation method.
pwg 9y ago
> You can even use this to defeat keyloggers. If you have a keylogger, your first order of business should be to clean out the keylogger. The very presence of a keylogger makes the machine insecure for entry of any passwords, no matter how you do the entry. > Keyloggers will capture cntr-v but they won't capture how many characters you selected. Why would you think a keylogger could not recognize the ctrl-v and then ask for the contents of the clipboard itself so it can log what was pasted?
- LinuxBender 9y ago
  I've never run across one that does, but that is certainly a risk too.
tptacek 9y ago
This is a weird comment. First and most importantly, you have the chronology backwards --- obviously, Intel implemented AES-NI after NIST chose AES. If NIST had chosen Serpent, AES-NI would implement Serpent. That's the point of encryption standards. Second, Serpent had a higher security margin, but was slower, and more complicated; among other issues, Serpent has a higher hardware footprint. None of the AES finalists have been meaningfully weakened since AES was selected. There are obviously sketchy NIST crypto standards, and at least one very bad one. AES isn't either of those kinds of things.
- LinuxBender 9y ago
  > First and most importantly, you have the chronology backwards No, you and I are saying the same thing. Perhaps I worded it poorly? My point is they are fixating on a specific cipher they believe everyone should and will use. As it turns out, most are because Intel backed their choice and gave people incentive to utilize it.
  - tptacek 9y ago
    Again, that would be the point of an encryption standard.
    - LinuxBender 9y ago
      If fixating on a specific cipher is considered to be a standard, then let's deprecate it. I believe that was done in error. The standard should be around how each cipher is implemented in a secure manor, not limiting options to one cipher. By diversifying options, brute force attempts get exponentially more expensive. It would be easy enough to list in CPU capabilities which instructions are supported.
      - tptacek 9y ago
        None of this makes sense, sorry.
dsacco 9y ago
> NIST have an interesting history around security. One such example would be AES. They favored Rijndael over Serpent, despite Serpent clearly winning on technical merit. Rijndael won because cryptography is first and foremost a discipline that makes tradeoffs between usability and security. A security measure is not helpful if no one uses it, either because it's a pain in the ass to configure or because it increases your own costs to implement and use. Serpent is technically more secure because it uses 32 rounds of encryption (among other things) while Rijndael uses 10, 12 or 14 (depending on key size). But they're both substitution-permutation networks, and Rijndael is secure enough while offering a significant speed increase. There hasn't been a meaningful cryptanalysis on Rijndael since it was published. > You can even use this to defeat keyloggers. Open up a prompt that you can type in, then type a bunch of a character. Then use your mouse to select the number of characters that represents your buffer character length, or a portion of it. Then copy-paste as required. Keyloggers will capture cntr-v but they won't capture how many characters you selected. I don't really follow. If a keylogger has compromised your machine, you're already approaching worst-case scenario territory. More importantly, of course a keylogger can capture how many characters you select. Even if they didn't, they can just capture exactly what's in the browser form field before it's sent in the login request.
skrebbel 9y ago
Do you actually believe that keylogger programmers have never heard of GetClipboardData()?

gruez 9y ago

Why even bother with these weird rules? just use a password manager, generate a secure (> 128bit entrop) password, and be done with it. Also, keepass has something like your keylogger foiling method, called "2 channel obfuscation".

LinuxBender 9y ago
Use whatever option you are comfortable with. I know people that can't bother to use more than 1 password everywhere and certainly can't use more than 6 characters.

alister 9y ago

> For those concerned about password managers: Leave off something, somewhere in your password. I like the idea. So what you suggest is to manually type, say, "7&>>", before or after every password entered by the password manager? Or to copy-paste the "7&>>" from somewhere. A password manager is essential for good security (and I use one) but I'm concerned that it can be devastating point of failure. It can be worse for highly-organized people who keep absolutely everything in there. It's a single, up-to-date database in a nice standardized format with known filenames and clearly labeled data that lends itself to automated malware that can seek it out when your password manager is open/mounted/decrypted. As you said, a majority of folks won't be bothered, but a good extra step for someone highly security conscious.

dsacco 9y ago
If malware has compromised your device, there is nothing you can meaningfully do to improve the security that is already offered by a password manager. This scenario is right up there with physical access to the machine - you're already screwed. To comment on this specific example - if you add the same set of characters to every item in a password manager, an attacker can deduce that it's a common obfuscation method.

pwg 9y ago

> You can even use this to defeat keyloggers. If you have a keylogger, your first order of business should be to clean out the keylogger. The very presence of a keylogger makes the machine insecure for entry of any passwords, no matter how you do the entry. > Keyloggers will capture cntr-v but they won't capture how many characters you selected. Why would you think a keylogger could not recognize the ctrl-v and then ask for the contents of the clipboard itself so it can log what was pasted?

LinuxBender 9y ago
I've never run across one that does, but that is certainly a risk too.

tptacek 9y ago

This is a weird comment. First and most importantly, you have the chronology backwards --- obviously, Intel implemented AES-NI after NIST chose AES. If NIST had chosen Serpent, AES-NI would implement Serpent. That's the point of encryption standards. Second, Serpent had a higher security margin, but was slower, and more complicated; among other issues, Serpent has a higher hardware footprint. None of the AES finalists have been meaningfully weakened since AES was selected. There are obviously sketchy NIST crypto standards, and at least one very bad one. AES isn't either of those kinds of things.

LinuxBender 9y ago
> First and most importantly, you have the chronology backwards No, you and I are saying the same thing. Perhaps I worded it poorly? My point is they are fixating on a specific cipher they believe everyone should and will use. As it turns out, most are because Intel backed their choice and gave people incentive to utilize it.
- tptacek 9y ago
  Again, that would be the point of an encryption standard.
  - LinuxBender 9y ago
    If fixating on a specific cipher is considered to be a standard, then let's deprecate it. I believe that was done in error. The standard should be around how each cipher is implemented in a secure manor, not limiting options to one cipher. By diversifying options, brute force attempts get exponentially more expensive. It would be easy enough to list in CPU capabilities which instructions are supported.
    - tptacek 9y ago
      None of this makes sense, sorry.

dsacco 9y ago

> NIST have an interesting history around security. One such example would be AES. They favored Rijndael over Serpent, despite Serpent clearly winning on technical merit. Rijndael won because cryptography is first and foremost a discipline that makes tradeoffs between usability and security. A security measure is not helpful if no one uses it, either because it's a pain in the ass to configure or because it increases your own costs to implement and use. Serpent is technically more secure because it uses 32 rounds of encryption (among other things) while Rijndael uses 10, 12 or 14 (depending on key size). But they're both substitution-permutation networks, and Rijndael is secure enough while offering a significant speed increase. There hasn't been a meaningful cryptanalysis on Rijndael since it was published. > You can even use this to defeat keyloggers. Open up a prompt that you can type in, then type a bunch of a character. Then use your mouse to select the number of characters that represents your buffer character length, or a portion of it. Then copy-paste as required. Keyloggers will capture cntr-v but they won't capture how many characters you selected. I don't really follow. If a keylogger has compromised your machine, you're already approaching worst-case scenario territory. More importantly, of course a keylogger can capture how many characters you select. Even if they didn't, they can just capture exactly what's in the browser form field before it's sent in the login request.

skrebbel 9y ago

Do you actually believe that keylogger programmers have never heard of GetClipboardData()?