|
OriginalGriff wrote: Randall seems to be getting later and later, wonder what is keeping him busy.
Probably those Scrabble games...
It was broke, so I fixed it.
|
|
|
|
|
I was signing up to a website yesterday only to find that they had disabled pasting into the password and confirm password fields.
Not only that, but having completed the painful process of registering (they had also disabled auto-complete) I found that they also don't allow pasting into the username/password boxes at login time.
Personally I fail to see how any of this achieves anything beyond:
1) Making their website a complete pain in the bottom.
2) Encouraging people to use short and memorable passwords - which is surely not a good idea on a site that handles money.
Is there something that I'm missing here or is it simply a case of a dev team making some really, really bad UX decisions?
|
|
|
|
|
I encountered that a couple of months ago on a major bank website. The irony was that the PW set fields allowed it, so I dumped a random KeePass-generated PW in and then had to manually enter that bastard when I wanted to log in. Fortunately I figured out pretty fast that Chrome would override that with ctrl-v.
I can only think that some fool assumes that hackers would use their web interface to attempt to brute-force accounts rather than something they would actually do, like edited packet replays.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Psht! Would you please leave those code monkeys in their belief that a little JavaScript on some controls can aktually keep us from doing something!
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Nathan Minier wrote: I can only think that some fool assumes that hackers would use their web interface to attempt to brute-force accounts
I was recently on a gov't web site (related to student loans) which also blocked the paste field.
It is so annoying and actually shows that the person who created the thing doesn't understand how password hacks are done.
So, again, these sites actually punish you for having a more complex (and longer) password which is very difficult to type. 
|
|
|
|
|
There is no point to have a Confirm password box if you can copy and paste the main password box... as an error in the first one would be duplicated in the second one.
The purpose of the Confirm box is to ensure that you are able to write the same thing twice which is really a good thing as if you are not able to do that when you register, then how hard would it be to type the password when you login the next time?
Philippe Mori
|
|
|
|
|
|
Well, at least it should not be possible to copy or cut a password...
Only pasting them might be a good compromise for those who trust passwords managers...
That way, you have the main advantage of making harder to users to manually copy one field to another while filling the form (those preventing mistyping to be permanent) while allowing pasting from other sources...
Philippe Mori
|
|
|
|
|
Consider also, typing your password on your phone or device. It's quite terrible to have to do it if yo have a long / complex password. I believe apps and sites should allow paste always. Doing otherwise encourages users to use easy-to-type passwords which are most likely weak. 
|
|
|
|
|
Your logic (and in fact the whole way you go about thinking about these things) is flawed. The purpose of a confirmation box is to help assure that the user's action matches their intent. For users who enter passwords manually (which is the vast majority), the confirmation box achieves its purpose, regardless of whether paste is enabled. For users who enter via copy/paste, the confirmation box serves little purpose, but disabling paste increases user error for no good reason. The only thing that actually makes sense is to disable copying of the password box, so that any pasting would have to come from some other source, as a password manager.
You have two basic errors here: 1) instead of analyzing cases for whether confirmation boxes are useful when paste is allowed, you identify a case in which it isn't and then wildly generalize, saying that they aren't helpful at all. 2) Rather than considering what the purpose of a confirmation box is, you only attend to its effect -- forcing people to type something twice -- and note that allowing paste potentially removes that effect ... quite overlooking the fact that, for passwords copied from another source such as a password manager, the confirmation box isn't necessary for its intended purpose (and disabling paste even acts against that purpose).
modified 25-Oct-16 19:36pm.
|
|
|
|
|
Well, say that you find a password.txt file on someone else computer and it has about 10 passwords in it... It is not hard to imagine that some peoples might be tempted to try to copy and paste those passwords in some site...
Thus, there are way that improve security for computer power users that are not real hacker or not even programmers...
Philippe Mori
|
|
|
|
|
If you find my passwords file, you won't be able to decrypt it even if you know the password.
You would also need the RSA key which is stored on my server away from the keepass database.
Good luck!
|
|
|
|
|
That does nothing, as said user could simply type those passwords. When you base the linchpin of your AAA mechanism on user carelessness, you are coding to fail.
This approach benefits no one, especially those of us who care enough about protecting credentials to use password management systems.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Philippe Mori wrote: say that you find a password.txt file on someone else computer and it has about 10 passwords in it... It is not hard to imagine that some peoples might be tempted to try to copy and paste those passwords in some site...
Or they may even type them in.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
|
PeejayAdams wrote: Is there something that I'm missing here or is it simply a case of a dev team making some really, really bad UX decisions?
They probably wanted to avoid looking 'careless' and went overboard with being 'correct'.
Requiring the password to be entered and repeated manually can avoid (a little) trouble by making certain that the user was actually able to type the the password twice without error. Also, as I only rarely register at some sites at all, it might be the perfect method to mske me think again about registering.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
It was probably not the idea of someone on the Dev team; more likely the requirement came from the Pointy Haired Boss. 
|
|
|
|
|
Probably just bad UX decision.
It is apparent some people consider it good security.
Perhaps even the management/design team/customer that ordered that web site thought it so and insisted to be so.
Or maybe it was just the work of an intern new developer...
|
|
|
|
|
Make sure you complain to them and tell them the reason you just stated here. It's pure ignorance. You have to combat ignorance or it will continue to spread.
I have to tell this story:
I had an account that was worse than that. Apparently, their site only accepted passwords of 8 characters or less, but THEY DIDN'T TELL YOU! There was no indication on their site whatsoever.
So I would change my password (my default was 16 chars), go to login in 5 seconds later, and it said "password invalid". This is not possible because I was pasting my password from Keepass that I JUST SET!
Every single time I logged on I would have to call their tech support to reset my password. And every time I reset it, I was locked out again. Their own tech support people couldn't even figure it out. I finally figured it out myself because I noticed after the tenth time that every time I was emailed a temporary password it was exactly 8 characters. I tried dumbing down my password to 8 chars and low and behold it worked!
Their application was only recording the first 8 characters of what you put in the web form. Then you paste in the exact same password next time and it would fail if it was longer than 8.
I told them about the bug and you what their response was?
[crickets]
So I closed my account.
Dumb-asses. If they won't listen to reason, then just walk away. Maybe eventually they will get the message.
|
|
|
|
|
Your story is a great one -- albeit painful for you as a user -- since you expose the ineptitude of those developers and that site.
It exposes what a lot of companies do with passwords that is so terribly wrong.
Through my work with writing a password generator (SHA256 based hashed and strong that the user never has to remember -- see my articles here at CP) I've noticed that many companies require a password to be quite short though everyone knows the longer it is the better.
I had an issue with Yahoo! while attempting to change my password to my strong SHA256 based password hash and it was related to length too. Now 50 million of their accounts have been hacked. Sheesh.
The Companies which Allow Extremely Long Passwords
Here's an example of my passwords (not a real one, of course)
53859190d943a005823a58af8d717755bf63fbf8fb0eb99733595ae70aa3b2d7
Facebook, LinkedIn, Google, Microsoft
AppleId only allows max of 32 chars for password - those simpletons.
|
|
|
|
|
This is what one of my typical passwords look like:
Quote: W6/\E\4d8ewUhDO`;*&O
I'm not going to use weak passwords.
I'm not going to remember or type my passwords.
I never use the same password on multiple sites or services.
The only option left is to not use their site or service.
By the way, if you don't already have it, get Keepass. It rocks.
|
|
|
|
|
Absolutely! Agree 100% 
|
|
|
|
|
I also faced a problem with a site which limited passwords to 8 characters, but pasting my original longer password didn't fail, it probably truncated that one too to 8 characters before doing the comparison.
I faced a problem when I had to change my password and the first 8 characters were the same but the ending was different, it was returning me an error saying that my new password had to be different than the old one.
|
|
|
|
|
If you are good with Greasemonkey, you can override their stupid "no paste" javascript and make the page work correctly again.
Greasemonkey is a great tool for this.
|
|
|
|
|
It's a side effect of what they are doing with the keyboard handler which is removing any ability to hook it.
A lot of the common keyloggers AdvancedKeyLogger, KeyGhost, Absolute Keylogger, Actual Keylogger, Actual Spy,
Family Key Logger, GHOST SPY, Haxdoor, MyDoom all use that method.
The ability to cut and paste is unfortunately a side effect of the change but in some ways is a blessing.
So basically the bank is doing something Microsoft should have done which is when you enable a secured connection
cut the feed to all windows hooks which would have been the preferred option.
You won't be able to restore the function it's way lower than anything Java can reach the paste functions will
not take input from the normal button win32 messages if implemented correctly. The hint is you would have to
register the message with the class and for that you need the security key.
What you think of as a button isn't a button at all, its a bitmap that gets draw on from deep inside the security
sections. Think of a rolling counter on a website or even look at US debt clock. The screen drawing is totally
fictional the key message never come outside the application kernel.
In vino veritas
modified 24-Oct-16 8:14am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
