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.
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.
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.
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.
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...
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.
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.
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.)
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.
> 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.
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)
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.
> 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.
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.
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.
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.
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.
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.
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 ?
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.
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.
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.
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'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.
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?
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.
> 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.
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.
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...
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.
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)
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.
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.
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
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.
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.
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 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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 :)
>> "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."
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.
>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.
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.
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).
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'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.
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 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.
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?
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
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.
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?
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...
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.
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.
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."
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.
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.
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.
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.
"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.
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.
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 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.
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).
> 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?
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.
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.
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).
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 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.
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.
449 comments
[ 2.1 ms ] story [ 360 ms ] threadOf 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.
> 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.
Starting with the premise that users should be remembering passwords at all is a mistake.
On the other hand, maybe development of software is a mindless endevour, and so the labor in this area must be cheap, right?! </sarcasm>
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.
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.
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.
I find it absolutely infuriating that this is necessary even when "purchasing" a free app.
The #1 reason I will not buy an app is because I do not want to deal with entering my Apple ID password yet another goddamn time.
If your phone shuts all the way down with any regularity, it's a nightmare.
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.
That way, password manager users can paste into both fields, but users who are hand-typing are forced to avoid mistakes.
A user typing the password elsewhere probably means they were able to see it while they type, and are therefore less likely to make a mistake.
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.)
Allow pasted passwords if they meet a very high password-quality heuristic; deny them if they seem too guessable.
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.
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.
isolate the users so they cannot destroy your system when they get hacked, because they will always get hacked.
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.
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)
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.
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.
I guarantee you are wrong about this. For example, a lot of people receive passwords via email, and then paste them in.
These days, I will refuse to log in to any website which doesn't support https.
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.
Your suggestion of disabling copy instead of paste may be a better solution, though.
Except no browser ever allows you to output data (as a clipboard copy-operation is) from a password field.
This is not a real scenario.
I like the idea of two factor input; enter/select a password on a phone and send it over WiFi to the pc to paste into the field. Does this exist?
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.
It doesn't trigger not copy events (so the website can't mess with the text), nor paste events. Just the way it should be.
0 - http://fy.chalmers.se/~appro/nt/TXMouse/
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.
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.
I got so fed up with TradeKing (which has horrible security practices in general) that I close my account.
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.
Which is pointless anyway because at the point you access the keyboard buffer you can as well install a certificate and get a proxy going
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 :-)
(Curious as to whether it would actually work though.)
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.
First you enter a password, then you have to enter a pin using a on screen numpad with jumbled placements.
And likely the game will be doing all manner of things client side, thus it is cheaters all over the place.
Tell me why plaintext password storage is bad, and you'll defeat your own argument.
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.
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.
That's still 2FA though, isn't it? You're proving to the server that you have the card and the pin.
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.
[0] https://www.rabobank.nl/images/how_does_the_rabo_scanner_wor...
[1] https://www.youtube.com/watch?v=f5FIxRsqFUA (work flow - in dutch, start at 20 sec, before that they show the old reader)
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.
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)
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.
Store in DB id position hash user_id 1 0 x0 1 2 1 x1 1 3 2 x2 1
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.
Why do hacker news people think they are better at security than multi billion dollar banks?
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.
Banks are good at not losing money.
But website security is an afterthought for them.
It's easy to make a website that has better security practices than a typical bank website.
It's not about having better skills or resources, it's about having the motivation to do it in the first place.
A bank could set up spectacular security, but that doesn't mean they usually do so.
Everybody knows that we are hopeless at it, and often the flaws that are exploited are just as simple as this.
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.
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.
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.
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.
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.
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.
Well nevermind. Fun thought though.
If an attacker is running code on your system, you are already lost.
[1] http://i.imgur.com/QCGPDWz.png [2] http://i.imgur.com/VdtGC4T.png
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.
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.
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.
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 :)
Edit: I realise you're probably referring to proprietary bank authenticator apps
see http://willtracz.co.uk/shamir-secret-sharing-and-passwords
Above is on the page you're linking to.
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.
That's why you should use Lastpass.
I hope they can improve that one day.
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!
http://www.tomsguide.com/us/lastpass-phishing-attacks,news-2...
Especially ever since Apple disabled pasting for decrypting external drives.
A .txt file on the desktop is actually probably a lot more secure than using the same shitty password on every site.
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.
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.
https://github.com/jswanner/DontFuckWithPaste
(I usually keep it disabled, but enable it when I'm about to use a site that has paste disabled on any fields.)
(Temporarily disabling JavaScript is sometimes an option.)
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.
When would I ever want a website to know the difference between me pasting and me typing some text?
Edit: Does anyone else feel... increasingly... trapped?
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?
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".
Just use a strong password ( https://xkcd.com/936/ )
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.
( as an example, this was on reddit just yesterday https://www.youtube.com/watch?v=lc7scxvKQOo )
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...
Paranoid? Maybe
Safe? More than others
email recipient: Pasword123
me: thanks.
JOB DONE :-)
"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."
Here's how I deal with sites that require them:
site: "What is your first teacher's name?"
me: "'Fx|<n8K@W8#[_,[ (1p)jqPC"
The answer is a password equivalent, so I just treat it like a password.
Or is this for when the account is locked for some random reason?
Some of them are lightweight virtualizations where a priviledged outside user can run processes inside the VM without requiring authorization or without being logged.
How is this a meme that needs to die?
Not if they self provide their own email (by running their own mailserver).
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.
http://i.imgur.com/DWKiy2a.jpg
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.
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).
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.
Do security consultants just completely lack common sense?
[1] http://www.dictionary.com/browse/imperialism
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.
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)?
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).
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...
But it seems like an actual captcha would be better, then.
But for login, I see no reason to prevent it.