I have nightmares of them going with two USB-C ports.
USB-C is awesome, though only two ports would be insufficient. Four like the MBP has would be good, and they're small enough it should create no issues, especially since you no longer need the thunderbolt or power ports.
going Retina
Why would you not want a higher-resolution screen? It makes everything much smoother and nicer looking.
Just don't fuck with the mag-jack
I prefer USB-C for power, though there are some downsides. The main one is the lack of a light to show charge status. I don't miss the mag jack. It always seemed like a clever idea, but it's way too easy to accidentally disconnect.
keep the SD card slot in there
I do miss the SD slot in my MBP. I'll give you that one.
This is even more insidious than slavery because they have tricked people into begging for these shitty jobs
You're getting more than a little hyperbolic. Do you know any H1-B employees? They aren't tricked, they knew what they were doing and nearly all of them not only would but will do it again. There are problems with the system, sure, but wild claims like yours really don't help your case, they just encourage people to dismiss you out of hand.
To me it sounds like quite a few use biometrics as a combined username+password which makes things even worse. Here in Sweden we have a publicly traded company, Fingerprint Cards (https://www.fingerprints.com/), who pushes the idea of fingerprints as the secret key to payments and what not. Do watch their site, it's a good horror show! (you won't sleep well though).
I don't see any problems at all with what they're doing. They are not using the biometric as both identity and authentication. The chip card provides the identity (username), and the biometric authenticates that the correct person is the one holding the card. That is a proper use of biometric authentication which is strictly stronger than chip + signature and roughly as strong as chip + PIN (roughly because PINs and biometrics both have weaknesses, just different ones, so which is more secure depends on a lot of other usage details).
OK. Let me see if I can explain to you in a way that will make it clear why you and the blogger are mistaken.
To be clear, I am the blogger. I wrote that blog post so I can reference it rather than having to type it, or even copy-paste it.
If I get the data for username or biometric, I can feed it back in to the front end and gain access.
Stop right there. The username, certainly. You just type it. The biometric... how exactly do you go about feeding it in the front end? Seriously, stop for a moment and think about what you'd have to do? What obstacles must you overcome in order to do it? And have you ever actually tried to to do? If so, how hard was it?
Those obstacles are the the security of biometric authentication. It's exactly as strong -- or weak -- as those obstacles, so if you want to understand the strength or weakness of a biometric authentication system, those are what you must analyze. I did high-level analyses of biometric authentication for smartphones and credit cards in the blog post. Do you have any specific counterarguments to my analyses?
You're accustomed to assuming that authentication can only be done by verifying a secret. But that's clearly false. How do you authenticate your mother or your wife before handing them your car keys? Do you ask a series of questions only they will know the answers to? Obviously not. You authenticate (and identify; the two can be done in a single step given a small database) them biometrically, by observing characteristics of their faces and bodies. The human brain is extremely good at this. Computers can theoretically do the same, though current-generation single-factor biometrics are very far from as good as the brain. Not uselessly far, though. There are plenty of contexts in which they are perfectly adequate.
[Much irrelevant maundering about hashing elided. Note that hashing is also not essential to the security model for passwords; it is a mitigation technique used to reduce the impact of penetration of the password store. Oh, and if done properly, rainbow tables are irrelevant, though brute force is still almost trivial given modern computation capabilities. Not that it's impossible to choose truly high-entropy passwords, but basically no one does it.]
The average user wouldn't be rooting their phone, so the average user wouldn't need to verify any signature.
Back to topic, if a user needs to verify that the app isn't malware, all they need to do is
a. officially install it on another phone, backup the apk and install it on the rooted phone
b. unroot the phone, install the app and re-root the phone
Obviously we're speaking of the average person who roots their phone... and the average rooter will not know they even need to bother with this. We're not talking about the people who post the how-to's on XDA, we're talking about the much larger number of people who read them and follow them step by step, and are baffled and stopped in their tracks if anything doesn't work as expected.
The average rooter will download the APK from some random web site, just as the AC up-thread did. They will not use Java keytool to verify the signature and to extract the signing certificate and verify that it's the one used by Netflix. This is how malware spreads in the Android ecosystem.
The article says businesses are moving towards biometric authentication, which is good as long as it's done correctly, not that they're trying to regard biometrics as secrets.
You didn't actually read the blog post. If you had, you'd have noticed that I covered that quite thoroughly, pointing out the major ways the sensor is and is not secure. Bottom line, it's context-dependent. Password security is also context-dependent. In either case, you have to understand the problem you're trying to solve in order to say whether or not a given solution addresses it adequately.
I agree fingerprints are not very good usernames. I personally wouldn't use biometrics for anything. However, the article you link to has many flaws. Lots of false arguments. Since it's a long article, going into all the details takes more time than I have right now. Maybe later.
Since I've been doing biometric security for nearly 20 years, as my day job, I'd be very interested in exactly what "flaws" you think you find in my arguments. I suspect that it's your counterarguments which are flawed. Oh, I suppose there are nits you can pick -- I could point out a bunch of those myself -- but nothing more.
But I still don't know: if biometrics are neither user id's nor passwords, then what are they?
They're authenticators. Given a user's identity (e.g. username), plus a scan of a body part of the person trying to log in with that username, you can have a pretty solid idea of whether the person trying to log in is the person associated with the username. In that way it's much like a password... but the security model is entirely different, since the security derives from the difficulty of fooling the scanner into accepting a fake body part, rather than from the difficulty of obtaining or guessing a password.
Login name + password is authentication. Biometric + password is authentication.
No, username + biometric is authentication, same as username + password (but with different security properties). Login + biometric + password is stronger authentication. Biometric + password is... bizarre and probably bad. In a database of any size, the biometric will match multiple people, so the system will have to test the password against all of the matching accounts.
Exactly. It's like having your users write their passwords on a post-it note, and stick it on the foreheads rather than their monitors.
No, it's not. At all. Post-it notes on foreheads would be completely insecure. Biometric security can actually be quite good, even though the biometric data is public.
Thanks for this. I'm in the same boat. We switched several year ago and the impact on collaboration and ease of logins and access to student and teacher work has been so positive. That doesn't even get into tools like Google classroom.
As a parent, I also like how easy it makes it for my kids to share their assignments with me. Especially on high school papers, it's great that they can say "Dad, I shared my essay, can you take a look at it?". I always just add comments rather than editing, except in trivial cases where I put my edits in as suggestions. The kid addresses my feedback, then shares it with the teacher, who, if they want, can see the edit history and tell me if I'm helping too much (none ever has, even when I point it out to them at parent-teacher conferences). Then I can see the teacher's comments after they've graded it (which often makes me want to argue with them, but I don't).
That could all be done by emailing documents around, but it's so much smoother to have a single shared doc.
It's totally reasonable for a single relatively low-skilled I/T person (or even a sophisticated teacher or two) to manage a fleet of several hundred Chromebooks. If one of them breaks, there's no worry about trying to recover data; it's all in the cloud. Hand the kid another Chromebook (possibly after making the parents pay for it, depending on how it was damaged). There's no way for students to misconfigure them. There's no need to worry about security, they're highly secure and update automatically.
The Open Source release could simply be a requirement for copyright protection.
IMO, there should be no copyright protection on binary-only releases. If there are such secrets in your source code that you don't want to publish it, you should use contract and trade secret law to protect your product. If you want copyright protection, you should have to publish the source code so that it's truly usable when it eventually falls into the public domain. That doesn't mean that you have to give anyone legal rights to redistribute, modify, create derivative works, etc. -- you can still reserve all rights, but people can read the code, and they can do whatever they like with it when the copyright expires (granted, that's essentially forever in software terms, but it's the principle of the thing).
If that were the law of the land, it seems very easy to tie support to it: If you stop supporting your product, you don't lose copyright protection entirely, but you must give your licensed customers the right to create derivative works to fix security vulnerabilities, or to hire a third party to do it. We could even maintain the restriction on the creation of derivative works for any purpose other than fixing vulnerabilities... customers still could not add features or modify in other ways; they could only perform minimal changes to address security problems.
Cite? Actually, this statement is pretty easy to disprove. The Taliban are not Wahabbi, they're Deobandi, and yet they clearly do commit acts of terrorism. I don't think ISIS is all Wahabbi, either, unless you consider Salafism and Wahabbism to be the same thing.
It will be much worse then that, since you cannot create a reliable hash from biometric data (since the biometric changes slightly from time to time) every off-line attack against a leaked database will be an instant reveal of all "passwords" since all of them will be your password=@password scheme.
Irrelevant, because biometrics aren't secret to begin with.
Slashdot Mirror
I have nightmares of them going with two USB-C ports.
USB-C is awesome, though only two ports would be insufficient. Four like the MBP has would be good, and they're small enough it should create no issues, especially since you no longer need the thunderbolt or power ports.
going Retina
Why would you not want a higher-resolution screen? It makes everything much smoother and nicer looking.
Just don't fuck with the mag-jack
I prefer USB-C for power, though there are some downsides. The main one is the lack of a light to show charge status. I don't miss the mag jack. It always seemed like a clever idea, but it's way too easy to accidentally disconnect.
keep the SD card slot in there
I do miss the SD slot in my MBP. I'll give you that one.
You're getting more than a little hyperbolic. Do you know any H1-B employees? They aren't tricked, they knew what they were doing and nearly all of them not only would but will do it again. There are problems with the system, sure, but wild claims like yours really don't help your case, they just encourage people to dismiss you out of hand.
To me it sounds like quite a few use biometrics as a combined username+password which makes things even worse. Here in Sweden we have a publicly traded company, Fingerprint Cards (https://www.fingerprints.com/), who pushes the idea of fingerprints as the secret key to payments and what not. Do watch their site, it's a good horror show! (you won't sleep well though).
I don't see any problems at all with what they're doing. They are not using the biometric as both identity and authentication. The chip card provides the identity (username), and the biometric authenticates that the correct person is the one holding the card. That is a proper use of biometric authentication which is strictly stronger than chip + signature and roughly as strong as chip + PIN (roughly because PINs and biometrics both have weaknesses, just different ones, so which is more secure depends on a lot of other usage details).
Oh. You are the same idiot.
Don't have any actual arguments, I see. Fine, I'll take that as your concession.
OK. Let me see if I can explain to you in a way that will make it clear why you and the blogger are mistaken.
To be clear, I am the blogger. I wrote that blog post so I can reference it rather than having to type it, or even copy-paste it.
If I get the data for username or biometric, I can feed it back in to the front end and gain access.
Stop right there. The username, certainly. You just type it. The biometric... how exactly do you go about feeding it in the front end? Seriously, stop for a moment and think about what you'd have to do? What obstacles must you overcome in order to do it? And have you ever actually tried to to do? If so, how hard was it?
Those obstacles are the the security of biometric authentication. It's exactly as strong -- or weak -- as those obstacles, so if you want to understand the strength or weakness of a biometric authentication system, those are what you must analyze. I did high-level analyses of biometric authentication for smartphones and credit cards in the blog post. Do you have any specific counterarguments to my analyses?
You're accustomed to assuming that authentication can only be done by verifying a secret. But that's clearly false. How do you authenticate your mother or your wife before handing them your car keys? Do you ask a series of questions only they will know the answers to? Obviously not. You authenticate (and identify; the two can be done in a single step given a small database) them biometrically, by observing characteristics of their faces and bodies. The human brain is extremely good at this. Computers can theoretically do the same, though current-generation single-factor biometrics are very far from as good as the brain. Not uselessly far, though. There are plenty of contexts in which they are perfectly adequate.
[Much irrelevant maundering about hashing elided. Note that hashing is also not essential to the security model for passwords; it is a mitigation technique used to reduce the impact of penetration of the password store. Oh, and if done properly, rainbow tables are irrelevant, though brute force is still almost trivial given modern computation capabilities. Not that it's impossible to choose truly high-entropy passwords, but basically no one does it.]
No. Username + Biometric is the same as username + username. Again, neither is auth.
No. You're wrong. Read my blog post, linked up-thread, for details.
Terrorist organization? That's novel. Care to explain your rationale for that term?
The average user wouldn't be rooting their phone, so the average user wouldn't need to verify any signature.
Back to topic, if a user needs to verify that the app isn't malware, all they need to do is a. officially install it on another phone, backup the apk and install it on the rooted phone b. unroot the phone, install the app and re-root the phone
Obviously we're speaking of the average person who roots their phone... and the average rooter will not know they even need to bother with this. We're not talking about the people who post the how-to's on XDA, we're talking about the much larger number of people who read them and follow them step by step, and are baffled and stopped in their tracks if anything doesn't work as expected.
The average rooter will download the APK from some random web site, just as the AC up-thread did. They will not use Java keytool to verify the signature and to extract the signing certificate and verify that it's the one used by Netflix. This is how malware spreads in the Android ecosystem.
I take it you didn't read TFA?
The article says businesses are moving towards biometric authentication, which is good as long as it's done correctly, not that they're trying to regard biometrics as secrets.
Ahh right, the "the sensor is secure" fallacy.
You didn't actually read the blog post. If you had, you'd have noticed that I covered that quite thoroughly, pointing out the major ways the sensor is and is not secure. Bottom line, it's context-dependent. Password security is also context-dependent. In either case, you have to understand the problem you're trying to solve in order to say whether or not a given solution addresses it adequately.
You are linking to a god damn blogspot post. FFS. Stfu
I'm linking to *my* blogspot post. I could have pasted the content here, but there's this nifty hyperlinking technology that's starting to take off...
I agree fingerprints are not very good usernames. I personally wouldn't use biometrics for anything. However, the article you link to has many flaws. Lots of false arguments. Since it's a long article, going into all the details takes more time than I have right now. Maybe later.
Since I've been doing biometric security for nearly 20 years, as my day job, I'd be very interested in exactly what "flaws" you think you find in my arguments. I suspect that it's your counterarguments which are flawed. Oh, I suppose there are nits you can pick -- I could point out a bunch of those myself -- but nothing more.
But I still don't know: if biometrics are neither user id's nor passwords, then what are they?
They're authenticators. Given a user's identity (e.g. username), plus a scan of a body part of the person trying to log in with that username, you can have a pretty solid idea of whether the person trying to log in is the person associated with the username. In that way it's much like a password... but the security model is entirely different, since the security derives from the difficulty of fooling the scanner into accepting a fake body part, rather than from the difficulty of obtaining or guessing a password.
Login name + password is authentication. Biometric + password is authentication.
No, username + biometric is authentication, same as username + password (but with different security properties). Login + biometric + password is stronger authentication. Biometric + password is... bizarre and probably bad. In a database of any size, the biometric will match multiple people, so the system will have to test the password against all of the matching accounts.
Exactly. It's like having your users write their passwords on a post-it note, and stick it on the foreheads rather than their monitors.
No, it's not. At all. Post-it notes on foreheads would be completely insecure. Biometric security can actually be quite good, even though the biometric data is public.
http://divegeekstuff.blogspot.com/2017/04/fingerprint-security.html
I agree. Unfortunately it's not "irrelevant" however since people/companies are trying to push biometrics in this direction.
For example?
Thanks for this. I'm in the same boat. We switched several year ago and the impact on collaboration and ease of logins and access to student and teacher work has been so positive. That doesn't even get into tools like Google classroom.
As a parent, I also like how easy it makes it for my kids to share their assignments with me. Especially on high school papers, it's great that they can say "Dad, I shared my essay, can you take a look at it?". I always just add comments rather than editing, except in trivial cases where I put my edits in as suggestions. The kid addresses my feedback, then shares it with the teacher, who, if they want, can see the edit history and tell me if I'm helping too much (none ever has, even when I point it out to them at parent-teacher conferences). Then I can see the teacher's comments after they've graded it (which often makes me want to argue with them, but I don't).
That could all be done by emailing documents around, but it's so much smoother to have a single shared doc.
Google won ON PRICE
And security, and manageability, and maintenance.
It's totally reasonable for a single relatively low-skilled I/T person (or even a sophisticated teacher or two) to manage a fleet of several hundred Chromebooks. If one of them breaks, there's no worry about trying to recover data; it's all in the cloud. Hand the kid another Chromebook (possibly after making the parents pay for it, depending on how it was damaged). There's no way for students to misconfigure them. There's no need to worry about security, they're highly secure and update automatically.
You know the answer to all three of your questions because the APK's signature should still be intact and verifiy as being signed by Netflix, Inc.
Uh huh, and how does the average user verify that signature?
A shit is a turd.
So... you're saying that every Muslim is a terrorist. What brilliant insight you have.
The Open Source release could simply be a requirement for copyright protection.
IMO, there should be no copyright protection on binary-only releases. If there are such secrets in your source code that you don't want to publish it, you should use contract and trade secret law to protect your product. If you want copyright protection, you should have to publish the source code so that it's truly usable when it eventually falls into the public domain. That doesn't mean that you have to give anyone legal rights to redistribute, modify, create derivative works, etc. -- you can still reserve all rights, but people can read the code, and they can do whatever they like with it when the copyright expires (granted, that's essentially forever in software terms, but it's the principle of the thing).
If that were the law of the land, it seems very easy to tie support to it: If you stop supporting your product, you don't lose copyright protection entirely, but you must give your licensed customers the right to create derivative works to fix security vulnerabilities, or to hire a third party to do it. We could even maintain the restriction on the creation of derivative works for any purpose other than fixing vulnerabilities... customers still could not add features or modify in other ways; they could only perform minimal changes to address security problems.
I was able to find an APK and install Netflix on my rooted phone in less than 5 minutes.
Does it contain malware? Do you know? How?
100% of "Muslim" terrorists are Wahabbi
Cite? Actually, this statement is pretty easy to disprove. The Taliban are not Wahabbi, they're Deobandi, and yet they clearly do commit acts of terrorism. I don't think ISIS is all Wahabbi, either, unless you consider Salafism and Wahabbism to be the same thing.
It will be much worse then that, since you cannot create a reliable hash from biometric data (since the biometric changes slightly from time to time) every off-line attack against a leaked database will be an instant reveal of all "passwords" since all of them will be your password=@password scheme.
Irrelevant, because biometrics aren't secret to begin with.
Biometrics aren't passwords, they are user IDs.
They're neither. http://divegeekstuff.blogspot....