Thursday, April 26, 2018

Biometric Authentication

Biometrics are being pegged as the next big deal for user authentication, esp. within the banking & financial sectors. Been having a few discussions to understand how good biometric authentication are as compared to traditional Pins? Is a return to being angootha-chaaps (thumb-print based) for all purposes the right thing to do, technically that is? Here's a lay-man attempt at answering some of those questions.

Staring off by calling out known facts & assumptions about thumb-prints (an example biometric): 

  • Thumb-prints are globally unique to every human being.
    (Counter: Enough people who don't have/ lose a thumb, or lose their thumb-prints due to some other reason. Also partial thumb-prints of two individuals taken of a portion of the thumb due to faults at the time of scanning, etc. may match.)
  • Thumb-prints stay consistent over the lifetime of an individual (adult).
    (Counter: May not be true due to physical changes in the human body, external injuries, growths, etc.)
  • Computers are basically binary machines. So whether it's a document (pdf, doc), an image file (jpg, gif, etc.), a video (mp4), a music file (wav), a Java program, a Linux operating system, etc. all of the data, instructions, etc. get encoded into a string of bytes (of 0s & 1s).
  • The thumb-print scan of an individual is similar to an image file (following a standard protocol), encoded as a string of bytes.
    The thumb-prints scans of two different individuals will result in two different strings of bytes, that are unique to the individual.
    Subsequent scans of the thumb-print of the same individual will result in exactly the same string of bytes over-time.

That's enough background information for a rough evaluation. A thumb-print scan of a certain size, say 10Kb is just a string of 10,000 bits of 0s & 1s. This is unique to an individual & stays the same over the individual's lifetime.

A 4-digit Pin on the other hand is a combination of four Integer numbers. Each Integer typically gets encoded into a 32-bit string. A 4-digit Pin is therefore a 4 * 32-bit = 128-bit string. The Pin normally stays the same, unless explicitly changed (rather infrequent).

In simplistic terms, when a request to authenticate an individual is made to a computer, it reads the incoming string of bits (from the Pin or the thumb-print) & matches it against a database of known/ all existing (1-to-1 or 1-to-N matches) strings. To the computer other than the difference in length between the two encoded strings of thumb-print (10,000-bit) & Pin (128-bit), there's not much difference between the two.

On the other hand, the Pin seems much better than the thumb-print if it were ever to get compromised due to a breach or a malicious app or something. The Pin can simply be changed & a new 128-bit string can replace the earlier one going forward. But in the case of the thumb-print there's really nothing that can be done as the individual's thumb-print scan will stay the same over time!

Yet another alternative for authentication is to use One Time Password (OTP). The OTP is also a 4-digit number (128-bit string) but it is re-issued each time over a separate out-of-band channel (such as SMS), is short lived, & is valid for just one use. These features make the OTP way more robust & immune to breaches & compromise.

What is a biometric to the human being, is just another string of bits to the machine, very similar to the string of bits of a Pin or an OTP. From the stand-point of safety though, the OTP is far superior to the other two. As is the common practice, it maybe ok to use biometric authentication within environments such as government offices, airports, etc. where the network is tightly regulated & monitored. For end-user authentication however, such as within phone apps, or internet payments, or other channels where the network or device is orders of magnitude more insecure & vulnerable these are not ideal. In general OTPs should be the top pick & biometrics the last option in such cases:

    OTP > Pin > Biometrics

Monday, April 9, 2018

Learning Deep

Head out straight to KdNugget's Top 20 Deep Learning Papers of 2018. Has a good listing of research publications spanning over the last 4-5 years. You could further go on to read the papers referred to within these papers & then those referred to in the referred papers & so on for some really deep learning!

Sunday, April 8, 2018

Application Security & OWASP

Lots of applications get developed these days to make the life of customers easy & comfortable. However, a cause for concern is the general lack of awareness of security aspects among app developers. As a result unsafe & buggy apps get released to production by the dozens.

Have come across quite a few such apps in recent times & duly reported them to the respective support/ dev teams. While some of these will get fixed, there does appear to be a lack of knowledge of security issues among the  teams. Had they known they would have mostly got it right upfront. Retrospective patching while common for newly discovered vulnerabilities, is no substitute for incorporating current standards & best practices that are well researched & documented.

OWASP is one of the leading open standards on security vulnerabilities. OWASP Top-10 Application Security Risks (latest: 2017) include things like Injection, Broken Authentication, Sensitive Data Exposure, etc. There's a whole bunch of material available online including an e-book with details & fixes for the vulnerabilities for the different stake-holders of the app. These are like the safety-belts that must be incorporated in all apps before allowing them to go-live.

Another major cause for widespread security issues in apps is the use of vulnerable frameworks & third party libraries by them. Buggy Javascript (JS) libraries are particularly guilty of pushing vulnerabilities down to apps. 

As per the Northeastern University research of outdated Javascript libraries on the web, of 133K websites evaluated 37% included at least one vulnerable library:
  - "not only website administrators, but also the dynamic architecture and developers of third-party services are to blame for the Web’s poor state of library management"
  - "libraries included transitively, or via ad and tracking code, are more likely to be vulnerable"

RetireJS initiative keeps a tab on the vulnerabilities in the JS libraries. As do the OWASP cheat sheets on 3rd Party JS & AJAX Security. Static analysers, security testing, sand-boxed executions, etc. are typical ways to address client side JS security vulnerabilities.

Security issues are equally widespread in frameworks & libraries from other languages. Java & Scala are fairly well covered by OWASP (though .Net, Php, etc. aren't). Evaluations of Java Spring framework against OWASP Top-10, listing of Java security framework, hdiv & Scala Frameworks provide context on how best to address security issues in some very popular frameworks.