> “If there has been any definite threat on our products and/or services, we will take immediate actions and make appropriate announcements to protect our customers’ valuable businesses and assets,” Ahn said.
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'm going to make a "PR boilerplate as a Service"... It will just be a service that replies "Thank you for asking about $PROBLEM. Our customer's security is our number 1 priority, and we will do a thorough review of our policies to make sure $PROBLEM doesn't happen again.".
No problem, navigate to your bank's webpage, click the biometrics login reset link, enter your email, open the email and click the verification link. You will then be prompted to choose a new body to associate with the account. Your old body will be promptly picked up by a certified mortician. Leaving a tip is optional.
Another business in the tech security business that has no business being in business.
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.
Biometrics as an authentication factor suffers from a "weakest-link" problem. The strength of authentication of _every_ system using biometric factors can only be as strong as the weakest, least secure implementation out of those systems.
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.
I honestly feel that the best we as an industry can do about it is to start referring to biometrics as "amputationware". As often and widely as possible.
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.
> The security researchers scan ports looking for familiar IP blocks, and then use these blocks to find holes in companies’ systems
> 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.
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.
I'm amazed how few people have cottoned onto the fact that if you wanted to steal a copy of someone's fingerprint, all you have to do is wait for them to go to their favourite restaurant and steal their empty glass.
Most people wouldn't even realise that the glass wasn't the target...
Sorry, poor choice of words on my part. "Seem to have". It's anecdata, it doesn't seem (to me) to get much media coverage.
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...
Yeah I constantly have to go around making a funny face nowadays. The trick to a safe new face is to take 4 random words (for example: horse, clown, sad, elf-ears) and create your new face by imitatating that 24/7. Or you use a face manager (or make-up artist as it is called in non sec circles) so you just have to remember one face.
This is why I love the expression; (first heard, either here or on Slashdot)
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.
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.
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.
The thing you learn in Security 102 is that you should encrypt passwords in HTTPS anyway, because so much of your middleware will assume fields aren’t secured, and will happily log them — that while from a theory standpoint, password-over-HTTPS is fine, in practice it’s a liability due to organizational issues.
You can securely send plaintext over TLS, but it’s best not to when avoidable — precisely because it’s inviting the disaster above.
Client-side encryption is security theatre. If clients encrypt the password, then an attacker can send a log-scraped hash just as easily as a plaintext one. If anything, the faults (like the one above) would still exist and just become harder to spot.
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).
Hashing the password in the client isn't very effective because the hash of the password now is equivalent to a password. If you have the hash you can just send it to the server and authenticate. Implementing this looks like a lot of trouble with little to no benefits, since you also have to take the regular precautions server-side anyway.
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.
Isn't it normal to send passwords over HTTPS? This is usually how login and password reset work. Obviously you have to be careful they don't get logged.
Sending passwords over HTTPS is fine, but storing them in plain text is not. Hashing should always be done on the server side, with great care taken not to leak or log plaintext passwords (see Facebook).
So the way I read this, “sending” is an ambiguous statement that could be really ok, or really bad.
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.
>"instead of saving a hash of the fingerprint (that can’t be reverse-engineered) they are saving people’s actual fingerprints that can be copied for malicious purposes."
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.
>"instead of saving a hash of the fingerprint (that can’t be reverse-engineered) they are saving people’s actual fingerprints that can be copied for malicious purposes."
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.
> 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?
The VPNMentor krewe carried out responsible disclosure according to the upstream blog post. That's good.
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.
If you collect the data, some of it will be exposed, that's a very real risk. Especially in cases like this with biometrical data that can't be changed. I wonder if something will change after a few big leaks in this sector.
Yeah, having a immutable input key has always seemed real scary to me. Text/numbers has always seemed the best to me but if you really want something quicker and more natural for humans to do than writing, why not go for something like a pose or hand gesture. That can be easily changed, though I am not sure how many different versions there are of it. Spell out something in sign language?
Is there a list of all countries/companies using their software? My country uses those fucking stupid finger-printed ID's. I'd very much like to know whether they use Suprema's system.
Suprema said they will take the immediate action. The only action of any value now that the data is already exposed is to fire the CEO and everyone in line below to the devs who touched the unencrypted data.
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.
They really should be sued out of existence and nothing less... perhaps it sounds harsh, but unfortunately companies have to be scared into taking security seriously, otherwise they will just continue to cut corners to save money or out of simple incompetence (which again could have been prevented by investing in a proper security audit)
We used Suprema readers and they were absolutely terrible. They would match the wrong fingerprint with regularity (~50 people trial we had a wrong match on day 2 and we averaged ~2 a working day after that)
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.
Maybe I'm being naive but why don't they store hashes of the biometrics on the server instead? Then just change the hashing algorithm if there's a compromise?
The title could be improved. There was no major data breach, unless you consider the researchers that discovered the vulnerability to be perpetrators of a data breach as a result of their research. That is not normally how security research is interpreted. They found a vulnerability, not a breach.
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 did some poking after reading this and there's a KB app located at http://kb.supremainc.com/home/doku.php that is vulnerable to CVE-2017-18123 as well. Rated 9.3 severity.
56 comments
[ 3.4 ms ] story [ 117 ms ] threadI'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.
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.
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.
> 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.
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...
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.
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.
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.
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.
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?
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.
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.
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.