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.
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...