Is it really necessary to portray an initiative to wipe out dangerous snakes as self-interested and imperialist?
Obviously it's self-interested for the species as a whole...
The “Cobra Effect” that is disabling paste on password fields
91–100 of 450 posts
Re: The “Cobra Effect” that is disabling paste on password fields
#92Earlier quoted context omitted.
I know of some of those sites that randomise the location of keys and then hide the key labels on mousedown, I assume to try and avert that issue. (Curious as to whether it would actually work though.)
A hacker can get around that by also taking a screenshot when there is no mousedown event, it's literally one extra line of code.
Or just take screenshots periodically each second and then submit with a mouse click the one before the click.
Re: The “Cobra Effect” that is disabling paste on password fields
#93Earlier quoted context omitted.
HSBC has this really odd system where they only ask for the (e.g.) 1st, 6th, and 7th characters of your password. That implies that they store plaintext or something reversible...
They could be extracting the 1st, 6th and 7th characters, concat them and storing the hash (+salt) of the resulting string. That way they can check equality without storing the plaintext password. You could extend this by storing the hash of all 3-letter combinations of the password on entry. Then ask for a random combination of 3-letters.
You realize that this is trivial to brute force, though.
Re: The “Cobra Effect” that is disabling paste on password fields
#94I encountered this once. "xdotool type password". If they're checking for a delay, xdotool can introduce that for you (defaults to 12ms though).
That said, we should never have let websites have this kind of control over the user agent. For the one time disabling right click was helpful (context menus in Google Docs), 99% of the time it's something dumb ("don't steal our images!").
Finally, I loved the comment about losing their security certificate. I'm sure the average CA will give you a cert for google.com if you ask nicely enough.
Re: The “Cobra Effect” that is disabling paste on password fields
#95Earlier quoted context omitted.
No amount of salting is going to make a 3-character recognizer secure.
The 1, 6, 7 is random
The problem is, if you have a bunch of partial passwords 1, 2, 3; 1, 2, 4; ... you can just brute force three character combinations of the passwords, which just takes something half a second (times the number of rounds) if you write your password cracker in bash. So your complexity goes from 52^n for a n character password consisting of lower and upper case to n/3* 52^3 which is a lot more manageable.
Re: The “Cobra Effect” that is disabling paste on password fields
#96I always assumed this anti-pasting was a requirement of some braindead auditor who insisted that this was a necessary security mechanism. If they aren't, there's a lot of "debt" in the passwords space, like Troy mentions. This is just something that will get better as websites get better. Webapps are much more complicated today than 5 years ago, on average, and as complexity increases things like user auth will get b…
I had a quick look through PCIDSS which is the usual source of this kind of nonsense, but couldn't see anything. However when the first site in the posting talked about losing their "security certificate" they were almost certainly talking about PCI or some related standard.
Re: The “Cobra Effect” that is disabling paste on password fields
#97Earlier quoted context omitted.
They could be extracting the 1st, 6th and 7th characters, concat them and storing the hash (+salt) of the resulting string. That way they can check equality without storing the plaintext password. You could extend this by storing the hash of all 3-letter combinations of the password on entry. Then ask for a random combination of 3-letters.
You realize that this is trivial to brute force, though.
Not when they'd presumably lock the account for some period of time after a few failed attempts.
Re: The “Cobra Effect” that is disabling paste on password fields
#98Earlier quoted context omitted.
They could be extracting the 1st, 6th and 7th characters, concat them and storing the hash (+salt) of the resulting string. That way they can check equality without storing the plaintext password. You could extend this by storing the hash of all 3-letter combinations of the password on entry. Then ask for a random combination of 3-letters.
You realize that this is trivial to brute force, though.
I never said it was a good way of storing passwords. It reduces entropy. I'm just saying there is way to both have hashed password storage as well as "asking for 3 random letters of you password at login".
Re: The “Cobra Effect” that is disabling paste on password fields
#99Earlier quoted context omitted.
Why though? A .txt file on the desktop is actually probably a lot more secure than using the same shitty password on every site.
A friend may get tempted to sneak a peek.
That's pretty tough with FDE, proper permissions on the text file, an ephemeral guest account for the times someone wants to use your computer, and religiously locking the screen when AFK.
Re: The “Cobra Effect” that is disabling paste on password fields
#100I believe that copy and paste is needed in login forms, as a UX expectation. Typing a secure random password is really painfully hard, especially on mobile.
Sometimes password managers don't recognize the target form fields correctly, so copy/paste is the next step. The act is even encouraged through the use of convenient helper buttons in the password managers.
However. In MacOs Sierra, Apple will introduce the Universal Clipboard feature. This means when someone copies a password on desktop, it would be available on their phone. Which is just one step away from being pasted, by mistake, into an IM chat or worse.
I'm uncomfortable with the idea that when I copy something it's being sent around to different devices, and available to everything running.
I've actually made the terrible mistake of doing that - pasting a password into a group chat my accident, because I didn't copy text correctly, and my last paste buffer was still around. Or messing up when using pbcopy/pbpaste in a shell script.
1Password for instance can actually reset the copy/paste buffer after some time, but the settings need to be enabled. I wonder if Apple has any kind of security around this planned. Maybe applications and scripts should not be able to access the paste buffer until the user explicitly allows it (via the act of using it)?