Thursday, February 27, 2020

"Hi, This is Google."

One-Time Passwords are the go-to solution for second factor authentication, and while they come in different variations, they all essentially do the same thing – prove “what you have”. The different variations include SMS based OTPs, hardware-based tokens and soft tokens that utilize an existing piece of hardware, such as a smartphone.

Two-factor authentication is typically required and enforced by regulatory bodies, when dealing with financial transactions or with extremely sensitive data. PSD2 for instance, is a regulation meant to promote competition in the European banking industry by requiring financial service providers to open their APIs to “regulated 3rd parties”. These regulated 3rd parties are required to enforce two-factor authentication when providing access to their end users, when accessing their financial information.

Each of the different variations of the OTP has its own pros and cons, but they all share one commonality – they require you, the consumer, to carry something. From a security point of view, should the item fall into the wrong hands, this paves the way to account takeover by a malicious party.

The image below shows a quite original crook, using chopsticks to pickpocket unsuspecting victims.

The Good
Let’s start with the user experience – OTPs remove the need to memorize passwords, although they are typically coupled with another “memory-based” factor such as username and password. OTPs also provide relatively good protection vs. replay attacks, since the one-time code or token can only be used within a limited time span, unlike passwords which are static and in the best case, are replaced every 2-3 months.

Perhaps the biggest advantage of SMS based OTPs is that they work on any device, and believe or not, some populations still use just “phones” as oppose to smartphones.

Fun Fact: Some Jewish Orthodox populations actually require a “Kosher” stamp on phones that they use. For some Jewish communities, “smartphones” in general are not considered Kosher, therefore they are required to non-smartphones, which can only use SMS to deliver the OTP.

The Bad
The downside is that the user needs to carry something physical – a device with the relevant SIM card, a token, or a registered device with a soft token.

A true story – someone once shared with me that they were abroad and had to access their bank account to do an urgent transaction. Surprise-surprise, they forgot their password and had to go through the tedious “recovery” process. However, since they were abroad, they could not receive SMSs (some banks restrict sending SMSs if the person is in a foreign country, for security reasons) and could not recover their password. In order to change their registered number to the temporary local number, they needed their password. Quite the conundrum. Eventually they had to call the helpdesk and waste precious time.

Aside from the usability limitations, SMS OTPs suffer from an inherent security flaw – the SS7 protocol used to send SMS has been declared by NIST and other standardization bodies to be insecure and unfit to be used for 2FA. In this case, hard tokens fare better from the security perspective, but who wants to carry a token with them at all times?

Social engineering is another phenomenon that has been the root cause for widespread fraud in the financial industry. It usually goes something like this: Hackers pull up a phony web site that is used to amass username, passwords and other personal details from unsuspecting individuals. The malicious actor then uses the credentials in an attempt to gain access to the targeted accounts. Once prompted with the 2-factor authentication request, they place a specifically timed call to the targeted user and impersonate as one of the bank’s employees, usually claiming they need to check something with the system and ask for the OTP that was just sent to the user. People are compliant by nature and most users would gladly hand over their OTP on a silver platter, allowing the hacker to circumvent the 2FA and gain access to their account.

This attack has several variations, including sending an SMS stating that someone attempted to access the account from an unknown location and in order to properly secure the account, the user should reply with the code that they will soon receive. After sending this message to the victim, the hacker inputs the credentials and is prompted with the 2FA, that is bypassed using the OTP they just received.

Another real-life example I came across - one of my acquaintances was robbed. The thief snuck in, in the middle of the night and grabbed the victim's bag with all the personal belongings including smartphone, credit cards and ID documents. Using the credit card PIN recovery feature via SMS, the crooks managed to withdraw thousands of dollars from the victim's bank account. Now you may be thinking, “I lock my phone, so I’m good”. Well, the devil is in the details – in this particular case the SMSs were actually visible, even when the phone was locked. This is to allow for quick viewing of incoming messages, but a terrible idea from a security perspective.

So, what can you do? First of all, change your smartphone’s settings, so that SMS cannot be viewed when the device is locked. Secondly, make sure you follow best practices in regard to "phishy" websites and social engineering via phone calls, as well as training your staff accordingly.

The Ugly
Exploiting SS7 vulnerabilities is frighteningly simple, just check out this short YouTube video that demonstrates how easily it can be done:
In 2011, an attack was conducted on RSA’s servers that supposedly exposed information that could enable malicious actors to circumvent RSA's token mechanism. Read about it here:

Several months back, a group of Chinese hackers launched an attack targeting government entities and managed service providers, using a combination of web server vulnerability exploitation and lateral movement techniques. But the more interesting part of the attack, was related to the way they managed to generate valid RSA software tokens.
Read more about this attack here:

How can Verifyoo help you?
First and foremost, Verifyoo DrawID incorporates two factors in a single solution: The possession factor (device) and the inherent factor (user behavior). Therefore, replacing SMS OTPs or tokens with DrawID can immediately ramp up the security posture and fraud resilience. Secondly, Verifyoo utilizes the push notification infrastructure to initiate the 2FA process, which is much more secure compared to the SS7 protocol. Lastly, using an existing infrastructure without SMSs, means that organizations can cut down costs associated with sending out masses of SMSs, that in some cases are received in a delay or not received at all when the cellular reception is unstable.

For more information visit:
To schedule a demo:

Monday, February 17, 2020

Introduction to Pa$$w0rds

When people hear the word "password", the first thing that comes to their mind is the pesky, hard to memorize code they are required to enter when accessing their online accounts. The truth is that passwords have been around for centuries, long before the first computers were introduced in the 1930s and 1940s (remember "I think there is a world market for maybe five computers"? Well, think again! But I digress).

Passwords were used in the Roman Military by sentries as a method of access control to restricted areas, challenge-response phrases were used by the American 101st Airborne Division in World War II by presenting a challenge "flash" with the desired response being "thunder".
In 1961 Fernando Corbató, an MIT Professor, first implemented the password in a computer system called Compatible Time-Sharing System (CTSS) which was an operating system used by researchers. In the 1970s Robert Morris first implemented the passwords hashing mechanism as part of the UNIX operating system.

In the mid-1990s when the internet started taking off, passwords became an integral part of our day-to-day, online life. Despite global efforts that include the largest tech giants (e.g., FIDO Alliance), passwords are still the most common method of online access control.

The good

Although extremely outdated, passwords have one significant advantage – they can be used almost from any device, assuming a physical or virtual keyboard is present. Technologies such as one-time passwords, tokens or fingerprint provide a much better user experience, but they still require the device to be present for the verification to take place.
Another important upside of passwords is preserving user privacy, since passwords are not considered Personal Identifiable Information (PII) they can be stored in the cloud or on-prem, assuming proper security measures are taken such as hashing and salting.

Assuming we are the type of people that "look at the full half of glass", password sharing can be considered a good thing in some cases, for example if you need to grant your spouse access to your email or bank account. Although in general, it is best to grant access in such cases beforehand using proper authorization mechanisms, that grant multiple users access to a single account or resource.

The bad

Where should we begin? Generally speaking, passwords are a lose-lose situation both for the enterprise as well as for the end users. This includes but is not limited to poor security, poor user experience and a high operating and maintenance cost.
Security wise, passwords suffer from a multitude of attack vectors that in most cases, can be mitigated by sticking to security best practices and proper employee training.

Data leakage: There are many different reasons why hackers gain access to restricted data - from unpatched vulnerabilities in the OS, to misconfigured cloud instances. Eventually someone bad will get to our data so we need to make sure we follow security best practices. With passwords this usually means hashing, since passwords should never be stored as plain text. But hashing alone is not enough, as it opens up the hashed passwords to a "rainbow-table" attack, that basically uses a precomputed table for reversing hashes. Therefore, hashing should always be done using a "salting" mechanism, by adding a random piece of text to the password and only then hashing it. By doing so, it will significantly increase the effort required to crafting an attack at scale, when exploiting the hashed passwords that were harvested.

Phishing websites: An extremely common attack vector, typically done by sending a link and redirecting the user to a "fake" website, that in most cases looks identical to the naked eye. The unsuspecting user inputs their credentials and poof… Their username and password are suddenly for sale on the dark web, for a dime-a-dozen. There a many elaborate and highly sophisticated tools to handle these attacks, from automatically taking down these websites to tools based on computer-vision that distinguish between a real and fake website. But in many cases, nothing beats the good old employee training and guidance, which are an integral part of the anti-phishing arsenal. Now you might say something like, "But hey, I got 2FA, I'm safe!". Well guess again, especially if you're using SMS OTPs. More on that on the next chapters.
Weak and re-used passwords: Some websites go to such great lengths with the password complexity requirements, that it can take several minutes just to come up with a password, let alone memorize it without writing it down. Eventually we are humans and we were not programmed to memorize random letters, which is why most users use easy to memorize passwords and also re-use them across accounts. Now, I feel pretty comfortable with Google safeguarding my password using proper salting etc., (should I?) But what about that questionable eCommerce website I signed up to, using the same password? It just so happens that they did not properly configure their cloud's security settings and forgot to "spice" up their passwords. You get the picture. In other cases, people use easy to remember passwords, the three most common passwords are: “qwerty”, “password” and “111111”. This opens them up to dictionary attacks, which is essentially a database containing a predetermined set of commonly used passwords.

So, what can you? Don't re-use passwords, require your users to generate complex passwords and don't forget to turn on 2FA!

Setting aside security, passwords also fall short in user-experience and can lead to lost business and transaction abandonment by frustrated users that are required to manage numerous accounts. Eventually these users will have to go through the tedious "account recovery" process that is also extremely insecure. As the cherry on top, add the high operating costs of managing and resetting passwords -  a Forrester research estimates that the average cost of a single password reset done by help desk is about $70, while Gartner estimates that 20% to 50% of all help desk calls are for password resets.

The ugly

A recent phishing campaign targeting Apple, redirected users to a phony website that mimics Apple's account management platform, in an attempt to harvest credentials. Another recent phishing campaign is targeting the UK, in an attempt to execute mass credential harvesting.

In 2012, reports stated that 6.46 million hashed passwords of LinkedIn accounts leaked online, and you guessed it, they were "unsalted".

Another notable data leakage was 7 million compromised Minecraft accounts, that were also "unsalted". Before you start thinking, "What's the worst thing that can happen with hijacked Minecraft accounts?", consider the fact that some of these passwords may have been re-used in additional accounts.

To sum it up, according to the Verizon Data Breach Investigations Report, 81% of breaches are related to weak or compromised passwords.

How can Verifyoo help you?

Verifyoo's DrawID solution "eats the cake and keeps it whole" by keeping the main benefit of passwords without the weaknesses – enabling users to safely verify themselves from any device, without memorizing passwords. Aside from providing organizations and consumers a much more secure method of verification, Verifyoo also reduces the friction caused by forgotten passwords. Password friction not only leads to massive transaction abandonment by frustrated users, but also incurs high operating costs of resetting these passwords using frequent help-desk calls, knowledge-based questions and other means that have proven to be inefficient and insecure.

Read the next article in the series here:

For more information visit:
To schedule a demo:

Sunday, February 16, 2020

Passwords, biometrics and everything in between - Introduction

Online user verification has come a long way since 1961, when Fernando Corbató first introduced the password we have come to know and "love". The password was used by Corbató for providing researchers access to the in MIT - see illustration below.

In 2013 Apple released the iPhone 5s, that was actually not the first smartphone to feature a fingerprint sensor but was the first device that was widely acclaimed and brought biometrics to the masses. The rest of the device manufacturers were soon to follow and nowadays fingerprint sensors are abundantly featured in low and high-end devices alike.

In this blog series we will try to make sense of all of the different verification methods, to review their pros and cons and to also suggest how and where Verifyoo can fit in to overcome these gaps and limitations.

Ready? Let's get started!
Check out the first article -

For more information visit:
To schedule a demo: