DEV Community: Nicholas DeWald

Fraud Capture: Identity Theft from a Data Science Perspective

Nicholas DeWald — Fri, 09 Feb 2024 22:01:12 +0000

In 2022, 1.1 million incidents of identity theft were reported through the Federal Trade Commission, resulting in $8.8 billion lost to fraud (1). Not only does this cost individuals and businesses money, but it also decreases trust between people and the companies they interact with. So, how can we stop bad actors without adding friction to good users in the digital world? While our goal is to prevent fraud, we still need to ensure that good consumers have as seamless of an experience as possible. The more extensive the sign-up process is for a product or service, the higher the drop-off rate, so the process must be as simple as possible.

Prove helps combat fraud by performing digital identity authentication and fraud mitigation using phone risk signals and associating identities to phone numbers to catch bad actors before they can commit fraud. Prove performs digital authentication and identity verification via a solution termed “PRO.” Much of this occurs behind the scenes, allowing the user to have a seamless experience.

PRO

PRO stands for Possession, Reputation, and Ownership, of which we are referring to a telephone. We check to see whether the person claiming to be using the phone is actually in possession of it (Possession), what the recent activity on that phone looks like (Reputation), and whether the person SHOULD have access to the phone (Ownership).

‍The first part of Prove’s solution is built on well-established cryptographic protocols SIM and FIDO. Prove utilizes a cryptographic bind-based authentication where the phone number is bound to the SIM with 128-bit encryption, allowing Prove to authenticate that the user is actually in possession of the phone at the time of the transaction. I’ll go into the importance of this later on, but this is critical for ensuring that I’m not using YOUR phone to open up accounts.

‍The Possession check can be done in a few different manners and Prove has quite sophisticated methods of accomplishing this, but the one most people are familiar with is the SMS OTP. Your bank may send you a text with four to nine digits and ask you to submit that ‘one-time password’ to the website – this allows them to confirm with a relatively high confidence that you are actually holding your phone. It’s important to note that an SMS can be shared through social engineered attacks. The outcome for Possession is True/False.

‍The Reputation check looks at what kind of activity has been seen on the phone recently. Indicators of risky phone numbers include Nonfixed VoIPs, as data on these line types is limited and the barrier to acquiring an account is much lower than others, and recent SIM swaps, as a bad actor can have taken over the phone. Prove has created a heuristic model that uses a plethora of signals to assign each phone number a score from 0 to 1000, where 0 is very risky, and 1000 has no risk we can identify from a Reputation standpoint.

‍The Ownership check confirms whether or not an individual is associated with a phone number. To do this, customers provide some PII (Personally Identifiable Information), that is used to confirm an association with the phone number. The outcome for Ownership is True/False.

Types of Fraud

While there are many different types of fraud, PRO focuses on third-party fraud, also known as identity theft. For example, say I want to open a credit line with my neighbor’s information so that I’m not held responsible for paying the card back. In this scenario, I’ll open an account using my neighbor’s phone number, which has a good reputation because she hasn’t been utilizing her phone for risky activity, and I know my neighbor’s PII, so I’m able to tie it to her phone number – ownership checks out.

‍However, because I’m not physically holding her phone, I won’t receive the OTP that’s sent to the phone to check for possession, and no cryptographic bind has been established – in this case, the possession check returns a ‘False’ value and stops the fraud. While there are ways for me to receive the OTP via SIM swapping and social engineering, we know the phone hasn’t been SIM swapped because it has a good reputation, and let’s assume my neighbor is knowledgeable about social engineering and doesn’t fall prey to my attempts to obtain the OTP she received.

PRO is NOT designed to catch first-party fraud, which is categorized as a person committing fraud as themselves. Consider that I, the fraudster, am perpetrating fraud in my own name. I’ll open an account using a phone number that isn’t used for risky activity but has been tied to me so that it passes the reputation and ownership checks.

Because it’s my real phone, I’ll be able to enter the OTP that’s been sent, and a cryptographic bind has been established, ensuring I pass the possession check. While not designed to catch first-party fraud, Prove can provide a detailed evidence trail that will discourage (or help relying parties identify) first-party fraud: e.g. "This transaction took place on your iPhone 15 at this time and day", essentially a 'digital watermark'.

Risk Indicator Modeling

Although our products are heuristic-based, we use machine learning (ML) to build gains charts to highlight the potential fraud capture capabilities. In other words, if we look at the number of applications that Prove deems to be risky, we see that we’re able to correctly identify fraudulent transactions while minimally affecting good applicants.

‍There are many metrics we can use to discuss fraud capture, but some are easier to understand than others, and we need to be conscious of this when presenting to a non-technical audience. Our team performs ML to help determine which signals may be most useful for a particular client and their fraud scenarios; we can then highlight why those signals were selected with visuals tailored to the audience (e.g., projected revenue or pass-through rates). More often than not, our audience consists of product stakeholders as opposed to data experts, so we have a few different tools at our disposal, depending on who we’re having conversations with.

‍Using accuracy can be helpful, but the data sets we work with tend to be undersampled with fraud. Fraud tends to make up a very small portion of a data set, typically less than 3%. Say we’re working with a set that has a 2.6% fraud rate, and we find we have an accuracy of 80% – this means that 80% of the time, we can correctly classify whether a transaction was good or fraudulent. However, this doesn’t tell us much about how the model is doing because we could classify all fraudulent transactions as good and still retain an 80% accuracy rate.

‍Precision and recall can be useful because they give us more information on how the model determines good vs. fraudulent, not simply whether the model is correct (as accuracy does). Precision tells us what percentage of total predicted fraud was classified correctly, and recall tells us what percentage of total actual fraud was caught by the model. These can be helpful but difficult to explain and can be easily misconstrued by those not familiar with the terminology. For the same population, we could have a precision rate of 0.07 and a recall rate of 0.9. While these numbers aren’t incorrect, they don’t quite tell a comprehensive story and can be misinterpreted as accuracy. Precision is low because the model is over-classifying good transactions as fraud and only correctly classifying 90% of the fraud. If clients take this at face value, they will see that we are adding friction to a lot of their good population but not catching a lot of the fraud – which is the worst-case scenario.

‍We’ve found that using gains charts is a great way to convey results in an easily digestible manner. A gains chart measures how much better a model performs than random guessing. For the same population with an 80% accuracy rate, we can say that we captured 30% of the fraud by adding friction to only 5% of the population. Random guessing would have us capturing 5% of the fraudulent population, so in this instance, we have a 6x multiplier capture rate.

Data Challenges

There are many challenges that come with working with fraud data that affect the industry at large - these are not unique to Prove.

Appropriately labeled fraud can be a pain point as there are different levels of maturity over classifications of fraud as well as different organizations and systems.
In order for us to study fraud, we actually need to go back in time to the moment the fraud was committed. Knowing what phone activity and identity associations are today is essentially useless, so while we have the ability to look back at a moment in time, our retro capabilities are limited and decline with age.
Having as much knowledge about our customer implementations is important as fraud looks different depending on what channels are available, where Prove products are in the flows, and what checks are happening before PRO, but we often don’t have insight into this information.

Modeling Challenges

The goal of modeling is to find the most effective features and signals in Prove’s products to stop specific client fraud.

Logistic Regression is our main approach to modeling; we prefer to keep it simple to allow easy translation to non-technical stakeholders and often need to be able to transition to heuristic rules for clients.
Correct fraud tagging provides better accuracy for models.
Data is often imbalanced (<3% fraud) OR a client may attempt to test us by throwing a large portion of untagged fraud into a file. Conversely, we’ve seen the opposite problem where fraud is over oversampled, but true production sampling is not clear.
The possession check aspect of a real-time transaction can’t be simulated – we simply can’t look back in time and test whether a transaction would’ve passed a possession check.
In Production, PRO is proactively stopping fraud, so it’s hard to measure fraud because we don’t get to see it come to fruition.

Despite these limitations, Prove is typically able to show a significant improvement in fraud capture and/or pass rates over our client’s existing approaches. Moreover, we are able to indicate an additional lift in performance when going live in production as possession checks will occur. Based on our experience with hundreds of client implementations, we can provide guidance on the range of expected lift that possession checks will yield. Finally, when we go live in production, we test a small sample population to validate that our PRO methodology is effective before deploying to the full user population.

Conclusion

Overall, Prove has been able to attain a 75% fraud reduction relative to the attack rate for our customers. There are quite a few different tools at our disposal, but we tend to utilize metrics that are easily understood by a broad audience. Types of fraud that occur, how our products are utilized, and any fraud controls our clients currently have in place can impact the performance of Prove's solutions in implementing the PRO methodology.

Bad actors are always coming up with new ways to commit fraud and so we’re continuously learning and researching how to best prevent it, developing new products, and creating best practices. It’s challenging to keep up with new attack vectors, but understanding how fraud is carried out puts Prove in a great position to stop it.

‍
(1) “New FTC Data Show Consumers Reported Losing Nearly $8.8 Billion to Scams in 2022”, FTC.gov, February 23, 2023 https://www.ftc.gov/news-events/news/press-releases/2023/02/new-ftc-data-show-consumers-reported-losing-nearly-88-billion-scams-2022

The Road to Adoption: A Product and Strategy Perspective

Nicholas DeWald — Fri, 19 Jan 2024 15:31:19 +0000

In our previous articles, we talked about what passkeys are and how to incorporate them into a new or existing web application. However, a successful adoption of passkeys requires considering the larger product to ensure a smooth user experience as well as a secure design.

‍In this article, we’ll address the following questions that product owners need to consider. This will inform the user experience design and strategic approach: ‍

What will passkeys be used for– and what’s the risk profile? ‍
How many of your customers have appropriate passkey capability? ‍
How will you ensure you create credentials for the right users? ‍
What is the recovery strategy (or, what happens when someone’s credentials don’t work for some reason)?
Will you fully retire passwords, and if so, when?

How Are You Using Passkeys – And What Are The Related Risks?

Passkeys are an authentication mechanism, and we addressed earlier how they are generally less risky than passwords. By less risky, I mean specifically that it is much easier to steal someone else’s username and password to be used for authentication, and much more difficult to access someone’s private passkey to fraudulently authenticate. In fact, passkeys were initially very attractive to financial institutions and other organizations where stolen credentials were very risky: if a passkey can’t leave a device, it’s almost impossible for a malicious actor to steal the passkey and use it to authenticate– therefore it’s much harder for someone to, say, log on and drain your bank account. But that’s only device-bound passkeys. Passkeys stored in a password manager (for example, Apple’s passkey implementation stores credentials in the iCloud keychain) are easier to steal. If a malicious actor can get into your iCloud account (and therefore your keychain), they can access your passkeys, and any accounts those passkeys protect.

‍To be clear: passkeys are more secure and less risky than passwords, full stop. However, as an organization, you may want to treat device-bound passkeys (those that are stored on the physical device and never copied elsewhere) differently than synced passkeys (those that are stored in a password manager and shared across devices). Prove has designed our passkey solution to support you in this differentiation.

Since you have a choice about how passkeys are created and stored, if your product is something that is less risky, you may choose to allow passkeys that can be synced and not biometric protected, because that will offer a better user experience. On the other hand, for financial-related products, you may want to require passkeys to be created on device-bound passkeys protected with biometrics for a lower risk of compromise.

‍Fun fact: Prove’s passkey implementation is designed to handle the distinction between device-bound and synced passkeys– even if a user’s platform creates synced passkeys, we can detect if the user is authenticating from a device we’ve seen before– and therefore we can trust more.

How Many Of Your Users Have Passkey Capability?

An important aspect of adopting a new technology is understanding your customer base and what technology they have access to. The wonderful thing about passkeys is that it is a standard built into web browsers, so if your customers have access to a modern web browser, they likely can use passkeys. However, what’s less clear is if your customer’s passkeys are device-bound or not; or if they can be protected by a biometric (Face/Touch scan) as opposed to a PIN. If your user base has access to the newest technologies, your passkey adoption strategy can move faster. In any case, you need to scaffold your passkey adoption strategy with passwords, as there are still many users who will need time to adapt, but by encouraging passkey adoption you reduce the attack surface in the meantime.

‍Non-mobile devices such as laptops or other computers may have more variability in terms of which authenticators are connected, as well as if they are protected by biometrics. More mobile devices have the hardware and software capabilities to support passkeys. If that is a significant issue for your user base, one thing to keep in mind is that passkeys on mobile phones can be used to authenticate on other devices. Prove has built this into our passkey solution as well.

How Will You Ensure That You Create A Passkey For The Right Person?

One thing is clear: once passkeys are created, they provide a secure authentication mechanism, far more so than passwords. If you’re building a product from scratch, using passkeys will be easy. Users creating new accounts will create passkeys instead of passwords. However, if you have an existing user base currently using passwords, they will have to go through a process of creating new passkeys. This generally looks like asking the user to create a passkey after they log in with a password (or your trusted authentication flow) that gets attached to the account as an alternate way to log in.

‍Prove’s authentication capability can help ensure that passkeys are created for the right person, rather than by someone who has stolen a username and password.

What’s The Recovery Strategy?

Even though passkeys are managed by computers on devices that customers tend to not lose, users can lose access to their passkeys. Remember, passkeys can live either on a single device (“Device bound passkey”) or can be shared across devices via a password manager. The risk with device-bound passkeys is easily imagined: perhaps someone loses their device, whether it’s their Yubikey, phone, or laptop; or maybe they get a new device. But it could also be that the device is stolen, and in that case, the path to reset access to someone’s account might be a little different.

‍One thing that will help is to try to keep track of where the private passkey lives for the user. For example, when credentials are created, have the user provide a useful description that you can attach to the public passkey (that you store). For example, if you store passkeys with a description such as “Passkey created on my iPhone 14”, the user knows that they can use a passkey stored on that device (or, really, in the iCloud account associated with that device) to authenticate on their account. Also, if they lose a device associated with that iCloud account, the user can revoke those credentials– then a malicious actor can’t access the account from a stolen device.

‍The original approach to protecting access to an account via passkeys has been to encourage the user to create multiple sets of credentials on different devices. For example, I might create one set of credentials on my personal laptop, my work laptop, and my phone. Then, if I lose access to one of them for some reason, I have a backup. While that might work for people with access to all these different devices, it’s a big lift to create multiple credentials for all my accounts on all these devices and keep them up to date.

‍The recovery strategy helps establish new passkeys for existing users. Identity verification can be leveraged to have confidence that the user is who they say they are. Prove’s identity verification can help ensure that passkeys are created for the right person and on the right phone. We also can help manage the trustworthy movement of credentials to new devices.

Conclusion

As you can see, one of the trickiest things about adopting passkeys is the decision-making about strategic adoption and user experience. There can be lots of “gotchas,” especially as we are starting to transition from our default familiarity with password-based systems to new, more secure passkeys.

The Road to Passkey Adoption: A Developer’s Perspective

Nicholas DeWald — Thu, 18 Jan 2024 15:27:10 +0000

This article focuses on some technical aspects of implementing a passkey authentication mechanism. In the previous article, we focused on what passkey authentication is, and in the next article, we’ll dive into details related to the user experience and business decisions.

‍Passkeys are a new authentication mechanism intended to replace passwords, utilizing public key infrastructure to address a majority of the security challenges we face with passwords. Public key infrastructure provides two things: first, authentication – it can prove who sends a message; second, authorization – it ensures that no one other than the intended recipient can read a message. FIDO2 passkeys utilize these characteristics to provide more secure authentication.

‍Passkeys are specified by the FIDO Alliance and include both software and hardware standards. FIDO2 specifically focuses on the use of passkeys in a web application, which requires the ability of the hosting web browser to interact with the underlying platform to securely create and store private keys. The FIDO2 part of the specification focuses on the interaction between a web application and a FIDO server, and WebAuthN focuses on the interaction of the web application with the browser, as well as the underlying platform.

‍Since FIDO2 and WebAuthN are open standards, it’s possible to read the standards yourself (WebAuthN, FIDO) and add passwordless functionality to your web application. However, while the specification is open, there is a complexity to understanding the details, building and maintaining the server, and keeping up to date with the changes (this is a cutting-edge technology that’s moving fast) while making it easy to integrate into your existing infrastructure. This article provides an overview, distilling the core functionality.

‍We begin by iterating on the interaction/flow required for passwordless authentication. There are two flows, one for registration (creating credentials) and one for authentication.

Reviewing Flows

Traditional password flows rely on a “shared secret.” In contrast, passkeys rely on Public Key Infrastructure, where the client stores the private key and the server stores the public key. The client creates both keys, only sending the public key to the server. Understanding how the registration and authentication processes work is necessary before any passkey implementation can be done.

‍We can implement passkeys in web applications as long as they are running in a FIDO2-compliant browser, with appropriate FIDO2 Authenticators attached. In the following discussion, we’ve represented the FIDO2 functionality used by a web application in a FIDO2 JS SDK library. We also need a web server that can store public keys (key storage) and handle cryptographic tasks.

‍With traditional password authentication, a web application could run in a browser and talk with a server, and the browser doesn’t really matter too much. Since passkeys are created and stored on the underlying platform (that is, either the mobile device or laptop the browser is running on), the browser needs to communicate with the platform and authenticators. Luckily, these days most (>97%, accessed Dec 2023) browsers are FIDO2 compliant (examples here, including Chrome, Edge, Safari, and Firefox), but not all platforms have authenticators built in. Authenticators are the components that run the cryptographic operations to generate, store, and evaluate key pairs. This usually includes some kind of secure hardware storage. Most mobile phones with modern, updated browsers fit this requirement. And, if we can create passkeys on a mobile device, we can use them to authenticate on a device (such as a laptop) that doesn’t meet these requirements.

‍Now, let’s see how these things work together to enable passkey.

Registration

The registration flow is what happens when someone creates a new account, or if someone wants to create a new passkey (it’s a good idea for users to have more than one passkey for each account). The process is depicted in the diagram below:

Let’s review what we see above:‍

Steps 1–3: The user will enter the desired username in a form, and clicking “Register” will invoke the start of the credential creation flow. The application asks the server to register a username.
Step 4: The server generates some information about what is allowed to be used as an authenticator. This includes things like what cryptographic algorithms to use and the hardware capabilities or security mechanisms on the authenticator. This is sent back to the client.
Steps 5–7: This is where we invoke the WebAuthN mechanism to ask for new credentials to be created. The options specified by the server are passed through the browser (Step 6) to the underlying platform and any appropriate authenticators that are available (Step 7). “Appropriate authenticators” means any authenticator that matches the options specified by the server earlier.
Steps 8–9: Most use cases will ask authenticators to protect the credentials with a biometric interaction. When that’s the case, the user will be asked to perform the biometric interaction, then will generate the public and private keys to be used in subsequent authentication actions.
Steps 10–12: After the keys are created, the public key is packaged up with some other information, such as details about the authenticator that was used to create the credentials. This information is passed back to the server.
Step 13: The server will review the details about the authenticator. In particular, this is where the server ensures that the authenticator has not been reported as insecure or compromised.
Step 14: The server stores the public key data and any other metadata.
Step 15–end: Assuming success, return to the web application that credentials are created in and the user can continue.
‍
Once the registration is completed, the user can return and authenticate later.

Authentication

Once a passkey has been created, it can be used for authentication. The general approach is as follows:

Steps 1–2: The client tells the server it wants to authenticate a given username.
Step 3-4: The server looks up the public key associated with the specified user. Assuming the key exists, it’s used in the next steps.
Steps 5–6: The server creates a message including some identifying information about the credentials that live on the client authenticator, as well as a “challenge” (a cryptographically random set of characters). This gets sent to the client. The message is encrypted with the public key– that means no one else can read this challenge, because no one else has the corresponding private key.
Steps 7-8: The web application asks the browser to pass the message to the appropriate authenticator.
Steps 9-10: The authenticator asks the user to unlock with a biometric, if appropriate.
Step 11-12: If biometric unlock was successful, the authenticator uses the private key stored on the device to:
‣ Decrypt the challenge with the private key
‣ Re-encrypt the challenge with the private key (This means that it can only be successfully decrypted with the corresponding public key)
‣ Send the encrypted challenge and metadata back to the web application
Step 13: The web application sends the message back to the server.
Step 14: The server validates the message from the web application, using the public key stored in the register step.
‣ The server decrypts the challenge with the public key and compares it to the challenge we originally sent to the client. If the challenges match, it’s because the correct client/authenticator successfully “unlocked” and “locked” the challenge and sent it back.
Step 15–16: The server tells the client whether the user was successfully authenticated or not, and authentication is complete.

Putting It All Together

Now that we are comfortable with how the registration and authentication flow work, we can summarize the work we need to add passkey capability to a web application.

‍Modifying a web application to use passkeys generally requires the following things: ‍

Adding 4 endpoints to the server. Notice that both the registration and authentication flows require two calls to the server. These are common to think of as “preRegister”, “register”, “preAuthenticate” and “authenticate”.
The client/web application needs to handle that middle part of making the first server call, communicate with the browser/platform, make the second server call, and then handle the result of the register/authenticate process.
Store and retrieve public keys on the server.
Do the cryptographic challenge generation, signing, etc as part of the two ceremonies.
‍
That summarizes the work to be done, but of course, the devil is always in the details. It’s one thing to get a reference implementation built, but once you have the basics in place, you need to of course consider scalability and reliability. Additionally, to improve the usability of passkeys for your users, you’ll want some more features such as the ability to add and remove multiple authenticators (or, sets of passkeys), which requires some overhead around managing the metadata of the authenticators for your users.

What Are Passkeys and How Can They Securely Replace Passwords?

Nicholas DeWald — Tue, 16 Jan 2024 15:09:00 +0000

Haven’t we all suffered with passwords for long enough? Many believe that passkeys are the new password, and they can be more secure and easier to use if implemented correctly. In this article, we’ll introduce the technology behind passkeys, so you can start taking advantage of them. In future articles, we’ll go into more technical depth on implementing passkeys in your organization.

What Is a Passkey?

Passkeys are a method of authentication that uses asymmetric encryption rather than relying on a shared secret like a password. With a password, the user and the company will both remember the same password. Passkeys store a private key on the user’s device, and the company stores a public key. These keys are long strings of characters that are created together in such a way that if you have one, it’s almost impossible to figure out the other, but they work together to prove something, such as that you are who you say you are. As long as we keep one secure (the private key), the public key can be, well, public. If someone steals your public key from a company, they still can’t access your account if they don’t also have your private key. Since there is less value in trying to steal your public key (that replaced your password) from a company, fraud (such as phishing) can be reduced in many ways.

‍To illustrate how powerful passkeys are compared to passwords, I’ll contrast how the two approaches work to protect an imaginary account that you have at a bank. The details will be simplified but include the important points. There are two essential parts of authentication: the first is creating an account (registration), and the second is accessing your account later (authentication).

Creating and Accessing Accounts with Passwords

First, let’s review passwords. On registration, your account is created, and you tell your bank what your username and password is. You and your bank both agree never to share that password with anyone else, so no one else can access your account. Later, when you want to access your account, you authenticate yourself by telling the bank your username and password. The bank compares it to what you told them initially– and if it matches, you can access your account.

I don’t need to go into many details about how this can be problematic; you’ve likely experienced many downsides yourself. You might forget the password; someone can steal the password from you; a malicious third party can steal your password from the bank; a malicious third party can steal your password from your password manager; someone can try to change your password with the company without your knowledge. There are MANY ways passwords can be compromised.

‍Using passkeys that utilize asymmetric encryption helps solve some of the core problems of passwords. As noted earlier, asymmetric encryption uses both a public and a private key. Not surprisingly, these keys are used to encrypt data. If you have a pair of keys, you’ll always keep the private one a secret, but you can share the public one with anyone. Then, if I want to send you a message that no one else can read, I encrypt it with your public key. The message can only be read if you decrypt it with your private key. Because the private key is secret, no one else but you can read the message. Another feature is that when you send me a message, you can encrypt it with your private key. When I decrypt it with your public key, I know the message HAD to come from you because there’s no way it could be decrypted any other way.

‍Next, we’ll talk through how these keys are used together to log into your account and show how they prevent the problems we have with passwords.

Creating and Accessing Accounts with Passkeys

Okay, back to passkeys: When you create an account with your bank, the flow is slightly different. Your device (mobile phone, laptop) creates a private/public key pair. The private key is stored securely in your device, and you send the matching public key to your bank, which stores it. When you return to access your account later, you tell the bank who you are (username). The bank generates a secret message “locked” (encrypted) with your public key and sends it back to your device. No one else can read this message because it was locked with your public key.

‍Next, your device unlocks the message with your stored private key and re-locks it with the private key, adding additional info and doing other checks simultaneously. Because the message is encrypted with your private key, anyone who can decrypt it with your public key knows it came from your device. The locked message is sent back to your bank, which uses your stored public key to unlock the message. If the message is the same as the secret message generated at the start of the process, it must be you and only you logging in, so you can access your account.

Keeping the Private Key Private

Let’s talk about this private key. Similar to a password, it’s important to keep it private. Therefore, your device (a mobile phone, a computer, etc.) stores the private key in a special place to keep it secure and prevent access from anyone (human or otherwise) who shouldn’t have access to it. When passkeys were first deployed, this was usually a hardware key (similar to a USB thumb drive) that you’d plug into your laptop; it became imperative not to lose this key.

‍These days, many devices have secure storage built in to hold unique data such as these keys. The secure storage is usually protected with biometrics (such as Face ID or fingerprint) but could also be protected by a PIN. But, unlike a password, it’s not easy to guess. And because it never leaves your device (although I’ll contradict myself in a couple of paragraphs), it’s very difficult for someone to try to steal it.

The User Experience of Passkeys

As a user, the experience of using passwordless generally feels the same as using a password manager, at least for everyday needs. Here’s an example of a time when it will feel different: Let’s say you are using a borrowed laptop that doesn’t have your password manager on it. To log into an account, you can look up the username and password in your password manager on a different device, and enter it in on the borrowed device. The password might be long and complicated, and it might be somewhat awkward, but it’s possible. You can’t do that with passkeys: the private keys belong on one device, and they are complex and lengthy enough that you can’t just open it up, look at it, or copy it over elsewhere. This means that it’s crucial to think about where your passkeys are created/living in a way that we don’t have to think about passwords.

‍This difficulty in “copying” private keys to other devices is intended to be a security measure, but it has been one of the things preventing organizations from adopting passkey authentication so far. We mentioned hardware keys to store private keys earlier– that’s helpful because you can take that key and plug it into, say, a different laptop and access the credentials. But now that more devices can store these keys built into them, what happens if you lose the device you created your credentials on? What happens if you get a new one? What if the device gets stolen? Securely replacing those credentials is a hard thing to do without passwords. We’ll talk more about that in a future post, but spoiler: Prove has thought a LOT about handling many of these challenges and has a solution.

‍Passkeys can now be stored in password managers, such as 1Password in Apple’s iCloud keychain, which is used in devices like iPhones, iPads, and MacBooks. These are referred to as synced passkeys. Syncing passkeys addresses the problem of credentials living on one device (referred to as device-bound passkeys) by storing the private keys in a password manager, which can be synced to multiple devices via the cloud. We expect to see more organizations making passwordless authentication an option now, as some of the biggest challenges are addressed with the availability of synced passkeys. While this is an extraordinary, huge step forward, it’s not the entire solution: storing private keys in a password manager makes it easier to adopt but also weakens the security of the credentials. The credentials can be compromised via the password manager, so it’s not entirely as secure as device-bound passkeys stored in a trusted module on a single device.

The Beauty of Hosted UX: Elevating Digital Experiences

Nicholas DeWald — Wed, 22 Nov 2023 17:57:40 +0000

In the realm of modern software development, creating delightful user experiences (UX) and harnessing the power of APIs have become essential for delivering value to users. Hosted UX is swiftly attracting interest as a remedy for various business challenges. This article will explore these and how Hosted UX can be utilized to elevate digital experiences.

Hosted UX: Elevating User Experiences

Hosted UX, often referred to as User Experience as a Service (UXaaS), represents a paradigm shift in UX design. Rather than designing and managing the entire UX in-house, businesses can now leverage specialized platforms and services that provide hosted UX solutions. These services offer a range of benefits:

Rapid Development

Hosted UX services come with pre-built templates and components, enabling rapid development. This expedites development by offering a ready-to-use framework that accelerates the creation of user experiences, reducing the need for extensive coding and design work from scratch.

Scalability

These services often come with the ability to scale quickly to accommodate growth. Hosted UX offers scalability by allowing businesses to adapt and expand their user experience solutions as needed. It allows companies to easily accommodate increased user loads, additional features, and changing requirements by leveraging cloud-based infrastructure and services. This scalability ensures that the user experience can grow in tandem with business demands, enhancing performance and accommodating a broader user base without significant infrastructure investments or overhauls.

Customization

While templates provide a starting point, hosted UX solutions are highly customizable. A company can tailor the user interface to match its brand and specific user requirements. Examples of customization include visual elements, such as layouts, color schemes, and branding, to align with a company's unique style and identity. Many hosted UX platforms also allow integration with other software and systems. This enables businesses to incorporate custom features and functionality that meet their specific requirements.

Seamless User Experiences

Hosted UX solutions provide a polished, user-friendly interface where users interact with the application effortlessly. The end user never knows they left the business's native flow when interacting with 3rd party APIs. This approach provides a consistently smooth and frictionless interaction with the product or service across the user journey.

Faster Development

Hosted UX expedites development by offering pre-built user experience components and templates, reducing the need for custom design and development, and streamlining the creation of user interfaces. Developers can focus on building unique functionality by utilizing hosted UX components and templates. This accelerates development, reducing time-to-market.

Data-Driven Insights

The power of Hosted UX combined with analytics provides a rich data source. It facilitates data-driven analytics by gathering and processing user interaction data, allowing businesses to derive insights, make informed decisions, and enhance user experiences based on this valuable information. Businesses can extract insights from user interactions and operational data, enabling data-driven decision-making.

Conclusion

Hosted UX is a game-changer for businesses seeking to provide exceptional digital experiences. Combining a polished user interface and seamless functionality from various APIs creates a powerful partnership. This enhances user satisfaction, improves efficiency, accelerates development, and positions businesses for future growth and innovation. Embracing this synergy is a strategic move for organizations looking to thrive in the competitive digital landscape.

Leveraging Phone Numbers for Rock-Solid Identity Verification: A Technical Deep Dive

Nicholas DeWald — Wed, 13 Sep 2023 21:34:19 +0000

This blog post is part of our Developer Blog Series. For more helpful content for developers and engineers, visit our developer blog.

‍Greetings, developers! Today, we're diving deep into the fascinating realm of identity verification and exploring why the humble phone number reigns supreme in this crucial arena. So grab your virtual lab coats, and let's dissect the technical marvels behind using phone numbers for identity verification.

The Anatomy of Identity Verification

Before we dive into the technical details, let's understand the why behind identity verification. In a world where digital interactions are the norm, ensuring that users are who they claim to be is paramount. Enter phone numbers—a unique combination of digits tied to a physical device—offering a brilliant solution to this challenge.

Phone Numbers as a Foundation

At the core of using phone numbers for identity verification lies uniqueness and accessibility. Unlike usernames or email addresses that can be easily created and discarded, a phone number is tied to a physical device that individuals possess. This inherent physicality forms the foundation of security in identity verification.

Global Accessibility

Phone numbers are universal. People have phone numbers to communicate regardless of location, culture, or language. This universal accessibility enables businesses and services to reach users globally, making phone numbers an excellent choice for identity verification.

Two-Factor Authentication (2FA)

Incorporating two-factor authentication into identity verification helps to fortify digital interactions. When users provide their phone numbers, a verification code (also known as a one-time password or passcode) can be sent to their device via SMS. This code acts as the "second factor," confirming the user's identity. Even if a malicious actor gains access to a user's password, they would still need the code to complete the verification process. In many cases, fraudsters are able to intercept the code – see the challenges and considerations section below – but equipping your flow with 2FA is undoubtedly much safer than not using 2FA.

Voice OTP

Another option for delivering OTPs is voice Similar to an SMS OTP, using voice verification involves calling the user's phone and asking them to confirm their identity. This direct interaction adds a layer of authenticity to the verification process. Consider Prove’s Prove Auth solution for your MFA needs.

Reduced Friction, Increased Conversions

Tech-savvy users are accustomed to the speed and convenience of phone-based verification. This familiarity translates to reduced friction during the onboarding process, resulting in higher conversion rates. Users are more likely to complete the verification process promptly, creating a positive user experience. Please refer to Prove’s Pre-Fill solution for how we can help consumers onboard with reduced friction using a user’s phone number.

Challenges and Considerations

While phone numbers offer numerous benefits for identity verification, it's essential to consider potential challenges:

Privacy Concerns

Users are becoming increasingly conscious of data privacy. It is of utmost importance that organizations handle phone numbers responsibly, ensuring compliance with privacy regulations and offering transparent explanations of how the data will be used.

SIM Swap Attacks

Sophisticated attackers might attempt SIM swap attacks, where they convince a telecom provider to transfer a victim's phone number to their device. This underscores the importance of robust security measures, such as additional security questions or biometric verification. Prove’s Identity Verify solution can check for SIM swaps to confidently do business with end-users.

User Experience

Organizations must ensure that the verification process is seamless and user-friendly. Overly complex or time-consuming processes can lead to frustration and abandonment. This is where Pre-Fill should be utilized to streamline the user experience.

Conclusion: Empowering Secure Digital Interactions

In the realm of identity verification, phone numbers have emerged as a reliable and powerful tool. Their universal accessibility, physical ties, and familiarity make them ideal for businesses seeking to build trust, enhance security, and create seamless user experiences.

As technology evolves, so too will identity verification methods. However, the phone number remains a steadfast companion in the quest for secure and reliable digital interactions. So, developers and tech aficionados, let's continue harnessing the potential of phone numbers to build a safer, more connected digital world!

What is Phone Number Trustworthiness?

Nicholas DeWald — Mon, 22 May 2023 19:59:07 +0000

Welcome back to the Identity Trends blog series! This is the third post in our series. Today, we’ll focus on the concept of phone number trustworthiness, a critical aspect of Trend #3: Reducing Fraud. Keep reading to find out what exactly phone number trustworthiness is and, more importantly, how you can leverage phone number trustworthiness to prevent fraud.

What is Phone Number Trustworthiness?

Phone number trustworthiness refers to the degree to which a phone number can be considered reliable or genuine. It is often used in the context of preventing fraud and scams, as well as verifying the identity of individuals.

Using phone numbers to verify online identity is a relatively new phenomenon. Unlike legacy identity verification methods using traditional data sources, like usernames or social security numbers, phone numbers can provide real-time identity authentication based on dynamic and current data. Real-time validation of these signals helps eliminate sophisticated fraud, such as synthetic identities.

Additional Resource: Move Over SSN – Here’s Why Phone Numbers Are the New National Identifiers

Various tools and techniques can be used to determine the trustworthiness of a phone number, such as checking it against known lists of fraudulent or spam numbers, conducting reverse phone number lookups, or using number risk scoring services such as Trust Score+™. However, it is important to note that no method can guarantee 100% accuracy, and scammers and fraudsters are constantly adapting their tactics to evade detection.

What are the benefits of Trust Score+™?

In today's digital age, fraud and identity theft are growing concerns for businesses and individuals. As more and more transactions take place online and using mobile devices, it becomes increasingly important to verify the identity of users and prevent fraudulent activity like account takeovers. This is where Prove's Trust Score+™ comes in.

Prove's Trust Score+™ provides a numerical score indicating the level of trustworthiness of a given phone number. Trust Score+ leverages phone number signals, proprietary data sources, and Prove’s more than 15 years of phone data to identify risks based on the history of that phone number while leveraging real-time data from Mobile Network Operator (MNO)/carrier data to track risky phone number behavior high-risk events (e.g., money movement, password changes, phone number updates, etc.).

The score is based on various factors, including the phone number's age or “tenure,” usage patterns, and association with known fraudulent activity. The Trust Score+™ API can be easily integrated into existing systems and workflows, supporting businesses to quickly and easily verify the identity of their users and prevent fraud. Below you will find an example of our API request and response to integrate Trust Score™ into your flow:

Trust Score+™ Request

Trust Score+™ Response

Trust Score+ provides banks, financial institutions, insurance companies, retail chains, and other organizations with a tool that can be applied to multiple use cases where knowing the fraud risk of a mobile-based transaction is critical.

How is the Trust Score+™ Measured?

The Trust Score+™ of a phone number will always fall between 0 and 1,000. The higher the Trust Score™, the better reputation of the phone number. A good rule of thumb and a Prove best practice is to consider trust scores greater than 630 as 'high', and trust scores 300 and below as ‘low’. If you were to leverage Trust Score™ to secure high-risk transactions such as a money transfer or password reset, for example, you would typically only green light or approve transactions tied to phone numbers that have high trust scores.

What are the most popular uses of Trust Score+™?

A popular use of Trust Score+™ by businesses is leveraging it as a trust indicator before sending a one-time passcode via SMS (“SMS OTP”) as a factor of authentication tied to a consumer’s mobile device. Trust Score+™ This helps businesses identify and evaluate potential risks, such as an insecure VOIP line, recent port activity, and/or low SIM tenure, before choosing to send the SMS OTP to the device and ultimately enabling access to their application or site. In other words, companies are empowered to fortify their OTP solutions by making an informed decision about whether an OTP should be sent.

For example, if Trust Score+™ is run prior to the SMS OTP being sent and comes back with an indication that the line type is VoIP or that a SIM swap has occurred recently, the company can choose to authenticate the consumer using a different method instead of sending an OTP.

Prove's Trust Score+™ API can help businesses improve their fraud prevention capabilities, enhance the user experience, and reduce costs, while also helping to ensure compliance with regulatory requirements.

What is Passwordless Authentication?

Nicholas DeWald — Mon, 24 Apr 2023 14:47:07 +0000

Welcome back to the Identity Trends blog series! The first post provided a comprehensive guide to leading identity trends—check it out here if you missed it. The next three posts will dive deeper into each of the major trends and explore how Prove solutions can help you stay ahead of the game. Today, we’ll be focusing on Trend #1: Passwordless Authentication.

What is Passwordless Authentication?

As its name suggests, passwordless authentication uses factors other than traditional passwords, such as biometric data (fingerprints, facial recognition, or iris scans), hardware tokens, and other forms of digital identification to verify the identity of a user. There are many different benefits to going passwordless from both a security and user experience perspective.

What are the benefits of going passwordless?

Did you know that roughly ⅓ of online purchases are abandoned at checkout because consumers cannot remember their username and password? Considering that the average consumer has around 100 passwords and usernames to remember, the rate of cart abandonment is not surprising. In addition, because consumers have too many passwords to remember, they often use the same password across different accounts, creating a dangerous domino effect in which a data breach at one company can result in dozens of accounts being compromised per user. As a result, many companies are phasing out passwords and replacing passwords with more secure options to improve user experience, bolster security, and boost their bottom line. That’s where Prove Auth comes in.

With the increasing prevalence of cybercrime, it's more important than ever to protect ourselves from hackers and identity thieves. Fortunately, there's a technology that is changing the game when it comes to online security: Prove Auth.

Prove Auth

One of the major benefits of Prove Auth is that it is incredibly user-friendly. Instead of requiring users to remember complex passwords and constantly reset them, Prove Auth works seamlessly in the background, verifying their identity without any extra steps or hassle. Plus, because it is based on real-time data analysis, Prove Auth can detect and respond to potential security threats in seconds, ensuring the user’s information stays safe and secure.

But what about privacy concerns? With so much personal information being shared online, it's understandable to worry about how that data is used. Prove Auth is designed with privacy in mind, using secure encryption protocols to protect your information and keep the user’s data anonymous and confidential. And because it works in real-time, Prove Auth doesn't store sensitive data on your device or in the cloud, minimizing the risk of a data breach.

Keep reading for details on our Prove Auth Flow as we dive deeper into how to integrate Prove Auth. Prove Auth is an umbrella service representing various forms of authentication. The product currently consists of Device Auth and Mobile Auth.

Device Auth

Device Auth is a form of passive authentication where the enterprise can verify the possession of the phone in real-time without any interaction from the user. Mobile Auth is also a form of passive authentication where the possession of the phone happens in real-time with coordination from the MNOs (mobile network operators). Prove Auth provides flexibility by allowing control of which authentication forms to execute for any given use case.

Mobile Auth

Mobile Auth is based on a 3-call flow; the first and last calls are handled in a server-to-server environment, while the intermediate step occurs on the phone being queried.

Our Server Integration Guide outlines how to implement the two API calls of /authenticateByRedirect and /authenticateByRedirectFinish in an API-only flow.

Our Native App SDK Integration Guide and Web SDK Integration Guide cover integrations on the device through one of Prove’s SDKs—whether through an app or mobile web browser—providing a quick and easy way to retrieve the data needed, even if your user is on Wi-Fi. This is important for the Device Auth call.

Mobile Auth Flow

The first step is orchestrating a server-to-server call to the /authenticateByRedirect endpoint, which requires the device IP of the cellular connection. The second step is a middle call that the Prove SDK handles; this happens over a cellular connection and attempts to reach the authentication URL (redirect URL). The third step takes the response from the second step, which is then passed to the client’s backend, making a server-to-server call to /authenticateByRedirectFinish. It’s important to note that the customer’s app must complete steps one and three, and is not done by the SDK. The SDK orchestrates when steps one and three are to be executed.

The mobile SDK provides a quick and easy way to retrieve the data needed to make those server-side calls. In addition, since the middle call must happen over the cellular network, the SDK helps by retrieving the cellular IP address of the device and potentially performing a Wi-Fi override for the middle call.

First Call: /authenticateByRedirect

The first server-to-server call, the /authenticateByRedirect endpoint, requires the mobile device's cellular IP from the mobile data session, entered in the “deviceIp” field, plus the URL for your server needed for the mobile device to send the verification fingerprint (VFP, i.e., a one-time, time-bound authentication for unique identification) via the “finalTargetUrl” field.

The “RedirectTargetUrl” generated in the response is a one-time, time-bound authentication URL with the first VFP specifically for this mobile device and request. The VFP value is a one-time use key that ensures that man-in-the-middle attacks are impossible.

Middle Step: Device Auth

Next, the mobile device must execute an HTTP GET directly to the “RedirectTargetUrl” returned from the /authenticateByRedirect call; the device makes the request directly to Prove and is authenticated.

The network enriches the request with subscriber identifying information, typically encrypted into a new, one-time use, time-bound, SIM-signed VFP token that is shared back to the device. The new VFP returns in the HTTP 200 or 302 responses, even in the case of an error. The 302 response in the web browser implementation returns the device to the FinalTargetUrl specified in the first call, which then starts the final call of the flow.

See our Native App SDK Integration Guide and Web SDK Integration Guides for details on integrating Device Auth.

Final Call: /authenticateByRedirectFinish

The final API call, the /authenticateByRedirectFinish endpoint, obtains the results of authentication from the second call, passing the “verificationFingerprint” (VFP) value returned by the mobile device.

If successful, the “MobileNumber” associated with this particular consumer is returned to your server in this step, indicating Mobile Auth has been completed.

Overall, Prove Auth is an excellent choice for passwordless authentication. It’s perfect for businesses and organizations prioritizing security and protecting their sensitive information from unauthorized access. In addition, its use of MFA and fraud detection algorithms and ease of use make it a reliable and effective authentication solution. Using Prove Auth, businesses can ensure that their online accounts and services are secure and their customers' data is protected.

Why Mobile Banking Apps Use React JS for Simplifying E-Banking Maintenance

Nicholas DeWald — Wed, 19 Apr 2023 13:54:27 +0000

Is your financial institution on the fence about whether to work with a React JS specialist and if React is the best solution for maintaining your banking app? It is abundantly clear that the seascape of the banking world has undergone a tremendous metamorphosis over the past decade. It is often hard to determine whether something is just a fad or a fundamental innovation.

‍There have been 4 billion finance app downloads across the iOS and Android platforms. At the same time, brick-and-mortar bank branches are closing around the world. There is a direct correlation between the two.

‍People prefer the luxury of being able to bank anytime and anywhere, and smart devices and the internet have made this possible. This has made the demand for technical experts in mobile development a must in the financial services industry. In this article, we explore the benefits of using React JS for the development and maintenance of your mobile application.

What Is React JS?

React JS is a JavaScript library, created by the developers at Facebook, to simplify the development of user interfaces. The two competitors in this space are Angular and Vue—at a distant third. React currently dominates the marketplace with more than double the users of Angular.

‍React is a component-based library that builds applications by stacking components into one app. For instance, a bank app may partially consist of components like:

Navbox
Profile
My Account
Transfer Money
Loan Products
Contact
‍

These components constitute the fundamentals of a basic e-banking app. The primary power of using the React approach to maintenance is that it uses both the Real Dom and a Virtual Dom. This is the key to the ability of React to maintain the stability of your website while changes are being made.

‍The developer can make changes to the individual components in the Virtual Dom without directly impacting the website’s framework. When the changes are made virtually, the Real Dom reacts by automatically updating the change to that particular component.

React vs. Angular

Over the past couple of years, React JS has overtaken Angular as the most-used UI development solution. React is a lightweight component creation tool that makes the process of building user interface components simpler. React is written using JSX and not HTML, so knowledge of this language is needed. For the maintenance of e-banking applications, the compartmentalized aspect of this library makes React JS ideal.

‍Angular is a framework rather than a library. Its robust design is focused on building applications. The approach of Angular is all-inclusive and extensive. The options that Angular presents for full application development are undeniable. However, React JS has become popular when it comes to maintaining a UI for an e-banking app because of the fluidity and stability associated with its use of the Virtual Dom, giving it a clear advantage in this regard.

The most fundamental difference between the two is that React is a library for developing UIs, and Angular is a full framework for applications. The streamlined approach taken by React makes it most suitable for financial services and banking. This is why banks use React JS for mobile applications.

React for Financial Services Apps

Another reason that React has become so well used is the open-source nature, making it possible to add libraries and enhance the platform in a wide variety of ways. We have seen this done to tend to the needs of the financial services communities specifically.

‍React JS has been enriched for the development of finance-based UI. React Native has become a popular iteration of the technology that financial institutions and service providers have used as part of the modularized codebase and attractive UI design kits for the design and maintenance of mobile banking apps.

A good example of how this technology has been enhanced to cater to the banking world is the React Native Finance App Template. The FinTech community is now using the multi-purpose facets of React Native explicitly tailored for developers of financial services and banking apps.

Some of the FinTech app types that were made easier with React Native:

Investment portfolios
Crypto trading
Stocks trading
Market news
Personal capital progress
Banking features (checking/savings accounts, transactions)
Net worth tracking
Expense tracker
Budget tracker
Notifications
‍

When you focalize your efforts to the crucial aspects of your product, you save time, money, and energy. When your objectives are clear, and you need a standard regulated approach to your user interface, React JS delivers in spades. The presets and plugin factors cut maintenance and development time down, thus cutting energy and cost.

‍The buzz behind the React JS platform is warranted and alarming to all who have not begun to convert to the use of this tool in financial services. It is understandable for financial companies to want to proceed with caution when it comes to using unfamiliar technologies and approaches that may not withstand the test of time; however, we see something much different for financial companies and the incorporation of React.

Conclusion

When it comes to updating and switching technologies, there is a lot to consider; however, the most significant consideration is whether the benefits outweigh the inconvenience of making changes to staffing or technical infrastructure. It should be apparent by now that the technology has moved forward, and React JS is the preferred platform in this day and time. When stability and efficiency matter, React JS seems to be the financial sector’s best option.

A Worthy Sequel: An Overview of Next-Gen NoSQL Databases

Nicholas DeWald — Tue, 18 Apr 2023 14:23:30 +0000

A database is an organized and systematic collection of data that can be stored and accessed electronically. A database management system (DBMS) is an integrated software package designed to allow users to access, manipulate, analyze, manage, and retrieve data in a database. Since the first DBMS, the capabilities and performance of databases and their respective DBMS have grown exponentially. This tech evolution has led to various databases such as the relational database (RDBMS), object-oriented database (OODBMS), cloud database, and NoSQL database.

Developed in 1970 by Edgar F. Codd at IBM, the RDBMS is a tabular database that stores and provides access to data points that are in relation to one another. In an RDBMS, data is organized as logical, independent tables and is shown through established relationships among data points and supports pre-defined data types with a reference that links them together. Many RDBMS systems use the standard Structured Query Language (SQL) for querying and maintaining the database. The RDBMS is the most widely accepted database model as users can safely and easily categorize, store, query, and extract data. Furthermore, software programmers and develops began to treat data in databases as objects leading to the rise of the OODBMS. The OODBMS organizes and models data as a definable data object as opposed to an alphanumeric value. Programmers using OODBMS can enjoy consistency in the programming environment as it is integrated and uses the same representation model with the programming languages. A cloud database is a database that runs on a cloud computing platform that collects structured and unstructured information and data. Organizations run cloud databases on virtual machines leading to higher infrastructure utilization leading to cost savings. Database-as-a-Service (DBaaS) powered by a cloud database has high scalability and efficiency and failover support and maintenance.

‍As the advancement of databases continues, it is essential to note that different databases have their own justifications for use. For example, a cloud database is typically equipped with a better scale than on-premises RDBMS but still built on traditional relational architecture with challenges in scaling and limited flexibility due to being anchored to the cloud service provider. On the other hand, an RDBMS is known for its accuracy due to data deduplication, easy accessibility, flexibility (as complex queries are carried out), and robust security due to the purpose of atomicity, consistency, isolation, and durability (ACID) to protect against data manipulation and ensure data integrity. However, the RDBMS falls short of scale-up architecture, which requires over-provisioning, auto-sharding, and replication when the data volume peaks. Additionally, the OODBMS represents the complex structure that allows the creation of a more realistic model, better performance, and flexibility. Nonetheless, it lacks standardization as there is no consistent theoretical basis to support OODBMS products.

NoSQL database use cases and benefits

As we acknowledge the potential advantages and disadvantages of various databases, here comes the innovative approach of the NoSQL database. NoSQL databases provide a mechanism for accessing, storing, and retrieving data that is not modeled in tabular relations like an RDBMS. Unlike an RDBMS where data is being structured in fixed relational columns, a NoSQL database involves various types of data structures such as the key-value store where data is stored and represented as a collection of key-value pairs, document database where data is assumed to be encapsulated and encoded in some standard format of encodings like XML and JSON. A NoSQL database has a cluster-friendly, non-relational structure with the ability to deal with heterogeneous and enormous amounts of data. NoSQL databases allow data to be stored in data schemas that are not as ‘fixed’ as RDBMS and have a flexible structure, essentially removing the rigidity of RDBMS.

The high scalability due to auto-sharding for scaling and geographically dispersed scale-out architecture makes a NoSQL database highly efficient in dealing with vast volumes of data while remaining cost-effective at the same time. The ability to enable complex analysis, flexible system, and managing unstructured data that changes over time prove superior to the RDBMS. NoSQL has dynamic schema and high agility better suited for big data and the Internet of Things (IoT) usage. We can look at the various examples and use cases, such as a NoSQL database in real-time data analytics, fraud detection, and risk management system that enables financial institutions to consolidate better and measure risk metrics. With the scale-out capability, a NoSQL database enables high-speed data ingestion and analytics in market data management. Many use cases such as profile management, reference data management, and customer 360° view capability can be unlocked using a NoSQL database.

The rise of the NoSQL database not only comes with its profitability and benefits it brings to database management. Still, it is also accompanied by disadvantages like lack of standardization, which can limit further expansion, limited community support, and problems with interfaces and interoperability. However, the issues with NoSQL databases are currently being solved, which points to the future development of the NoSQL database. The next thing in store for the NoSQL database is the improvement in the consistency model with ACID and Basic Availability, Soft state, and Eventual consistency (BASE), as well as an increase in standardization and benchmarking combined with the expansion of NoSQL to encompass functionality that other database platforms have. Many companies are actively expanding and experimenting with the use of the NoSQL database, so it is exciting to witness the potential and future roadmap for NoSQL databases.

Security By Design

Nicholas DeWald — Fri, 14 Apr 2023 17:32:27 +0000

We consider many things valuable in our lives: money, freedom, and homes, for instance. Yet all of these are now in danger because of stolen identities. In the modern digital era, criminals are not just targeting our wealth or property but our very identity itself.

Sadly, the software development methodology of many corporations has aided this new breed of criminals by failing to be good stewards of the information entrusted to them. We’ve all seen the news headlines: “Millions of Identities Stolen” and “Corporation Left Secure Data on Open Server.” This sort of headline is now all too common, often dominating the news cycles. People are left wondering if their data can ever be safe or if the software can ever be trusted.

Most of this goes back to a quirk of human nature—namely, that security often becomes an afterthought to functionality. For example, the first cars built didn’t have door locks or even an ignition key. It was more important the vehicle be able to drive and go places. It wasn’t until years later that automobile companies began offering door locks and ignition keys as a standard part of the cars they sold.

We see this same opinion in many industries, which has led to the situation we are in today. Criminals will always look for the easiest route to make money. When infamous bank robber Willie Sutton was asked why he robbed banks, he answered, “That’s where the money is.” But after decades of work to vastly improve security, criminals rarely attempt to rob banks anymore. It’s far too risky.

But if only legitimate customers can get money out of banks, then the criminals need to find a way to convince the bank that they are legitimate customers. Achieving this level of deception used to be complicated. First, you have to know secret information about a person, information only that person should know. But the very companies that would validate this information were like the banks of Sutton’s day. These modern corporations kept all that information in the equivalent of inadequately guarded safes. Some of these data breaches involved putting their customer’s information on a public display board in the figurative front lobby, thinking no one would ever look there.

This may seem like an odd article for a company dealing with precisely this sort of customer information to publish. But that’s because, at Prove, we believe in a different philosophy: Security by Design.

Imagine that instead of security being something bolted on at the end, security is the primary goal that we plan for from the very beginning. We add functionality to our systems only after ensuring that the data used is secure at all times. That way, data can never be compromised because it is always secure.

This philosophy has led Prove to several standard models that form layers of security within all our systems. The first and most robust is that Prove does not store any Personally Identifiable Information (PII) in our storage systems. After all, if you don’t have the data, you can’t very well lose it.

Whenever PII data is required, we retrieve the most recent and accurate data from our providers, ensuring that our data is never stale. We use that data only for the requested transaction, after which the information is forgotten on our systems. Discarding sensitive information means that, even if someone had direct access to our servers and storage, they would still be unable to compromise any customer data.

Secondly, we rely heavily on encryption in all of our systems. All connections to and from our data sources and interacting with our clients use modern cryptographic techniques to ensure that the data cannot be intercepted or compromised. As a result, only the intended recipient of the data can receive it.

Additionally, we also use encryption internally. When data moves within our systems, it is encrypted, ensuring that the data, even internally, cannot be read while in transit between systems. This kind of protection is mandated by the highest security requirements of government agencies and the military. Data simply does not move in a useful format. Even an employee of Prove could not read the confidential data.

Finally, in rare cases where we need to know if data has changed over time, rather than store the data for comparison, we keep a version that has been mathematically hashed in a way that the original data cannot be recovered from the hashed value. This way, we can determine changes without needing to store the actual data on any of our systems.

Rather than security being an afterthought, like we see at the compromised companies, all our systems are designed first and foremost to be secure. At no time do we expose the data of customers in any way.

I’m sure you’ve heard these promises before, but as the original system architect, I ensured security by using my personal data as the first record run through the system. After all, if I wouldn’t trust it with my data, then why would you trust it with yours?

Prove believes in security by design and ensures that all your data is always safe from compromise. Don’t you wish all corporations worked this way?

How I stopped worrying and embraced Docker Microservices

Nicholas DeWald — Thu, 13 Apr 2023 17:17:26 +0000

Hello, world!

‍If you are like us here at Prove, then you’re really passionate about programming, programming languages, and their runtimes. You will argue passionately about how Erlang has the best Distributed Systems model (2M TCP connections in one box), Haskell has the best type system, and how all our ML backend should be written in Lua (Torch). If you are like me and you start a company with other people, you will argue for hours, and nobody’s feelings are gonna be left intact.

‍That was the first problem we had in the design phase of our Machine Learning backend. The second problem will become obvious when you get a short introduction to what we do at Prove:

‍We data-mine a lot of sensors on your phone, do some signal processing and encryption on the phone, then opportunistically send the data from everybody’s phone into our Deep-Learning backend, where the rest of the processing and actual authentication take place.

‍This way, the processing load is shared between the mobile device and our Deep Learning backend. Multiple GPU machines power our Deep Learning, running our proprietary Machine Learning algorithms across all users’ data.

‍These are expensive machines, and we’re a startup with finite money, so here’s the second problem - Scalability. We don’t want these machines sitting around when no jobs are scheduled, and we also don’t want them struggling when a traffic spike hits. This is a classic auto-scaling problem.

‍This post describes how we killed two birds:

Many programming runtimes for DL
Many machines

With one stone. By utilizing the sweeping force of Docker microservices! This has been the next big thing in distributed systems for a while, Twitter and Netflix use this heavily. Since we have a lot of factors we verify against, like Facial Recognition, Gait Analysis, and Keystroke Analysis, it made sense to make them modular. We packaged each one in its own container, wrote a small HTTP server that satisfies the following REST API, and done!

This API can be useful because every Machine Learning algorithm has pretty much the same API; training inputs, normal inputs, and outputs. It’s so useful we decided to open-source our microservice wrapper for Torch v7/Lua and for Python. Hopefully, more people can use it, and we can all start forking and pushing entire machine learning services in Dockerhub.

But wait, there’s more! Now that we containerized our ML code, the scalability problem has moved from a development problem to an infrastructure problem. To handle scaling each microservice according to their GPU and Network usage, we rely on Amazon ECS. We looked into Kubernetes as a way to load-balance containers; however, its support for NVIDIA GPU-based load-balancing is not there yet(There’s an MR and some people who claim they made it work). Mesos was the other alternative, with NVIDIA support, but we just didn’t like all the Java.

In the end, this is how our ML infrastructure looks like.

Those EB trapezoids represent Amazon EB (ElasticBeanstalk), another Amazon service that can replicate machines (even GPU heavy machines!) using custom-set rules. The inspiration for load-balancing our GPU cluster with ECS and EB came from this article from Amazon’s Personalization team.

‍For our database, we use a mix of Amazon S3 and a traditionalPostgreSQL database linked and used as a local cache for each container. This way, shared data becomes as easy as sharing S3 paths, while each container can modularly keep its own state in PostgreSQL.

‍So there you have it, both birds killed. Our ML people are happy since they can write in whatever runtime they want as long as there is an HTTP server library for it. We don’t really worry about scalability as all our services are small and nicely containerized. We’re ready to scale to as many as 100,000users, and I doubt our microservices fleet would even flinch. We’ll be presenting our setup in the coming Dockercon 2017 (hopefully, waiting for theCFP to open), and we’re looking to hire new ML and full-stack engineers. So come help us bring the vision of passwordless implicit authentication to everyone!