Major breach found in biometrics system used by banks, police and defence firms
theguardian.com
theguardian.com
Quote :
Our team was able to access over 27.8 million records, a total of 23 gigabytes of data, which included the following information:
- Access to client admin panels, dashboards, back end controls, and permissions
- Fingerprint data
- Facial recognition information and images of users
- Unencrypted usernames, passwords, and user IDs
- Records of entry and exit to secure areas
- Employee records including start dates
- Employee security levels and clearances
- Personal details, including employee home address and emails
- Businesses’ employee structures and hierarchies
- Mobile device and OS information
One of the more surprising aspects of this leak was how unsecured the account passwords we accessed were. Plenty of accounts had ridiculously simple passwords, like “Password” and “abcd1234”. It’s difficult to imagine that people still don’t realize how easy this makes it for a hacker to access their account.
I am shocked... SHOCKED!
Actually, I'm not. Maybe, I should be?
Commence anecdote: When evaluating which of 2 positions to accept, I settled on {CompanyX} because of the CTO, who seemed like an excellent person to learn from. Something like 20 years in leadership & a linux chops that I'll probably always be envious of.
By the time, I'd accepted the offer & taken 2-weeks to get settled into a new town, he'd left the company (quite the surprising red-flag for me)... but was still monitoring Github as part of the changing of the guard.
The first issues I filed at {CompanyX} was "we are sending passwords in cleartext(!!!)".
It wasn't 5 minutes before CTO-LINUX-GURU shouted me down. "IT'S HTTPS, NOT CLEARTEXT!". His message was sharp, and the obvious subtext was that I was dumb.
Well, if you say so... I let it go, and kept my head down.
Months later, we had to reset a bunch of user accounts because those passwords were being logged (in cleartext) to emails, and also saved to error logs when users had a difficulty logging in.
After 8 months with the company, I'd finally had enough. 2 months after I left, the friends I made there called me to tell me they were looking for work. The company had run out of money, and laid off a bunch of engineers.
Obviously (not) logging cleartext passwords is the kind of thing you learn in Security 101.
You can securely send plaintext over TLS, but it’s best not to when avoidable — precisely because it’s inviting the disaster above.
1. Sending in clear text over HTTPS from the login form to validate authorization: normal and OK, this simply is how auth works. Here the user sends the password, not the site, though it is via the frontend.
2. Writing/storing cleartext password on the server/in DB/as part of a logline, and (inevitably) revealing it later when reading said stored data for some other innocent purpose (server is sending the cleartext password which it should have no record of and has no legitimate use for).
Good hashes are by definition a one-way, irreversible means to authenticate without leaking actual credentials. Storing the actual passwords anywhere in the system is tempting fate.
A) The password was being sent in full to the server, over HTTPS?
B) The password was being sent in full to the server, over a plain text (unencrypted) channel?
It sounds like the CTO was claiming the former (A).
If you are running JS on the client anyway, then it seems reasonable to pass the client the salt, and ask only for the hash of the salted password.
But, if you say it's never OK to send the full (unhashed) password over HTTPS, then this implies it's not OK to have a fully server-side web app with password authentication. Because the only way to validate the password is for the client to send the whole password (unless you only ask for specific characters, but then password storage gets harder).
I wasn't arguing FOR hashing the password before sending it. My point was this: even if we think it's reasonable to require that a password be hashed before being sent over HTTPS, the corollary is that all web apps must use JS, and can't be server-side-code-only. And this corollary doesn't seem like a reasonable thing to require.
Your point that 'Hashing the password in the client isn't very effective because the hash of the password now is equivalent to a password.' is true if there's no salt, and if the password is never re-used across sites.
If the password is salted before being hashed and sent by the client, then having read-access to the plain text of the exchange only gives the attacker the ability to log in to that one site. Even if the same username/password combo is in use on other sites, the attacker can't use the password on those sites, because she can't hash the unknown password with an arbitrary salt.
Anyway, I'm definitely not an expert on this topic, so take what I wrote above with a pinch of salt (ha!).
My only reason to comment was that I was thinking through 'never send passwords' from first principles, and it struck me that, if everyone were to accept this to be true, they would also never willingly/knowingly log in to any site that works without JS.
Passwords suffer from the same "weakest-link" problem to a degree, but at least we can choose to have more than 1 or 2 and even more than 10 different passwords. Also, they can be changed after a leak. In biometric authentication, once your raw biometric data has been leaked, you are basically left to rely on the strength of the PAD (Presentation Attack Detection) and the (lack of) propagation of the leaked information.
Until the public perception about them changes, vendors will keep pushing the scheme ever further as a silver bullet.
I've been playing around with (and written about) the idea of a new set of authentication factor categories. I think part of the public perception problem is the "things you have, know and are" slogan of authentication (factors). It is super catchy, but makes biometrics ("are") way too prominent. It promises you can prove who you are by who you "are". Why the need for the other 2 categories?
I'm still on the fence as to the replacement, but I think seperating the factors based on "knowledge" versus "possession", and then further based on high versus low "transferability" is a good start. Smart cards are highly transferable possession factors, whereas biometrics are lowly transferable possession factors. Passwords are highly transferable knowledge factors, whereas things like keystroke dynamics are lowly transferable knowledge factors. The model really just lacks a catchy slogan now.
ffs, so anyone who's watched myth-busters can literally re-create the fingerprints of millions of people to bypass security or plant evidence.. If there is any justice in the world, Suprema should be liquidated to compensate the millions of people who can no longer use their fingers as a security check.
It's almost impossible to use hashes for fingerprints with COTS scanners. You use templates which in most cases, if left in the open, can be used to reverse engineer and get a fingerprint to match that template. Though it does not have to be the original one.
I was under the impression that with a template all you can do is use that template to authenticate on that system or other system that use the same schema.
Could you elaborate? How you would go about it? Any links I can read up on?
No, really, any source on that?
If this were just a regular company, the failure could be excused a little. But an authentication management company that doesn’t have security controls in place shouldn’t be in business.
Suprema blamed us for not using a high enough quality for enrolment and also for not doing the enrolment properly.
We used their enrolment method, a very specific way of placing the finger on the enrolment reader, and this had the effect of making it easy to reach high enrolment quality, i regularly hit 90, 95 out of 100 but you needed to be an expert at enrolling.
Effectively, it took about 10 attempts per finger and we'd do 2 fingers minimum. Even after that we had the odd wrong match.
Our client had 500 people to enrol, with a further 4000 to 6000 [sic.] to come in the next two years and they decided to can the whole thing and blame us for the whole fiasco. Even when we had suggested they go with the more expensive readers (Ievo) and made it clear that we were using these cheaper readers for them.
> They were able to search the database by manipulating the URL search criteria in Elasticsearch
Am I going dumb or is this mumbo-jumbo?
It's both funny and baffling how publications keep writing nonsense instead of saying “we are unqualified to explain the workings.” But then, I've seen similar behavior from people apparently unable to admit they don't know something. Which tendency can be outright harmful sometimes.
Fingerprints are your login, not your password.
One thing I worry about is if/when the government(s) start using the same algorithms that industry is using to generate $HASH in all these biometric scanners. Some ugly version of the world where the local police department can search FBI+Apple+Google Fingerprint DB.
See the repeated use of the word business? It’s because until companies who mess up like this (I’m looking also at you Equifax and TalkTalk) are forced out of the market then standards will remain lax.
The title would be less like click-bait if it simply said: Vulnerability Found in popular Biometrics System allows access to gigabytes of data including unencrypted passwords.
I'm still surprised how the goto reaction on this kind of incidents is ignoring the researcher and than claiming nothing happend.
There should be a government agency to report this kind of findings to and those cases getting handled like the real world equivalent of a toxic spill.
I assume if your biometrics information has been stolen, you don't want to be in any compatible/similar biometric authentication system ever again because of the risk.
Most people wouldn't even realise that the glass wasn't the target...
Second, have you thought about scalability and risk analysis?
My point being, if you want to break into one of these offices, there are easy ways which can't be easily mitigated against. If you want to do it covertly... get a job as a waiter at that restaurant...
Whatever happened to Defense in Depth?
All secrets (yes, all secrets) eventually leak ... so
1. Perimeter security should be good.
2. The body of secrets behind any given perimeter should be small, so fewer secrets leak in case of a perimeter breach.
3. Breaches and leaks (data exfiltration) should be detectable, and actually detected.
4. Corrupting the body of secrets by inserting or changing them should be defended against rigorously.
5. The secrets themselves should have limited utility. Securely hashed passwords are a good example.
6. The secrets should have limited useful lifetime. Credit cards can be replaced, so they meet this criterion. Fingerprints... their useful lifetime is the same as the subject's lifetime; not so good.
Not even state actors with unlimited talent and funding (hi, NSA!) can prevent secrets from leaking. So why don't more secret-gathering organizations do steps 2-6, or at least try to do them?
This Suprema outfit has a lot of business in Europe. It seems likely they will be severely punished by GDPR enforcement.