Tag: security

Apparently, Google’s face unlock on Pixel 4 can allow access to a user even if he has his eyes closed. This comes around the same time when a critical bug was detected in the fingerprint unlock on Samsung’s Galaxy S10 devices.

Both the companies put out a completely tone-deaf first response. Samsung, naively, suggested using their authorised” accessories. Google, on the other hand, reiterated that theirs is a strong biometric” solution.

I am really surprised by this callous attitude towards the user’s security on the devices.

Google preferred to focus on the gimmicks in Project Soli rather than strengthening the face unlock first. They felt a need to differentiate their face unlock feature from iPhone’s. Samsung felt the need to go with a different mechanism of the ultrasonic in-screen fingerprint reader. All others use optical ones.

This need to differentiate for the sake of differentiation is laughable.

A tweet from Rene Ritchie sums it nicely.

If we’ve learned anything over the last couple of days it’s that good biometrics take a lot of consideration.

Smartphones have become critical for many in their day-to-day use-cases, from identity to banking. And the inbuilt biometric solutions are increasingly being depended on to validate that identity. So the OEMs can’t afford a misstep with these solutions.

I hope the smartphone makers realize they can’t deal indifferently with the security of the devices.

Why CAPTCHAs have gotten so difficult

So apparently we, humans, are struggling to prove ourselves as human now – The Verge reports.

Figuring out how to fix those blurry image quizzes quickly takes you into philosophical territory: what is the universal human quality that can be demonstrated to a machine, but that no machine can mimic? What is it to be human?

I am sorry, but we are taking the literal definition of CAPTCHA – Completely Automated Public Turing test to tell Computers and Humans Apart – too seriously. It is a good enough system to filter out attacks from majority of the bad actors not so strong both technically and financially. Sure, there would come a day when the AI systems to beat these complicated CAPTHAs would become extremely cheap — might be even sold pay-per-use.

But when that happens, we better be ready with something that can replace this old system of identifying humans online. Authenticating and authorizing an identity online should be made a priority project at all the technology leaders.

Passwords are, still, mess

Some time back, I read this interesting post at xkcd, a usual for these guys.

It made me realise, for the zillionth time, passwords are mess. This medium of authenticating a valid, and a human, user has overstayed its welcome. The way it is being used is not secure. Well, can you blame the poor souls who are made to remember the crazy letters every time they want to get something done online? Moreover, they are forced, as a security policy, to change and then remember the new passwords every some time. Sigh! Indeed, passwords are mess.

You need more proof? Try searching for the phrase “passwords should die”. This farce has to be one of the most cursed phenomenon out there.

But then what are the options?

  1. Make browsers/OS’es handle the password generation and management: This is one of the oldest and most recommended solution for this issue. The problem is such machine generated passwords are usually random Strings; hence they are extremely hard to memorise. Good password managers can negate that need. However, they become a hinderance in an environment where there are multiple machines involved (for example, work vs home environment). Moreover, the security aspect of these are hotly debated topics.
  2. Recommend ways for easy to remember, difficult to break passwords: An option that is evaluated a lot these days. The xkcd post linked above recommended one such way. It also opened a lot of threads discussing and analysing the accuracy and feasibility of the same. There were articles and papers written on understanding and improving on the suggested way. The problem is, eventually, it is a human, the lazy ass, who will decide what the password would be. What would end up happening is instead of ”password1” being a common password, it would be ”mypasswodiscommon”.
  3. Go Biometric: Apple introduced a working and, debatably, secure implementation of biometric authentication in TouchId. By bundling it as a core feature of iPhone, Apple made it reach to the masses. Tons of articles were written detailing how it can solve the password problem altogether. Though possible, issue remains this would not happen until biometric authentication comes bundled across all technology devices, even the low-end mobile phones. Passwords remain the standard, and only acceptable authentication method till then.
  4. Make passwords die, altogether: Finally, we come to the most interesting option that can be driven by the application developers themselves and not the users of the application. I feel, this will eventually become a reality.

Password-less Authentication

A lot has been said on this front too. There are articles and even open source frameworks, like Passwordless that want to target this by providing application developers ways to replace their login forms with password-less access. At high-level, key steps involved to achieve this are

  • Make a user just mention his userid/email address
  • Generate a one-time token for him
  • Deliver it to him
  • Authenticate him with the generated token

These are pretty standard and well accepted steps. However the issue remains in the 3rd step, how should these tokens be delivered. Whichever mechanism one selects will become the single point of threat to the whole system going haywire, be it then email (what’s the password for email account then?) or SMS (phone is lost, what now?). The hacker news thread on one such suggested system is nice rundown for the probable issues.

Now that thread is more than a couple of years old. Today, the best option would be to deliver the token to the device which has biometric authentication enabled. As an example, I really like the way Apple has enabled the two-factor authentication on Apple Id. It displays possible devices where the token can be delivered and asks the user to select one. Once delivered to, say, an iPhone, only the user who owns the iPhone can access it by authenticating himself with TouchId. This same mechanism can be applied for delivering the secure tokens of web/mobile applications too. There, the delivery problem is solved.

However, given that majority of the users do not own an iPhone or a similar biometric authentication enabled device, this method cannot become the primary way of authenticating users.

So even though I believe that, in John Siracusa’ words, on an infinite timescale, all applications will have password-less logins, we are some years away from realising that dream.


Ok, so what till then? This is what I would like the applications developers to do to make this password mess a bit less itchy for me. Decide first, do you really need me to secure my profile via a password? User forums/discussion groups, I am looking at you. I will give leeway to banks/financial apps to make me remember and enter the password. For all others, please make this process simple.

  1. When a user visits the first time, ask for his email id/mobile number. Next, make him choose a word, an image or, preferably, a set of words/images to remember as “password”.
  2. For every subsequent visit, just ask him for the email id or mobile number. Even better, just do not ask him anything. Maintain his profile information in cookie with expiration set for a longer timeframe.
  3. Give him the options amongst which lies his password and make him “select”, not enter, that as the password. He gets a couple of chances, else make him fall back to one-time token.
  4. If he does not remember the chosen password, or chooses not to, a click on a link sends him a token on email/mobile which he used while registering.

I believe this will ease the burden from majority of the people of maintaining the passwords without making them any less secure. Passwords can’t die yet, but at least they would be a little less painful.