TradeKing went full idiot and disabled entering your password by keyboard completely. They implemented an on-screen keyboard and there's no way to opt out.
Their support forum is full of angry customers, people who can't use their screen readers anymore, etc. They argue [1] it's to protect their customers from key loggers.
> I agree, it’s a little more inconvenient than before.... but for now we’re asking you to accept a little inconvenience for the sake of greatly enhanced security.
This gives people incentive to pick the shortest possible easiest to input password. Definitely not good for "greatly enhanced security".
It seems astonishing to me to attempt to include in your threat model "login must be secure even on a system which has malware on it". If a system is infected with a keylogger, the LAST thing you want to do is allow the client to log in.
Either you employ some sort of malware detection on your login page. Modern trojans mostly inject stuff into web pages, so things like Trusteer Pinpoint will scan the DOM and report back anomalies. Based on those reports you block the user from logging in or send them to a safe sandbox so they can't do any damage to their accounts.
Alternatively, you can work with your clients' ISPs. Most malware still exhibits visible communication patterns, either by getting in touch with other bots or by contacting command-and-control servers. Once you get ISPs to notice that sort of behaviour, they can sandbox their clients and have them clean up their systems before they reach the Internet (and disclose all of their data).
Isn't this what Intel's SGX system is supposed to do? Create a trusted, isolated execution environment, that's certified by Intel (or whomever manages your PC platform) not to mess with your data in malicious ways?
IIRC can't it communicate directly to the keyboard,screen and the network?
Besides DRM, this is probably the next best killer feature for the system if it's as secure as they claim.
iSGX utilizes iME's DAL interface to access to a very limited subset of iME features that explicitly pertain to cryptography (primitives), time and calculations. iSGX is dependent on a skylake processor (due to the MEE[the hardware being iSGX] being attached/combined into the MC) and BIOS/UEFI support for iSGX.
Features such as PAVP via Intel Insider are not accessible in the current implementation (version 2) of Intel Software Guard Extensions. Access to PAVP and other powerful features of iME such as iAMT has been restricted to Intel and Intel Partners (M$, DoD) through obscurity and no available documentation. However, that being said, there are several white papers authored/co-authored by Intel employees who do make use of these immensely powerful features.
iSGX (nor any current technology that is known to the public) is capable of ensuring input CIA properties (without utilizing Intel Insider/PAVP to display a digital keyboard, transmitted via direct bus to NIC/eth.)
Other security technologies, specifically Sanctum does provide different coverage than iSGX but there is no "unified" security technology that is a one-size-fits-all solution.
iSGX's main PoF is poor security implementation by ISV's/enclave writer's. That being said it is better than TrustZone, TXT, XOM, Bastion, Aegis and Phantom in regards to the ratio of return:implementation cost.
In practice no, it's not useful for this because it has to take over everything. This makes it basically impossible to support for anything complex like a web browser. You end up having to put way too much stuff in the trusted environment. It might have worked way back in the text terminal days when it was slightly realistic for someone to build basically an entire trusted OS to run instead of your normal OS, but today that's just not going to happen.
I wouldn't. The point was more that this mitigation for password entry amounts to saying "if a client infected with malware logs in to the banking site, at least we can be sure that the malware won't be able to determine the user's password - they will only be able to steal all of the user's money".
Another one that is a great pain are the sites that insist upon asking for three letters from one's password to log in. This is all very well if one has an insecure password, but when I've created a 20-character password containing all the necessary characters then this makes it rather more difficult to enter the required values.
I actually like this as implemented by one of my banks. The 'pick a few letters' part of the login is pulled from a list of secret question answers rather than the password itself, and is presented after successfully entering the password.
So my password manager enters my password, and then on the next screen I am asked for the (for example) 4th and 5th letters of the street I grew up on. The requested letters change and the question is pulled from a saved list of question/answer pairs.
I am not aware of how the bank deals with accessibility limitations of this system.
But that doesn't solve the problem that all of that is still "Wish-It-Were-Two-Factor". Secret questions and secret answers are still passwords by a different name. (At this point I even keep them in the same password vault and am starting to pseudorandom generate them thanks to support lines treating them as passwords and giving people access to accounts based on easy to find knowledge.)
Instead of all the work banks put into chicanery around this secret question and answer security theater, they should just roll out real Two Factor and save us all some hassle.
I never used them, but my guess they try to make one time passwords from your passwords.
They probably ask to enter e.g. 3rd, 6th and 8th letter of the password. Supposedly if someone logs it it supposedly won't be as useful, because next time it will ask for different letters.
Not sure why won't they use rsa keys or similar technology. Also if it is the way I think it is, then you know that your passwords aren't hashed on their servers.
then you know that your passwords aren't hashed on their servers
This is the immediate alarm that went off in my head reading about this. I've never seen this before either and it sounds like an idea from someone who means well but doesn't understand what they are doing.
It would effectively be a dead giveaway. Exhaustively searching all combinations of three characters takes trivial time even in an excruciatingly slow hash.
Entering partial passwords prevents MITM. OP was just explaining how partials could be implemented securely by hashing each combination; he wasn't saying hashing prevented MITM.
> Also if it is the way I think it is, then you know that your passwords aren't hashed on their servers.
Only if the developers are extremely lazy. A proper implementation would precompute a series of hashes for different subsets of the password and store them in the database instead. Similar to how Facebook stores both the password and its reversed-case form as a convenience feature for people who forget to turn their CAPS LOCK off.
But how many subsets would you do? With enough of them (and particularly relative to password length) this would leak a lot about your password. For say an 8 character password, do these things ask you to enter more than 4 characters?
On my >10 character passwords (I generally don't use shorter passwords with banking sites, so I don't know how the system behaves for short passwords) they ask for ~11 characters. Of course the login box can, and often ends up, being longer than your actual password, so it doesn't visually reveal the actual character count of your password. In my case they usually end up asking for ~5-7 "real" characters.
I presume a good implementation hashes and salts each "sub-password" separately. Since it's the server that decides which subset it wants, I don't think it reduces the search space, unless the hashing/salting algorithm is vulnerable to differential cryptanalysis (which it may be, I don't know this aspect of state-of-the-art hashing functions).
It's a huge detriment to security. You can break sets of 5-7 characters at a time and combine them instead of having to break the entire password at once.
Seems like a tradeoff. What's more likely - that a bank loses its password database, or that some customers find themselves infected with keyloggers?
Also in any bank that's even remotely sane this is just one leg of a 2FA; often a kind of a "delayed" 2FA - where one factor is enough to get you mostly "read-only" access, and any important changes or wiring actual money requires one-time SMS codes.
Any bank that's remotely sane with regards to website security (probably rather few of them) doesn't do this at all and uses standard forms of 2FA. This one doesn't even protect against keyloggers, because they can combine the characters from multiple logins to get the full password (guessing the remaining ones if necessary) and because the password might be reused somewhere else, and they try this at the expense of user convenience (counting characters is annoying) and security in the event of a leak involving password hashes (if they hashed them at all).
I understand what you are saying, but I suspect that fb doesn't store multiple hashes but just recomputes the hash entered a couple of times on failure.
I agree that they probably haven't hashed the password. Any time that I complain about this sort of thing the company agent usually doesn't know what I'm talking about.
I think GP is referring to the practice of asking you to type some amount of random characters from your password. It seems to be popular with banks nowadays. The field looks like this:
[ ][X][X][ ][X][X][ ][X][ ][X][X][ ][ ][X][ ]
(you enter characters in the blanks)
The idea is supposedly to protect people from keyloggers. But the side effect is that more sophisticated passwords get excruciatingly annoying to type in.
Most of banking software in Korea is doing the same thing. I had to type my password every single time with a randomly arranged keyboard. Eventually I switched to the only bank that didn't do this.
Which why you run screaming away from these sorts of organizations.
If they are too fucking stupid to implement a password text field correctly just imagine the byzantine nightmares that their infrastructure is. All you are doing is volunteering to be part of the next major security breach.
They also have the silly "Security Image" which is supposed to alert me to a phishing site because I'm supposed to notice its absence. I'm guessing that's been effective roughly never.
I think the idea is that you enter your username and the site replies with the security image that you've chosen. If the image matches, you then enter your password.
By itself, this doesn't rule out a man-in-the-middle attack, but it might prevent an attacker from setting up bonkofamerica.com and using it capture valid username/password pairs "offline", which could be reused on the real site. Of course, this depends on people noticing (and caring) that the image is missing or incorrect, so who knows...
Set up your own site, remove any mention of the reference image, watch users continue normally. "Huh, they must have finally gotten rid of that dumb thing."
> it might prevent an attacker from setting up bonkofamerica.com and using it capture valid username/password pairs "offline", which could be reused on the real site.
Exactly so. That was a pretty frequent vector when those images became popular, so it wasn't a crazy defensive move. Even though there are ways for criminals to defeat it, proper mitm for one, those were more complicated measures that weren't as commonly used. Higher risks, development costs, trouble with scaling, or just unnecessary, for whatever reason, the static dumb credential harvesting pages that look "legit enough" were most common.
A company with limited defensive resources could approach security like a greedy algorithm. Just constantly ask, "How are most customers at institutions similar to my own getting compromised right now? How do I prevent that with as much blunt force as possible that I can deploy as soon as possible?"
That would probably get you some bizarre defensive solutions that reduce usability. But it's not an obviously crazy general strategy.
Well, major caveat: presuming you're at least doing the basics right. If you aren't bothering with hashes, then your men are already dead.
And presumably a halfway skilled attacker could proxy requests to the real site and send the user their actual image. So this only works if we assume the bad guys are lazy and the users are incredibly perceptive.
I assume this is a different HSBC to HSBC US. In the US, they make you answer a security question and either a OTP from their mobile app or randomized characters from your password (e.g. first, second, fourth and last characters).
Every bank in France does this too... and my bank (BNP) also forces me to change my (6-digits) password after 80 logins for "security reasons", which only has the effect of me choosing easy-to-remember passwords.
Malware can still be capable to take screenshot of the screen. If it would log mouse clicks I would imagine it would at least take screenshot if not a video.
Knowing when to take a screenshot, uploading and storing it, and extracting the password is a lot more work than dumping a text file and grepping for bofa.com.
The worst is websites which not only disable pasting but don't even let you type your password in. Instead you have to use their janky on-screen keyboard to fumble your way through login.
I got so fed up with TradeKing (which has horrible security practices in general) that I close my account.
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...
Yes. This is to protect against attackers obtaining your full plaintext password on your end, for example by phishing or installing keyloggers. In practice this is a much bigger security threat in the online banking world than someone doing the same by compromising the bank's systems - even if that were to happen they can easily re-verify your identity and issue you with a new password, and you really shouldn't be using the same password elsewhere.
It's a ridiculous practice and storing the passwords in plaintext is deplorable. Banks have your phone number, (which can't simply be changed online) and that is the best additional line of security.
The scrambled on-screen keyboard / n-th character request only poorly "protects" against cases where the attacker has full root access to the customer's machine (how would it protect against phishing?), and in those cases the attacker is likely already capable of making all kinds of payments, even without access to the online banking account. If security is done properly, an attacker can't make direct use of a banking account anyways: creating a new transfer recipient should require phone confirmation by default.
you know. It occurs to me that you could actually do this without storing the password in plaintext!
All you'd have to do is iterate every potential answer into a bloom filter and store that. The math gets a little hairy around the 50 character mark as you'd have 117600 operations to do to construct the bloom filter, and it gets worse if you expect more characters.
Here's how you would construct it.
For every 3 choose n of the password, insert a value of those 3 characters ("abc") + delimit (":") + the positions (1,2,4), You can't just insert the characters because the index of characters is part of the answer.
all you'd need to do is store... a ~1MB bloom filter per client. Huh, that number was bigger than I thought it would be.
Phishing is a much bigger security threat, but is a much less harmful one than having the password database stolen. It sounds like they are trying to minimize the day-to-day risks, at the expense of maximize the damage of a catastrophic event.
If the password database is stolen somehow, that probably means that the bank's online banking systems have been compromised. Having the password database stolen is likely to be the least of their worries at that point.
If someone has that level of access to your system, they can just send themselved the session cookie. Or if the cookie is tied to an IP address, they can just make requests with that cookie from the compromised machine.
If an attacker is running code on your system, you are already lost.
How does this prevent key logging attacks? You still type in those characters. And secondly, that just immediately made it a hell of a lot easier to brute force your way through the passwords!
It asks for different characters from the password each time. So it'll ask for the 1st, 4th, and 5th characters. Next time you go to login it'll ask from 2nd, 8th, 14th. So a key logger is only getting a small portion of the password each time.
Yeah I was thinking they could do that. You'd only need to record a few logins.
Re brute forcing, some like firstdirect make you type a word as well and they probably block you after 3 fails so it would be quite hard to brute force. Tddirectinvesting only ask a 7 digit account number and 3 digits from the password so you could probably brute force coms of those with a botnet though they only let you transfer money to a pre nominated bank account so it would still be hard to nick people's money.
The attacker needs to both be able to read the page and key log every keystroke and be able to associate as single letter, digit, or symbol to you password and not only that to the correct placement within the password.
This is virtually impossible to achieve by any effective means.
They ask random characters from your password in a random order if you login into your bank twice a week it most likely will a year or more until a some one can phish your entire password from you this is not scaleable.
>This is virtually impossible to achieve by any effective means.
Actually it's very simple to achieve.
First, those digits will not be randomly placed among all the things you've typed, but they'd follow some specific patterns (the most obvious one being you typing all of part --due to autocomplete-- of the bank's url).
(Of course if you can run a keylogger you can also check what website is loaded on the browser and log that information alongside the keys too, but you don't even need to go that far).
So, we established that the attacker checking the keylogger logs can trivially tell - "now they're typing their banking password".
If they also knew the correct placement that would be handy, but they can do without it too. Just knowing those N characters are from your password (in any order) really improves the possibilities they need to search.
Even if it takes a year, either they are very dedicated to you as a special (large bank account) profile target, so they can wait, or they are logging tens of thousands, via some malware, so it's still worth it to wait.
It doesn't the passwords will be rotated, and they cannot be used for anything without the token.
Such attacks rely on large scales rather than being targeted.
If you target a specific account there are much better attacks out there to do if you target specific individuals or organizations.
Yes this isn't the best method and I've had and still have a lot of objections to it (it requires the password to be stored in a reversible encryption, but that is also sadly a regulatory requirement).
But I've tested it a 10 character password using their random characters random order request method took at the least 413 (that was the lowest in my case, I didn't run a full statistical analysis on it) login requests.
This is because that asking for 1st 2nd and 3rd characters, and 2nd 1st and 3rd, and 3rd, 2nd and 1st etc. are all considered "different" authentication requests by the bank.
Your keylogger would have to be also able to read the page and know that the 1st box wants the 4th character and the 2nd box wants the 3rd and the 3rd want's the 7th.
This isn't that trivial, and this doesn't scale for an attack that can target 10,000's of users over a short time period.
You need to understand that banks constantly change their web pages, they monitor for bank related malware and some of them even use additional protection like for example randomizing the names of the input fields and even the number of the fields to make effective keylogging with full browser compromise even harder.
You also are incorrect when assuming that if i know the 1st 3 characters of a password it somehow helps me it doesn't because you do not have an authentication mechanism to brute force against there isn't some login page that takes the full password, and 3 incorrect login attempt lock your user and require you to initiate a recovery by phone or by visiting a branch.
This system overall is pretty good at preventing direct attacks against the bank's own system, it's resilient to phishing, brute forcing is not an option, and a keylogger can be active for 1-2 years without effectively getting the password.
Effective security isn't black and white, there are is a lot of grey areas that might seem asinine and many of them are but they do work when you have the proper mitigating controls.
But let's ignore all of what we've established so far and go back to your assertion you assert that this attack is effective against high value accounts / individuals.
Well that's great, because from the point of view of the bank it says hey look we've put in a control that can effectively protect 99% of our users, let's see what can we do to protect the 1%.
That's how you achieve good security, you don't pool everyone into the same group, accounts with an average balance of 5000$ do not have the same risk portfolio as accounts with an average balance of 1M$.
Differential security and risk management is how you apply effective security on very large groups, you employ shared controls that cover the basics and add mitigating controls based on the individual risk portfolios for each sub group.
They also use 2FA i believe.. but then it makes logging in a right pain the ass for customers: 1) track down your massive identity number 2) enter 2nd, 5th, 8th characters of your password 3) locate your 2FA code from the HSBC device they send.
>> "This post is intended to introduce concepts and practically demonstrate a method. The implementation provided is not a reliable/hardened solution (i.e. there are vulnerabilities because finite fields are not used) and should not be used anywhere near a production system."
HSBC doesn't do that any more for me -- they've moved to a Google Authenticator-like 2FA approach[1], but Lloyds[2] does - they have one username and password, and a "memorable phrase" which they clearly store as plaintext because ask for the xth, yth and zth character as a secondary security measure. Lloyds tech folk reading this -- please consider fixing this.
Why cant they just also hash those three letter combinations they ask you? Not nearly as secure but I see many people saying that the plaintext must be stored to achieve this, and all I am thinking is that it would require you to store multiple hashes for each user, each a portion of their password.
Still a lot easier to guess a portion of a password than a password, but it doesnt follow in my mind that it is definitely in plaintext.
Three letter hash combinations and single letter hashes would all be essentially plaintext. The security of a hashed password comes from the fact that the password comes from a field of 2^(# of bits) possible values (with more useful bits the more types of "characters" allowed). If you only have a few characters that is so easily crackable (by brute force of every letter or three letter combination) that it might as well be plaintext. It is a security failure if they can get at some of the characters in a password.
However this is a memorable phrase (not password), similar to a security question. These are not generally hashed because customer service uses them to confirm authorization to reset a password.
HSBC always used a token for online banking you can either order a secure Key or for the past year or so use a mobile authenticator.
The "password/memorable phrase" is only used as a secondary authentication measure and in order to initiate a token recovery procedure on the site.
P.S.
I still use the physical OTP token, just got a new one last month it's a Vasco Digitpass 270 supports upto 8 digit pins and it locks out automatically after IIRC 5 attempts.
I don't recommend using a phone authenticator for the sole reason that losing a phone is annoying enough on it's own you don't want to lose your bank account access too :)
I have the memorable phrase and have to use the HSBC app for my password. Now, the fun thing is that my actual HSBC password is 40 characters randomness, so pretty secure. The mobile password that is used to derive the 2FA key must not be longer than 8 characters. So essentially I traded a long and secure password for an 8 character password.
I really really dislike HSBCs online banking as a whole, the password system plus the constant “We encountered an error, please try again later” messages.
Plus the unintuitive navigation, the ridiculous over-skeuomorphism of 'past statements', and the insanely-low, seemingly non-configurable session timeout. At least you can finally use a payment reference > 10 characters, but HSBC's online banking is still stuck in the stone-age overall.
I do not agree that they store a password in plain text. You cannot say for sure. What if they hash each character and store each with its position in the db?
I don't find your other answer. But, basically if you hash one character, there is only ~ 255 possibities (a-zA-Z0-9 plus some special chars). So, a 10 characters password is only ~ 2,500 hash to compute and that's nothing. Might as well store it in plaintext, because it in fact is.
Lloyds UK has a system that I quite like, you have your credentials and then to login they ask you 3 random letters of another password that you select from 3 dropdowns. This way you have your password that is presumably secure, and you have this thing which is pretty fast to complete once you get used to it, that should help with people looking at you or keyloggers.
Barclays in the UK does 2fa if you order it, otherwise this strange bit with just parts of the password.
They also have the most complicated 2fa I've seen. You get a pocket-calculator-like device where you need to insert your card (chip and pin type), then you enter your personal code, and then you do a challenge-response thing where you enter a code generated from the website into the device, and it responds with a number you have to type into the website.
They also have this anti-paste function that was triggered by me typing too fast.
> You get a pocket-calculator-like device where you need to insert your card (chip and pin type), then you enter your personal code, and then you do a challenge-response thing where you enter a code generated from the website into the device, and it responds with a number you have to type into the website.
Such a thing is rather common in The Netherlands, though it's often not a second factor but just the way you log in to online banking. It avoids having you remember yet another password, instead you just use the same card and PIN you need "offline".
Side note: At the end of 2014 Rabobank (one of the banks with such a system) replaced those devices (which they called "random readers") with "Rabo scanners", which have a built-in camera to automatically read an image from the website instead of having you manually enter a code.
The Rabobank system when used for online shopping using the "rabo scanner" works by redirecting to their site. Then displays a color QR code that your scanner reads.
You insert card and enter PIN, then scan the QR code.
The device actually displays amount+account that you are transferring money to. Then asks you if that is correct.
If you enter "yes", it will give you a 8 digit code that you can enter in the website to confirm.
>> You get a pocket-calculator-like device
> Such a thing is rather common in The Netherlands,
These devices are very common in Germany as well but I
heard they are phased out and replaced with a solution using a mobile phone.
> have a built-in camera to automatically read an image from the website instead.
In Germany we have a variant that has five photo diodes along one edge. You hold it against a flickering pattern on your screen. This works reasonably well. In my experience it is about equally fast as typing, just a little less reliable.
That's because they are reusing a multi-purpose device. Nationwide uses the same calculator-like device to make you sign new withdrawals with your card in the machine.
You can also use it to login with Nationwide, but they also allow login with a password, which is far simpler (and you don't need to find your card to do so either)
The Co-operative Bank does this too. They absolutely store the password in plain text, because if you phone up, you have to tell the whole thing to the phone operator.
To be fair, they're right in the middle of rolling out a new banking site which I think has proper passwords. The current system is a holdover from when they only had phone banking.
That does not mean they store plaintext passwords. When you login to most any website you have to submit your whole password. It is usually hashed and the hash is compare to the stored hashed pasword
Not necessarily. It might actually store multiple versions of your password as A.....B...C (where . means some known-to-them character, basically salt), ..A....B.C., etc, basically all the combo-of-3 templates encoded as PWs. Then it asks for one of them and recreates the template before comparing.
Still crappy entropy, though. An eight char password has 56 combinations of 3 positions each, so with N character choices that's 56 * N^3 vs. N^8 the normal way. Gets much worse in comparison with longer passwords.
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.
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".
You replied to a comment saying "That implies that they store plaintext or something reversible." You posted about hashing in a way that implies that comment is wrong. But that comment is completely correct. Taking three characters and hashing it is easily reversible. And then the attacker gets to log in.
The question is not whether on a technical level something got hashed. The question is whether a hash protects the password against brute forcing. And the answer is no.
Password hashing is used to prevent the brute forcing when the attacker already has the copy of the password database, and is free from any failed attempt limits and timeouts. And in this case storing hashes of all 3-letter combos is basically useless, since all those hashes are very easy to bruteforce.
Ah ok, so you're starting from the assumption that the site has already been owned and the attacker has the hashed passwords. In which case yes, it does make it easier.
Can't it be achieved by this simple steps?
Consider ur password is y.
a) f(y, i) = a func that gets i'th character of a pass. y;
b) hash(x) is ur hashing func;
c) x0 = hash(y);
d) concat(a, b) - concatination func;
1. x1 = hash(concat(f(y,1), x0));
2. x2 = hash(concat(f(y,2)+x0));
.
.
etc
Store in DB
id position hash user_id
1 0 x0 1
2 1 x1 1
3 2 x2 1
Many banks (I work for one of them) follow reasonable best practices, allow or require strong passwords, store them safely and require sensible second security factors. Others are decades behind in security, using nonsensical security schemes like the ones morgante and mng2 described above or requiring your password to be letters and numbers only between 6 to 8 characters.
If you care about security, stick with the banks who do as well. Make sure their password guidelines are in order, go with the ones that make you use a second factor, and if you ever see any hints they're storing your password in plain text, run.
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.
You're assuming that the verification is being done by the bank itself. This is under the assumption that there has already been a security breach. The password database has been stolen, and has just been sold to the highest bidder. In that case, there is no lockout.
This one at least makes some sort of sense; it's designed to prevent keyloggers from reading your password when you type it in. You can just MiTM the connection though.
It doesn't. Today's banking malware will capture the form values on submit, either as text or as a screenshot. And it will do so, silently, every time you log in.
All this scheme does is limit an attacker to gathering three letters per login attempt. Given an eight-letter password, three logins will probably disclose most of it; or at least enough for an attacker to pass the challenge when he tries to log in.
In addition, if the attacker is actually interested in your data, he can easily inject a fake "wrong password" message after your first attempt and have you try again, gathering 6 characters per login.
> don't even let you type your password in. Instead you have to use their janky on-screen keyboard to fumble your way through login.
Wow that's just insane. I'm glad I haven't run across any services like that. I'm not sure what their line of thought it; it only inconveniences normal users. A person attempting to try multiple passwords can likely figure out how to get around that restriction without issue.
It's theoretically a defense against key loggers. Of course, if someone has compromised your machine to the point where they're tracking key strokes there's no reason to assume they can't also grab your mouse presses and websites.
This isn't even their worst security practice. What truly got me to leave was their security questions: they're presented as multiple choices. My randomly generated string stands out rather obviously next to the "typical" choices.
This is where convenience trumps security. Virgin Money used to require you to enter your password using an on-screen keyboard, except they REARRANGED THE LAYOUT EVERYTIME YOU USED IT. Thank fuck they eventually got rid of it, but it was such an abject pain in the ass, I cringed everytime I needed to log in to view my details.
I wouldn't even call it a trade-off between convenience and security, because there is no security gained. This is a trade-off between convenience and stupidity. If someone suspects that a keylogger is there, the entire computer should be assumed to be compromised. Trying to guess the capabilities of the keylogger and working around them is ludicrous.
It's a valid defense against hardware keyloggers, ignoring that you're way more likely to encounter a software keylogger.
If your account is interesting enough for criminals to break into your computer room and attach dongles to your PC (I'm imagining a Mission: Impossible style break here), congratulations: you've clearly made some good financial decisions in life :-)
Not unrealistic to assume a scenario where a disgruntled IT technician installs countless hardware key loggers throughout an open plan office. Could be easier and less noticeable than trying to circumvent the business-grade antivirus.
I doubt that the motivation for preventing paste in a "confirm password" context is to prevent workarounds to character limits.
Why does the "confirm password" field exist anyway? It exists to remove the risk of input error. They want to avoid you locking into a mistyped password and not being able to recover. To this end, it makes some sense to prevent copy/paste, as a user may simply copy their mistyped password and paste it into the confirmation field. Especially risky if the input fields are obfuscated with placeholder characters (*).
Not to argue that it's the right answer, it certainly makes more sense than a heavy-handed enforcement of character limits.
I often use copy/paste to prevent typing errors. I save the password in some keychain software, then I copy/paste the password from that software into one of the password fields, and type it myself into the other.
Yes, I am the same, but there's [at least] two different types of users here. I use a password generator + manager. I never type a password, so I never mis-type a password.
My father, on the other hand, hunts and pecks and I can't get him to use a manager despite my best protestations. Having to retype his password certainly avoids mis-types on his part, even if it encourages other bad behaviors in the process.
This raises the interesting question of why we obscure the input when changing passwords. Showing the new password would allow people to check and correct it, so you'd only need one input.
Given that the contents of a password input can easily be revealed, the only security obscuring the input provides is from an attacker who can see the screen but not the keyboard, and has no physical access to the device - a pretty limited threat pool.
I guess the answer is that users expect passwords to be hidden. So we make their lives more difficult purely to keep them happy.
IE/Edge have at least one thing good about them : you can click on a little eye icon to the right of the obfuscated field to reveal the text in the field until you release the mouse button.
Showing the password can be nice in situations but I doubt I would catch most typos but re-reading my password. My eyes often see what my brain expects to see.
>Why does the "confirm password" field exist anyway? It exists to remove the risk of input error. They want to avoid you locking into a mistyped password and not being able to recover.
It seems silly to force everybody to doubly enter their password, when I'd guess at most ~10% of people might enter an incorrect password on their first try at which point those unfortunate ones are only a few minutes away from a password reset... where they would be sure to get the password right that second time.
Requiring input twice as input validation has a fair amount of use already, like with email addresses, so it doesn't seem super unreasonable to think that's a motivation for this limitation.
Also, while it sounds silly, disabling copy doesn't mean a user can't type the PW somewhere else and paste it in. I've totally done that before and suspect it's not super uncommon.
Here in Norway, almost all financial and government institutions allow a form of authentication called BankID (https://www.bankid.no/en/company/).
I use the mobile variant and it works for all government related stuff like taxes, health, relocation notices and also with all banks both when logging in and paying bills, signing contracts etc. It is a legally binding identification akin to signing a paper.
The procedure for the mobile version is to input your phone number and birthday on the login and you get a popup on the phone (via the gsm network and sim toolkit, not ip) to input your password along with a short phrase like "pink bridge" so you can verify that it was the web page that sent it.
This also works with a lot of credit cards for paying online via 3dsecure.
It's become so common that a large majority of our customers (I work in a bank) are using this as the sole mechanism of identification.
(And yes, for the non mobile version of BankID you can paste the password!)
Isn't that vulnerable to MITM attacks for GSM? There have been quite a few demonstrated at DEFCON that could work very well for attacking this kind of system (on a large scale)
Attackers convinced (either with their official badges or by conning) the targets' cell service providers to change the SIM info associated with the accounts, and thereby intercepted SMS authentication codes.
You are confusing this method with one time SMS. This isn't SMS, it uses the Javacard-based SIM toolkit to decrypt a challenge sent to to the mobile number. the passcode for decryption is usually a 4 or 6 character PIN number. For an attacker to MITM this he would have to both have the number assigned to his own SIM and he would also have to impersonate the victim an show up in person to a bank or a security apparatus and social engineer his way so they program the new SIM with his personal PIN. a bit harder that just calling up the service provider to say 'I lost my mobile phone, i have this extra SIM card laying around, can you assign my number to that?'
Would the short phrase from the website over TSL mitigate this? Even if someone could snoop the GSM, there would still be some (hopefully random) string that only the web server and client would know.
The main in the middle could just decode any secret being sent. The only way I'd want to participate in a system like this is via a smartcard or a challenge based system over TLS
We have the same thing in Sweden. The mobile version also supports biometric authentication (TouchID on iOS devices) for less risky operations like logging in and transferring between pre-approved accounts. Very convenient and quite secure.
This is what we use here in Sweden as well. The reason it works is that all inhabitants are given a personal identification number upon birth, that consists of our birthday + 4 digits which are loosely based on where we are born and if we are male/female. This number is unique for every person and is used to register to the BankID service (among other things) and ensures that it is connected to a single individual.
In Sweden, we were at some point running out of numbers as when there were an unprecedented number of applicants due to the immigration a while back.
Someone was interviewed on the subject and said that if they built the system today, they would totally go for randomly generated number sequences rather than relying on a system based on birth date etc.
US SSNs used to be that way. The initial prefix was based on where you applied, and the last four were shown like it was nothing (Boeing used my last 4 as part of my UNIX account ID). Instead of 5-9 digits of entropy, you're down to just 2.
I still don't get why anyone would ever want to treat SSN / national ID numbers as private information. They're usernames, you give them to so many people all the time and they're printed in so many places plain that it's ridiculous to think they should be used as a secret for authentication.
> The reason it works is that all inhabitants are given a personal identification number upon birth
Isn’t that the same as the Social Security/National Insurance number you get in various countries? In France you have a unique number that depends on your sex, where you’re born, 3 more digits to differentiate you from all other people of the same sex that were born the same day at the same place and then a final digit for a checksum.
You are probably right, I added that part in because I read somewhere that not all countries maintain lists of personal identities as comprehensive but that might have been a long time ago, in that case my mistake.
The key bit is that it (sounds like) they use it only for identification, whereas the SSN in the US is treated as a "secret" which can be used for authentication (!?). Thus a weird legal limbo where it's officially not supposed to be shared around, as it can prove who you are... yet all kinds of businesses are required to record it to identify their employees :|
Not quite the same thing, but ID Analytics claimed that "6.1 percent of Americans have at least two SSNs associated with their name," and "more than 15 percent of SSNs are associated with two or more people" in commercial records.
Right, that goes along with "20% of credit reports have errors." (which was found in an FTC study). Example errors are misspellings and number transposing and both versions end up in the database. The correct report can be pulled up 99.9999% of the time even if it has errors because usually a bunch of data is used to pull up the report (name, address, birthday, social), not just a single number.
I know someone with misspellings of their name on one bureau's credit report and its never caused a problem (he's too lazy to ask them to fix it). The misspelling is listed as his name and the right spelling is listed as "other name" (or something like that).
The keyspace is also shared with the larger "TIN" (Tax ID Number) pool, though the pretty-print format is different:
SSN and ITIN: nnn-nn-nnnn
EIN: nn-nnnnnnn
So it covers not only all the individual taxpayers but also all the employers and businesses that are taxable separately from individual income tax payers.
So ... how can it not be exhausted yet, or at least close enough that it's irresponsible for officials to offer blanket denials regarding reuse of defuncts?
What if you have more than 10,000 people who have the same birthday? Let alone people with similar birthplaces/gender/etc. If that's all there is to it it seems like you'd run up against a combinatorical ceiling pretty soon.
There will never be a problem with that in Sweden. They're averaging 328 births per day. They'd need to increase their population from 10 million to the size of the United States to bump up against that limit.
Sweden has added two million people in the last half century. In net terms, essentially all of those two million have been immigrants rather than born in Sweden. They're de-populating when you exclude immigration, because their birth rate is so low.
10,000 people per day would be like Sweden adding 1/3 to its population in the next year. That's never going to happen. They're #166 when it comes to birth rate. Based on their population gain rate, they'll need to worry about the four digit limit in about 2,000 to 3,000 years give or take.
Actually, it already is a problem. According to this article, around 2,500 people have been assigned a personal number which differs from their birthdate. [1]
The last digit is just a checksum digit, so we're left with 3 digits per day. But that still would give some leeway for each day. The problem seems to be that some immigrants have been assigned a default birth date (Jan 1 and Jul 1) as their exact birth date is unknown.
Another issue which is not mentioned in the article is that we're only using two digits to encode the year (i.e. YYMMDD-XXXX), which causes problems now that many live to be 100+ years. Most banks and other places now requires you to enter a four digit year, even though that technically is incorrect. The correct way to annotate that someone is over a hundred years old is that the dash changes to a plus sign (i.e. YYMMDD+XXXX), although I've never seen that implemented anywhere.
I always assumed it was for the same reason sites make you enter your email address twice without pasting - to reduce the chance of mistyping. If you only have to enter something once, then you could easily mistype it and then you end up with an account you can't log in to or even recover. But if you have to type it twice, then the chance is greatly reduced, since you'd have to make the exact same typo twice in a row.
Edit: This is regarding account creation/changes like the PayPal example. I have no idea why login forms would disallow pasting.
If you're security conscious, you shouldn't be typing passwords at all. You should generate them from a password manager and paste them into the field both times.
It boils down to security theater making us all less secure.
As someone running a user-facing site, you cannot control whether your users use password managers. So what's your solution? Just disregard the segment of your users who don't use password managers? That's a tradeoff that you might not want to make, depending on your business.
Also, if you're someone who uses a password manager, does disabling pasting really make you less secure? I assume you're still generating passwords; you just have to retype them. So maybe less convenient, but less secure is kind of a stretch. (By the way, I personally use KeePass, and I generally use auto-type instead of pasting, so I'm not inconvenienced at all.)
> Just disregard the segment of your users who don't use password managers?
No, I recognize that most users probably don't use password managers. But I'm not convinced that disabling pasting helps much.
For one thing, I don't actually think it's that common for someone to copy a mistyped password. Browsers disable copying from password fields, so they would have to type it in a third place and copy it into the fields from there. Most users are not sophisticated enough to do that.
> Also, if you're someone who uses a password manager, does disabling pasting really make you less secure?
It directly encourages people to use less secure passwords. If I try to manually retype a 50 character password myself, I'm very likely to make an error. This isn't theoretical—I've often purposefully lowered the complexity of passwords for sites with these kind of arbitrary restrictions.
It's too bad 1Password doesn't have an auto-type feature.
You can get/set HTMLInputElement.value on [type="password"] anyway so if you wanted to shim the PW field copy/paste functionality back, you could just create a bookmarklet or something.
Edit, threw an example together. Ignore the horrible code ;P
Http://jsfiddle.net/6gc2d6hb
Type in one of the PW fields then double-click it. Doesn't overwrite populated PW fields.
That's a fair point that in general, password fields aren't copyable.
So I do think that retyping passwords has value, but disabling pasting may have questionable value. (In my experience, disabling pasting on email confirmation fields does reduce the rate of error there, since lots of people copy-paste)
I think I am slightly dyslexic, and have immense difficulty correcly transcribing a random string that is more than about 8 characters especially if it has numbers and random non-alpha characters. Logins that don't allow pasting the password often cause me to lock myself out due to repeated errors typing the password.
> Just disregard the segment of your users who don't use password managers?
No. But, consider that the segment of your users who don't use password managers is also very likely 100% intersecting with the segment of your users who do not ever attempt to paste a password into a password field.
So by blocking paste you have zero effect on the users you wish would improve their password practices, and a 100% negative effect on the set of users who are creating and using secure passwords.
> But, consider that the segment of your users who don't use password managers is also very likely 100% intersecting with the segment of your users who do not ever attempt to paste a password into a password field.
I guarantee you are wrong about this. For example, a lot of people receive passwords via email, and then paste them in.
How is that a solution to the problem of user error (i.e. mistyping)? Are you making an implicit assumption about password manager use and mistyping, that somehow your heuristic will be able to differentiate? That seems like a lot of work for something that may be prone to mistakes, while also delivering an inconsistent user experience, for the sake of some (unstated) assumptions about security that may not be founded.
People will almost never manually type out high security (>20 random characters) passwords themselves. So if someone enters a high entropy password, you can fairly confident that mistyping is not an issue.
1) Aren't there people using generators like Diceware that don't do the password management part?
2) The industry's definition of "high security" is constantly changing. Password strength measurement makes assumptions about what is and isn't guessable, and a lot of that depends on what techniques the common brute-force crackers are employing. So finding the right heuristic is also problematic.
> 1) Aren't there people using generators like Diceware that don't do the password management part?
I'm not sure they're actually that common. Moreover, if someone is sophisticated enough to use a password generator I assume they have some sort of system for ensuring integrity.
Also, if you're worried about someone changing their password to something they don't know, simply force a relogin and have effective password reset mechanisms.
> 2) The industry's definition of "high security" is constantly changing.
Industry might be getting more serious about encouraging higher security passwords, but standards for high security passwords haven't really changed much. People are just becoming less tolerant of low-security ones.
In terms of estimating security, you can use something like https://github.com/dropbox/zxcvbn which does a pretty good job of evaluating entropy and resistance to brute force attacks. Ultimately, a password with sufficient entropy will be resistant to any brute force cracker.
The nice thing about password generators is that you can have a huge margin of strength for free. Keepass defaults to 119 bit passwords. Require 100 estimated bits and you'll blow manual passwords out of the water.
Not concerned about security, but about the direct user experience. The user won't know that they've mistyped their password, won't potentially won't return when they can't log into their account.
Sites already do, but that doesn't stop users from copy-and-pasting from password generators or typing the password elsewhere and copy-and-pasting that twice.
If you are security conscious at all, you'd be generating a public/private key pair for website authentication, only using HTTPS and potentially preferring TOR. I mean, a username+password field is SO FAR from good security practices, it's almost a joke.
Interestingly, the french taxation department used to require you to identify on their website using a certificate, starting in the early 2000s.
A few years ago they dropped this requirement and you can now login using just an email and password.
The certificate-based identification process was really bad UI-wise so going with passwords probably helped them get more people to interact online instead of via paper forms.
I'd like APIs to automate rolling my passwords. Ideally keepass expires it, gives me a list and let's me day "go" and be automatically updates them all.
Once we had a chance to push openid to internet.... Now that would have been convenient. At least more are working toward google, twitter and facebook oauth, so a majority of services I use has no password at all.
That doesn't make sense - where did the user copy the email/password from, in order to paste it in twice? Somewhere clear text, ergo easy to double check for typos or at least discover them after the fact. If you're worried about someone copy/pasting a typo, you should disable COPY on the field, not paste.
If you've ever run a website that doesn't verify email addresses, you will likely run into this problem. The average person doesn't double check for typos, and they can't discover it after the fact because they didn't notice the typo in the first place, and you won't be able to contact them to inform them.
Your suggestion of disabling copy instead of paste may be a better solution, though.
Yeah disabling copy makes more sense. I think the scenario is where you have to type your password 2x to avoid typos on a field where you can't see what you've just typed (to avoid shoulder surfers).. the first time the user types the password, then they highlight and ^C and then paste into the second field...
People are going to forget their passwords no matter what, so you have to have a system in place for someone not knowing their password. If you have that system in place, it will also work for people who copied a typo in their password.
In addition, the whole point of making someone type their password twice when changing it is because you can't see what you are typing in a password field. You also can't copy what is in a password field, so there is no danger of someone copying the typoed password in the normal case. You are only stopping people from using something like a password manager.
Fortunately, it's not hard to get around this on desktop (for Mac at least) with an applet like Paste Typer. But when I see this on iOS it infuriates me. I use 1Password to generate strong (long) passwords and having to type them out manually is a huge PIA.
The annoying one on iOS is how often it makes me re-enter my Apple ID password. In a modal, of course, so it's impossible to bounce out to 1Password to copy the (very long and complex) password without dismissing the modal first. Sometimes I'll get a "re-enter your apple id password" modal at some random time while I'm doing something else, dismiss it to go get the password, and then have no idea how to get it back because I don't know what triggered it in the first place...
On Android, KeePassDroid registers as a keyboard to prevent other apps from retrieving your passwords from the clipboard. Not super familiar with iOS, but it seems like a good practice anyway, independent of its utility in circumventing asinine "no pasting" policies.
1Password does too but I've found that the Chase app and the Google Account manager all fail silently when using the keyboard to paste in your password. I called up Chase and they had no idea about why it wasn't working, although they could see my login attempts.
I only was able to figure it out when I changed my gmail password to something stronger and couldn't log back in and had to google the problem.
I have a Microsoft touch mouse, and I can program macros on the touchpad's regions. So if I press the top/middle part of the thing, it just types my password :)
In fact, now that I'm thinking of it, I can use it to trigger a script which will type whatever is in the clipboard. Silly javascript script kiddies think they can control a user's behavior like this.
Shouldn't chrome itself be a "don't fuck with paste" tool ?
As the world moves to the browser as the OS (essentially) it's imperative that the browser respect end user wishes and behave as a sentry against malicious websites and malicious website behavior.
Most of the time websites disable paste by registering "onPaste" events. How do you allow websites to keep doing that when necessary, but not allow the websites that break the paste?
I 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)?
>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.
If Apple has any sense at all they will allow apps to mark content being put in the clipboard as local-only. Otherwise this feature will leak all kinds of information intended to be private (passwords, stuff copied from incognito browser windows, financial information from tax software, etc).
I 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 better and more homogeneous. This is especially true if Google and Apple have their way with the Credential Management RFC and get people to have a reason to save their passwords with chrome.
"Passwords" are getting better but we need another 5 years to get us there.
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.
Perhaps the companies involved have been told by their lawyers that choosing a password is a legal action, like an electronic signature, that must be performed by a human, letter by letter, to have certain legal ramifications.
It is only stupidity if you assume the only purpose of a password (or a physical key) is security, and not also authorized entry. It may still be a poor engineering solution to the requirement (because engineers were told the solution, to asked to meet the requirement). But it is wrong to assume there is no reason for the requirement.
You can't paste your legally binding electronic signature either, I'll warrant. I've had to type out my name plenty of times, in digital contracts, even though my browser is quite capable of auto-filling.
This is all made up nonsense. You can paste your signature, choose some random image to represent your signature, or even merely click to sign. Have you used Docusign? HelloSign? Document signing in Mac Preview? Please don't spread FUD.
The companies involved have specified a protocol for communicating your chosen password to them. Namely, the well known "spelling protocol" whereby you repeat your choice, letter by letter, to the other party. They have gone to some pains to enforce that protocol.
The article advocates breaking the bank's protocol for your own convenience because you supposedly know more than the other party. In general, in life, this is bad advice.
Please do not ask people to do things against the will of the other contracting party for their own convenience, without considering the risks of doing so.
> It is only stupidity if you assume the only purpose of a password (or a physical key) is security, and not also authorized entry.
What's the difference really? I'm either way blocked from accessing my account. I don't give a damn what that some idiot nontechnical lawyer put into the ToS. I find these kind of services annoying anyways and the first sign is usually forcing me to pick a less secure password.
The article outlined a way for websites to check this: count the number of key press events (filtering modifiers of course) and the number of characters. Or you can imagine a particularly asinine site performing some statistical analyses on your keystroke timing (flight time and dwell time) and even deduce whether it's typed by a human or not. The thing is, this is a policy issue, not a technological issue.
You can always solve this technologically, though, as long as the code powering their nonsense checks runs on hardware physically under your control. There are no javascript commands, only javascript suggestions.
If it's JavaScript, you can script that out in your client.
Honestly there's no reason to do this bullshit of disallowing pasting client-side. If pasting is a problem, if your machine is compromised, it's got a key-logger too.
Those on-screen keyboards to try and foil that vector basically presumes everyone's infected, and so, encourages weak passwords that are more likely to be brute-forced by an adversary not using that interface.
Sadly did not work very well for me with Windows 7. In some situations it works like in X11, in some nothing happens (no copy/paste). Breaks opening links with middle click... Is there some alternative or fix that would make it function more like in X11 ?
I always assumed that the reason paste is disabled on change password forms is to prevent you from changing it to something you don't know. The whole point of making you type it twice is so that you get it right. If you type the password once and paste it twice, that is moot.
Not that I necessarily agree with that notion (just make it easy for me to change it again) but that's the idea. I thought.
What about the people who already have weak passwords, and accidentally misspell their dog's name or whatever? They're probably in the overwhelming majority compared to people using strong, complex passwords. Disabling paste here seems to be more of a convenience decision rather than a security one.
I have a crazy idea: what if we held people responsible for their own mistakes, instead of turning the world into a padded room? You messed up your password? Reset it. You have a virus / XSS that is slurping the clipboard? It's probably logging keystrokes too, and that's not the devs problem (well, XSS is, but blocking paste isn't the solution)
I agree that the security theater is annoying, and uselsess, but I think you are drawing the wrong conclusion.
Sometime in the 1960s we realized that we can't reduce fatal car accidents by "holding people accountable for their own mistakes". We actually have to make cars safer.
That's different, people can't learn from fatal accidents. They do learn not to ignore the "check oil" indicator though, we don't need to disable the engine to make people pay attention to that. This is acceptable, even if it costs the occasional fool an engine.
Why do you want to punish people even more instead of trying to educate them and help them? You and me probably do not make mistakes in this subject: but we have to admit we are both lucky and got enough education/insights to be able to handle security 'right'. Most of the population are not that lucky.
Forcing users to type out passwords does not educate them, or even encourage good habits. All it does is frustrate people who already have good password management habits, and encourage those who don't to keep (re-)using passwords that are easy to remember and quick to type.
This is one of those appealing-in-theory philosophies that comes up all the time. But you're ignoring the costs.
For the whole of human civilization, generation n-2 can complain that generation n is turning the world into a padded room. E.g., if you have a car, you expect it to just start at the press of a button or the turn of a key. But starting the Model T required physical strength and an intimate knowledge of the engine:
People who grew up on the Model T surely bitched about how later cars were making whippersnappers soft, what with their electrical starters and things just working reliably. But nobody today would say, "back to Model Ts so we can toughen up and really learn how internal combustion engines work". We have better things to do. Very smart car designers have made it so that we mostly can just get in and go. Soon, we'll just get in and the car will do the going.
That's what technology is for: We solve problems so other people can do what really matters to them. There is no sense in stopping now and saying, "Fuck it, 5000 years of technological progress is good enough."
Off topic note, but this comment causes this page to be nearly unreadable on iPhone, because it doesn't line wrap. Should probably be something in the HN CSS to fix that.
Great article. The only point missed is that password length limits AND re-type fields AND disabling copy and paste are all measures that when, implemented correctly, are supposed to help you remember your password and prevent easy access to reset mechanisms by forcing you to type it twice and not accidentally copy and paste it twice.
Of course, in an era where weak password re-use and leaked hashes are one of the biggest problems facing normal internet users, we really should re-evaluate all the above assumptions.
Or if it's too hard, let email providers handle the login security requirements... Since most places allow email-based password resets anyway.
I understand the desire to stop stupid users from being stupid, however outright preventing user best practice unless they resort to somewhat exotic workarounds is completely inexcusable.
> we really should re-evaluate all the above assumptions
I would not consider anyone supporting these practices remotely competent. There should not be any need to re-evaluate anything.
I 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.
There is a piece of terrible, unwarranted analysis in this article:
> But there’s one angle to this that helps explain the madness and it goes back to that earlier PayPal screen grab. This was of the change password page, not the login page. You can easily paste into the login page and in fact you can even paste into the original password field on the change password page, just not the new password field or the other field that confirms it.
> The reason lies in the earlier message I showed from PayPal, in particular this part of the password criteria:
> Use[] 8-20 characters
> Ah, so because you’ve gone and put an arbitrary limit on the length of my password and taken away my ability to create a nice a 50 character random string, you’ve had to kill the paste function because otherwise I’d go around thinking I’ve got a 50 char password but it was actually truncated to 20 due to the maxlength attribute of the password field. Nice one guys, good work there
Having spoken to no one about this, I'm still confident that Troy Hunt is full of crap. The reason to disallow copy-and-pasting into the new password field(s) is obviously the same as the reason you have a confirmation field in the first place: you want to make sure the user hasn't entered the password wrong, inadvertently locking themselves out of their own account. Allowing them to enter their password once and then paste it, typos and all, into the "confirm password" field completely defeats the purpose of having the confirm password field at all.
All joking aside, that's why you have password reset functionality. The reason I can't paste in most cases makes me choose another site. One that takes my security seriously. I'm the kind of user that wants to paste in a 40 character long password and store it in a manager that will allow me to forget all my passwords except one or two.
Any web developer who does this should be shot. Same with silently dropping characters from passwords when signing up and poor validation of email addresses
Backblaze is another company that does this, which is infuriating when you're entering your long private key into their client. CTRL-V doesn't work, but surprisingly, right-clicking and selecting paste does. I didn't realize this until I the second time I had to enter the key.
Not that I think it's a good reason, but I think the rationale behind disabling paste is to prevent users from implementing their own "password managers" via a .txt file full of passwords on their Desktop (more common than you'd think).
I'd rather a user has a strong password that they paste from a file than a weak password they can type easily. If their machine is hacked then it's game over anyway. At least using a txt file of strong passwords means their account is secure if the online service is compromised.
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.
I have a method of generating passwords from a cryptographic hash of a secret key and the name of a service. This has been defeated by several services that forbid me from using the resulting passwords, either because of their special-character requirements or password lengths (after encountering some of this, I prefix the output with "A1a" and cut it off at 16 characters, but I've used services where even that isn't good enough), or because they want me to change my password every N days and don't allow me to reuse passwords.
I submit, I give up, you win. There's a file called "plaintext-passwords.txt" in my home directory. I keep the account information for these services in there. I've thought of keeping it encrypted, but if they don't want my account to be secure, why should I?
Anyway, if I had to type these passwords in rather than paste them, that would not stop me. All it might do is incentivize me to make them shorter.
I am starting to be even bigger fan of 2FA. I had once bank account that prevented me from pasting pw first I made grease monkey script to remove this blocking then I removed my bank account from that bank.
Why do browsers all them to do this? Surely there should be some way to determine it's just a textbox and prevent the side from screwing up the user's actions? Same for autocomplete.
Every time I see an apparently stupid security restriction reason I feel obligated to check if "Password1" is a valid entry...
You won't ever believe how often this work while gibberish keychain-generated passwords get rejected because they contain a "-" character ...
Wake up IT departments it can't always be users fault. People born with Window95 starts to work, they won't take your shady security reasons for granted as did people born in the 60's!
They just will just think that your are incompetent...
I find it slightly annoying there were repeated hypotheticals that blamed the developer for designing these password pages. It's highly unlikely it was a rogue developer... Most of these companies probably use contract work and likely provide these stupid password requirements and use cases arbitrarily and weren't properly challenged...
I recently read that Slack has combined salting and hashing with 2FA after their data breach in March 2015. But if I remember well, whenever you want to connect, you can get a "magic link" with an automatically generated password right in your mailbox and then copy-paste it in the app. Has someone tested if it's bullet proof?
In Turkey there must be law which says that mobile carriers must cooperate with banks because when I enter my ID and my first password to the web page of the bank it says "oups! it appears that you have changed your SIM card, please re-validate yourself before we SMS you a 2fa password".
And in Bulgaria I saw use of client-side certificates.
Disabling paste on changing password strikes me as a good idea. If you're not pasting from a password manager, it's easy to accidentally select additional whitespace or miss the first or last character. If you then paste it, you end up with a different password than you thought.
What? The password comes from the password manager in the first place! Please people, do not break shit just to protect me from my own sloppy mistakes.
I could see it having at least some benefit if you not only disabled paste, but tracked the individual letters as they were typed in. It'd give you a little statistical information, like how Google watches how you click a checkbox for a captcha.
But it seems like an actual captcha would be better, then.
The final inanity; what supports a compromised user device from simply submitting it's own copy of the form that it populated, or even transparently proxing the client and MitM on the compromised machine it's self so that it can change the submitted values?
Windows doesn't let you paste whenever you are in one of those 'elevated' contexts, like the login screen. In fact, this prevents my nifty mouse macros from running too.
One of the local bank in my city not only disable pasting, it disable typing altogether! It pops up a virtual keyboard and let client click on those virtual buttons. Since noticing that, not one single service from that bank was used anymore
Can someone school me in why we don't just throttle login attempts (each fail extends time to next attempt exponentially) and put an attempt cap that requires password reset?
So what banks out there actually have password systems that let you use secure passwords, or maybe even real 2FA that aren't German banks with their TIN systems?
No, it counts as the paste event as well. But pasting to another text field in the application (or just the address bar), selecting and dragging the password to the field works, as it just counts as a "change" event, which would be very hard to disable without causing issues.
and at this point, who isn't using a mobile device to enter passwords where potential shoulder surfers (human and camera) lurk? Without copy and paste, you have to what? Go into a bunker to type in passwords safely?
It always amazes me that someone is hired to implement strong security and they come up with things like paste-blocking. Or "security questions." Security questions are a social engineers best friend. Unless you're savvy and your answers are all strong passwords themselves, and if they are you're probably using keepass or something like it with 400+ bit passwords and you hate wasting time on security questions too.
I respond with a strong password for all security questions. It created a cute incident recently when I had to verify my account over the phone by telling the phone rep that my favorite pet's name was 'o(c:Y^u=86U@4k', or whatever. I'll give the rep credit, they didn't care the answer made sense, just that it matched their screen.
I had a bad time recently with one of those when the IVR system tried to verify my security questions. I ended up making farty sounds at it to get it to give up.
I'm intrigued as to how you 'pronounced' that. Did you say "open parens" and "caret", and did they understand what you meant? Also, is having to divulge your password really the best way of verifying your account? Do they advise you to change your password immediately after going through this rigmarole?
I would have rattled off something like "oh open paren sea cap why colon caret you equals" and so on. Honestly I have no idea if they parsed the sentence, or decided "gibberish from phone equals gibberish on screen .. good enough"
They didn't advise me to change my security question, no doubt because the name of my favorite childhood pet isn't likely to change.
Another good argument is: having 5 passwords is not more secure than 1 really strong password.
I also think 2fa is ridiculous for 99% of applications. The widespread adoption we've seen is largely the result of developers trying to solve for user error, which as I stated in a previous comment is a waste of time and can never succeed (unless your goal is to find the flaws in your system).
I do that too but shot myself in the foot on one site. Somehow I did not get one of the three random "answers" recorded in my password manager. And of course THAT is the question the site is now insisting I answer. I have tried a few times hoping one of the other two questions is presented, but so far no luck.
United MileagePlus just switched to security questions that only allow multiple choice answers. Some of the questions only have 12 valid answers. Compare that with even a weak password! Unbelievable.
> Unless you're savvy and your answers are all strong passwords themselves, and if they are you're probably using keepass or something like it with 400+ bit passwords and you hate wasting time on security questions too.
The worst part is that some companies (TradeKing) turn these into multiple choice questions, where a password-like answer will stand out like a sore thumb.
My school had me sign up for a service that required an 8-character long password containing at least one number, one special character, and a mix of uppercase and lowercase letters. The recovery question was "what is your father's middle name?" No way anyone could find that out or guess an incredibly common middle name. Also I should mention that our school required us to sign up using our school email address as our username, which was assigned to us on the basis of the first letter of our first name and our entire surname. And also the address says where we go to school.
Do security consultants just completely lack common sense?
It's amazing to me how insecure email is these days. If you know somebody's email, and you have a plausible reason to have a conversation with them, you can very easily take over their email account and reset the password on every account attached to it.
I often wonder how much the security of email (and by extension, every other account online) depends on people just not knowing how simple and easy it is to break into. If everyone knew, we'd be living in chaos right now, right?
I imagine he/she is referring to how most "security questions" use info that we typically don't hesitate to give out in casual conversation, even with total strangers.
Someone pointed out that if you talk to a CS rep and try to say that off, they'd just hear gibberish- meaning if someone tried to get at your stuff, they would just have to spout off gibberish and the CS rep would probably accept it.
If you can do this, it seems weird you would ever need to contact support for help. If you can keep the security answers safe why can't you keep the original password safe in the same place?
Or is this for when the account is locked for some random reason?
To me, the scarier idea is how many of these answers are now online. Mother's maiden name and other family names can be gotten from wedding notices or obituaries. For a teenager, the first job / school / car / concert are probably all available on Facebook. Even without the Internet as a backup, I could probably answer the security questions for 2-4 of my childhood friends.
I think if I had a casual conversation and they started asking what was your pets name, where did you go to school etc I'd think it a bit odd. As an aside I usually have to write down the answers I've given in a word doc and look them up if I need to do that stuff as I can't remember which memorable place it was and the like.
Really? I'm sure it would seem odd if someone just ran down the list of questions, but I suspect you could easily maneuver the conversation so that a casual acquaintance answers one or two of them.
"Hey, how are you?"
"Pretty good. We're thinking about getting a dog so I went to the shelter this morning."
"Oh really?"
"It's tough to find one that's a good match though."
"Definitely"
"You ever have a dog?"
"Nah, wife's allergic. Had a snake as a kid though...called him Mr. Slithers."
Nah... it's brute force all the way down. Scammers aren't brilliant men in dashing suits who swindle bankers, they're assholes who prey on the weakest. The second you do something that doesn't mark you as weak in some way, they don't want you anyway. It's the human equivalent of scanning large IP blocks for basic security holes.
This exactly why all my e-mail passwords are at least 18 character long with random generated gibberish stored on a keychain...
And to secured that keychain I use a very long login password (XKCD style + numbers) that always make people cringe.
In return I assert a well deserved facepalm when I see a friend log in on his e-mail account with a variation of "Password1".
The funny thing with having email as a username is, how sometimes people can use social engineering to gain control of your account, non of that fancy "hoaxer" stuff are needed when your service providers put untrained people in charge of your accounts. Hacking human stupidity is a more effective way in to get in to a secure system.
Nope I mean I kinda never login to my mail through unknown browser. My smartphone is just good enough when I can't access my computer, so there is only three places where my long e-mail password is stored. Keychain on my computer, keychain on my smartphone and backed up encrypted keychain in my cloud account. So it's highly unlikely that my e-mails get compromised.
Also worth mentioning my e-mails are not hosted on gmail or any big cloud player. I actually pay for my imap, when you don't pay you probably in some way are the product...
"If you know somebody's email, and you have a plausible reason to have a conversation with them, you can very easily take over their email account and reset the password on every account attached to it."
Not if they self provide their own email (by running their own mailserver).
Spammers are the ultimate Sybil attackers. Setting up a useful SMTP server as an individual, and creating a new non-blacklisted identity as a spammer, are effectively the same task. The community of legitimate email providers has responded (quite effectively, and without too many false positives) by making this as expensive, difficult, and time-consuming as possible.
Emails from residential modems are not even worth scanning - they are practically guaranteed to be from botnets. Emails from commodity hosting providers are also pretty suspect, because they're very easy for spammers to get their hands on.
If you want your mail delivered, you need to send it from IP addresses that don't have those obvious red flags, don't have a reputation for sending spam any time in the distant past, and also have a long-term positive reputation for sending non-spam email.
In practical terms, you need to be in the professional mail server administration business full-time (be extremely careful to shut down abusive customers/tenants rapidly, never make a mistake that would let an attacker run an SMTP server on your network, etc.) or you need to pay someone who is, and who trusts you to cloak yourself in their reputation and not ruin it.
And that’s why I host all my email myself, and have my VPS with no password login (only key auth), and have 2FA enabled for the VPS control panel at the hoster, and have 2FA enabled for any change to the domain requiring a letter to be sent to me.
There are many different types of virtualization. Most of them use disk images, meaning someone can read (or even write to) your disk without you noticing.
Some of them are lightweight virtualizations where a priviledged outside user can run processes inside the VM without requiring authorization or without being logged.
With a dedicated server I’d have more privacy, indeed, but already with a VPS with encrypted data that requires me to decrypt manually by entering a password upon restart via ssh to start the actual email service I gain a lot of privacy.
>Sometimes you want to use the same credentials on multiple domains of the same service and auto-fill only works against the domain the pattern was recorded on.
Oh good so I'm not alone! I tried setting it up but trying to mass import multiple passwords from KeePass over (which doesn't translate directly 1 to 1) left me manually entering them. The process was so incredibly slow and cumbersome that I gave up. It doesn't help that LastPass looks like it was created in 2003 by developers with zero UX / design talent.
It's gone from apocalyptically bad to horrendously bad.
I have no idea where they thought any of that UX would be even remotely a good idea. Everything about it is misguided to such an extreme I'm left wondering if there's a single human on their development team.
1password may not be perfect, but their attention to usability is obvious!
Lastpass is horrible. And IIRC someone posted a proof of concept attack a while back which looked exactly like the LP password dialog but instead stole your credentials.
One reason to dissuade users from using the clipboard to paste passwords is this: the password stays in the clipboard.
Not all users realize this, and so .. don't 'clear' the clipboard after logging in .. which means their password is still available to anyone else who might use that computer.
That seems like an incredibly weak argument: if an attacker has physical access to the machine, all bets are off. How do you know that there wasn't anything installed to MITM everything already?
That's an interesting idea actually. My first response was that you can't freely interact with the clipboard but you can set it provided you do it in response to a js event so in theory that is possible. The only problem is that you'd need to be sure the clipboard did actually contain the password because of course you can't read it. I guess you can log whether onpaste fired and then if the login button is clicked with a second or two, clear the clipboard.
And by 'clear', I mean add a textbox, set its value to an explanatory message '{app} cleared the clipboard because it contained your password' and then execCommand on it.
Hopefully there is nothing important in the clipbkard, like some data that the user will attempt to submit a second time after logging in. It sounded like a good idea at first, but now I want my +1 back :p
I've written short Powershell functions that watch your clipboard and send it over UDP to a remote Powershell session. Does your favorite Powershell module have something similar? It could simply load with Powershell and start logging your clipboard.
Developers don't need to be mindless code punchers. They can be thoughtful individuals who say, "that's dumb", and then have a discussion with the PM on why that is dumb.
On the other hand, maybe development of software is a mindless endevour, and so the labor in this area must be cheap, right?! </sarcasm>
You're right, of course, but it's also true that in a real life environment, you've already found a polite way to say "that's dumb" three times this morning and you're starting to pick your battles.
This! Dilbert is a documentary not a cartoon. Devs work for businessfolk. Businessfolk have the control call the shots. Sure they'll listen to devs but get the final say.
Couch your suggestions in business terms? user engagement decreases when you don't let them save their passwords or some such drivel.
honestly if you think businessfolk call all the shots, you may have a broken business relationship
Ultimately they call the shots because they'll judge the developers idea and say yay or nay. All a developer can do is influence and with a given number of battles to fight, password copy and paste may be a long way down there.
It requires getting promoted to management or board level to get the ultimate decision power. Some companies are more progressive when their board chooses to be but they can always revert back if they choose or get taken over.
He never described the _initiative_ as imperialist, just the British rulers. Since the British rule of colonial India is virtually the dictionary definition of imperialism, I'll go ahead and call the author's word choice reasonable.
It's true that the article doesn't describe the initiative as imperialist in so many words, but it does portray it as such in the sense of putting "imperial or sovereign interests over the interests of the dependent states" [1]. I apologise, my use of the word "imperialist" was quite redundant as I had already used "self-interested". I further apologise for extending this tedious game of definitions but since I have now been flagged as well as downvoted, I can only assume that my original comment was desperately unclear.
Their support forum is full of angry customers, people who can't use their screen readers anymore, etc. They argue [1] it's to protect their customers from key loggers.
[1]: https://community.tradeking.com/forum/categories/suggestions...