To Password or Not To Password

Authentication: Why?

Businesses are dealing with large volumes of private, sensitive data (e.g. employee or customer’s personal data) on a daily basis. At the same time, they are also fighting malicious and deliberate attempts to breach their information systems. No enterprise is immune to hackers, and how they address this growing need will have a significant impact on their company. Former Cisco CEO John Chambers once said, “There are two types of companies: those that have been hacked, and those who don’t yet know they have been hacked.

Source: The Northrop Grumman Fan
  • Perimeter: Honeywell, Bosch Security Systems
  • Network: Palo Alto Networks, Fortinet
  • Endpoint: McAfee, Symantec, Cylance, CrowdStrike
  • Application: Veracode, Checkmarx, Qualys
  • Data/IAM: Okta, Duo, Auth0, BeyondTrust
Source: Experian, 3/11/2019

Authentication: How?

Authentication determines who/what can access a system, how they can access a system, and which data they have access to, by verifying information provided based on stored credentials.

Password-based Authentication

The Username/Password approach is the most common way to authenticate a user, but it is also proven to be very insecure. According to the Verizon Data Breach Investigation Report (DBIR), “81% of hacking-related breaches leveraged either stolen and/or weak passwords.” It’s very common for individuals to use the same password for both personal use as well as work related applications. According to PixelPrivacy.com, “Millennials aged 18–31 lead the lame password category parade, with 87% admitting they frequently reuse passwords despite knowing better. 60 million Dropbox’s user credentials are stolen and available for sale on the Dark Web because of employee password reuse.

You could watch the clip here: https://www.youtube.com/watch?v=L4Xmud9iX3w

Password Hashing

Hashing is a type of algorithm which takes any size of data and converts it into a fixed-length of data. Theoretically speaking, hashing algorithms have the following properties.

  • Resist to collision: two different messages should generate two different hashes; m and m’ are two distinct messages, hence hash (m) <> hash (m’)
  • Difficult to reengineer: given a hash h, it should be difficult to find a message m that hash (m) = h
  • SHA-256: convert into a 256-bit hash, 64 hexadecimal characters
  • SHA-512: convert into a 512-bit hash, 128 hexadecimal characters

Hashing can also be cracked!

Reverse engineering hashes is not easy but is doable via brute forcing, i.e. to try all the possible inputs until the right one is found. Proof-of-work in bitcoin mining adopts this concept. Mining a block requires the miner to produce a value (aka nonce) that, after being hashed, is less than or equal to one used in the most recent block accepted by the Bitcoin network. The number is between 0 and 256-bit, and miners have to use hard-core GPU/FPGA/ASIC hardware to stay competitive in this brute force competition.

Hashing with Salts

Salt is another layer added to the password protection. Let’s use Big Head’s credential again.

Password-based Authentication: ZKP comes to the rescue!

The centralized password database seems to be the problem with password-based authentication, because it enables many passwords to be accessed in one fell swoop if a system is compromised. Is there a way to eliminate that centralized database but still use password as a primary way to authenticate users? There is, Zero Knowledge Proof (ZKP).

Passwordless Management: Distributed Authentication

We understand the caveats of the centralized password-based authentication approach. Developers have come up with an approach to make authentication passwordless by incorporating a user’s mobile phone and biometric authentication. This approach is passwordless by default, which is different from the traditional 2FA or MFA approach where password and centralized password management are still needed.

Passwordless is a fictional passwordless authentication vendor 😜

Passwordless Management: Decentralized Blockchain-based Authentication

Decentralized blockchain-based (or onchain) authentication is to distribute the authentication work to nodes/verifiers in the blockchain network by comparing fresh biometric samples submitted by users from any device with the users’ biometric templates stored onchain. Let’s start with how it works from a user’s perspective.

AuthChain is a fictional decentralized authentication protocol with a front-end interface 😜
StorageChain is fictional decentralized storage on blockchain 😜

Enabler A: Randomness

Verifiers should be randomly assigned for each transaction to ensure decentralization and security. In our case, if this is a permissioned network and we have a few nodes dedicated to serving Dropbox’s authentication requests, this protocol is not necessarily far more superior than the centralized one where authentication is performed by one centralized node. From a security perspective, it’s actually worse than the device-dependent passwordless approach, whereas the authentication is fully distributed to the edge. The designated nodes could easily become targets for adversaries.

The Blockchain Trilemma

Enabler B: Privacy-First Protocol

Mainstream protocols like Bitcoin and Ethereum are not built for privacy-preserving smart contracts. People would argue Bitcoin/Ethereum is anonymous because users can transact bitcoins/ethers on chain with no personal information required. However, it’s not anonymous. It’s pseudonymous, as every transaction is linked to two specific addresses, a sender’s address and a receiver’s address. Transaction details including amount and time are recorded and revealed onchain. Given how sensitive users’ biometric data is, an open decentralized blockchain protocol is clearly not a viable choice for authentication. The mathematical representations of users’ face and fingerprints should not be made publicly available on the blockchain.

Enabling C: Decentralized Storage

Beyond privacy-preserving, the blockchain network needs storage to hold users’ biometric templates to perform verification. How does storage work on blockchain? The mainstream network such as Bitcoin requires every full Bitcoin Core node download/store the entire ledger of onchain transactions. Bitcoin transaction data is pseudonymous by nature, so it is reasonable for every full node to have the full copy.

Conclusion

We live in a world dominated by password-based authentication, and we have seen risks and incidents associated with that approach. We discussed the dominant approach and a couple of its alternatives. A quick rundown on pros and cons:

  • Make sure customer/employee passwords are stored in hashes with salts
  • Implement 2-step user authentication: Once hackers gain access to the active directory, it’s just a matter of time before they crack some user accounts and passwords, especially the ones using common words and phrases. 2-step verification adds another level of security. Big Head’s account could be easily hacked. If he receives a text code to access his account, and he wasn’t the one asking for it, he’d know someone is trying to access his account without his permission. He could immediately log in and change his password, hopefully not password as password this time.😉
  • Keep personal and professional passwords separate: Dropbox’s incident where 60M+ user accounts were breached happened due to an employee password reuse. Hackers gained access to that employee’s password from the previous LinkedIn breach. As we cannot be sure every product/service is implementing a strong authentication protocol, we should at least separate work-related passwords from personal passwords to contain the damage.
  • Stay open-minded about the ZKP and passwordless based authentication approaches as the fundamental technology continues to evolve and mature

Approach go-to-market in the Enterprise space with patience

  • The current market might be hard to crack at this point as passwordless is quite disruptive to the existing centralized password management; there are also alternatives such as to shore up their network, endpoint and cloud security to protect their active directory from being hacked.
  • Some enterprises might be willing to do pilots for specific use cases with limited deployment; use them as your design partners to iterate on the product and to build credibility.
  • Build partnerships with existing IAM vendors. Secret Double Octopus, the password-free enterprise authentication vendor, recently announced a partnership with Okta. As part of the joint solution, Secret Double Octopus complements Okta’s solution by providing passwordless access to all enterprise’s services and applications.
  • SMBs are more likely to become early adopters as passwordless management is theoretically secure and simple to manage (the actual authentication is distributed to users’ devices at the edge).
  • Need to come up with a solution or back-up plan for edge cases like phone stolen/lost/broken
  • This approach requires a lot of evangelism to educate the market at the early stage. Make sure you have a talented, creative product marketer. 😄
  • Hats off to all of you that are involved in this Web 3.0 initiative that is to bring the Internet back to what it was supposed to be — to assure the open development, evolution and use of the internet for the benefit of all people throughout the world — and to return privacy and control to users.
  • Authentication is very likely to be tackled via Decentralized Identity (DID), a much broader initiative that enables users to own their own identity, control and protect their information, and share their information with entities that request it without being dependent on centralized third parties such as governments and banks.
  • The enabling technologies such as privacy methodologies, consensus, decentralized network and decentralized storage are critical to the development of Web 3.0 (aka decentralized web), and the front end of authentication or DID would sit on the application layer among many other decentralized applications.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store