Unveiling the Secrets

Published in

saas-infra

11 min readNov 29, 2023

Understanding SaaS Security Practices

In this article I would like to give simple “under the hood” explanations for security measures we use (and enforce) in our day to day usage and development of online services

Password (Hashing)

We all know the idea behind passwords and no longer have a post-it note glued to our laptop screen with “1234” or “password” on it, but how does it actually work? Is my password stored in some database waiting to be leaked? can multiple users have the same password?

Most SaaS applications use some sort of “Password Hashing”. A Hash function is a manipulation of text (usually using a cipher algorithm) in order to create a unique string of characters that can be identified as the user’s password but has no value on it’s own.

Example

SaaS platforms these days require a password of at least 8 characters including small and capital letters, a digit and a special character. Something like ‘Password123!$’

This is a good place to mention that the complexity of the password has nothing to do with the hashing but is simply meant to prevent someone guessing your password or a hacker using ‘Brute Force’ to crack it.

Now enters the hash function which will take our password and use an algorithm to produce a new string of characters to be stored in the SaaS database.

There are several widely used hashing algorithms, each using a different hash function to transform the password. Some of the more common ones are bcrypt, Argon2, scrypt and SHA-256

Each algorithm has it’s own internal logic and has advantages and disadvantages when we consider our defenses against hackers.

Let’s take bcrypt as an example. bcrypt stands for “Blowfish Crypt” which uses a cipher (basically a secret code for exchanging characters) and sprinkles in some ‘salt’ which is a random data set generated each time the hash function is executed.

I took our password from above and run it through the bcrypt generator:

Plain text password: Password123!$
bcrypt hash: $2a$10$UNbz3ebHwJcfXgYbUGBjeON6pKYWu/d.s71My64ifgiVEfO4E5Pp.

We can now break this hash down to see the various parts of it:

$2a - This is the cipher version used
$10 - Rounds (2^10 = 1024 rounds of using the cipher encryption)
$UNbz3ebHwJcfXgYbUGBjeO - The randomized 'Salt' data
N6pKYWu/d.s71My64ifgiVEfO4E5Pp - The actual hashed password

why is it important to have the random ‘Salt’ part?

This allows multiple users to have the same text password without having the same hash result.

Also, the ‘Salt’ combined with the cipher version and rounds are used to perform the password validation when the user enters their text password. The validation algorithm uses the Salt part of the hash to make the same computation on the text and verify that the resulting hashed password is identical.

Taken from https://bcrypt-generator.com/

Multi Factor Authentication

MFA (2FA or 3FA) is a mechanism that adds additional layers of security to the SaaS application.

These are the common authentication factors referenced in MFA terminology:

Knowledge Factor (Something You Know): This is typically a password, PIN, or some other piece of information that only the user should know
Possession Factor (Something You Have): This involves a physical item that the user possesses, such as a smartphone, security token, or smart card
Inherence Factor (Something You Are): This refers to a biometric characteristic, such as a fingerprint, retina scan, or facial recognition

Why do we need extra layers of security?

There are several answers to this question, the easiest one is wanting to make sure that the person who entered the password in the first layer (Knowledge Factor) didn’t steal it or guess it.

For the purpose of this article I will reference only 2FA, as the 3rd factor will usually require specific hardware and is less relevant for SaaS applications.

How does it work?

First step in setting up 2FA is by registering a device to be associated with the user’s profile in the SaaS

There are several way to achieve this, mostly this is done by either scanning a QR code or entering a numeric code into one of the commonly used Authentication apps:

By entering the code into the app, you are now creating a shared secret between the application on your device and the user’s 2FA profile in the SaaS.

Later, this shared secret will be used by the TOTP (Time-Base One Time Password) algorithm to verify the code entered when prompted by the SaaS upon login.

Basically the algorithm creates a numeric code that is based on the following factors:

The shared secret
A cryptographic function
Time window (a code is usually valid for 30 seconds)
Code length (number of digits)
Current Time

Since these are made of 4 constants and one time based variable, it can be calculated exactly by the 2 parties that hold the shared secret — i.e the authentication app on your device and the SaaS code using the relevant library (commonly used is otplib that supports all 3 applications above)

Example:

Shared Secret: JBSWY3DPEHPK3PXP
Current Time: 1672531200 (January 1st 2023, midnight)
Cryptographic function: HMAC-SHA1
Code length: 4 digits
Time Window: 30 seconds

And this is more or less the TOTP calculation process in this case:

Since the calculation of TOTP is time based, the code will only be valid for 30 seconds and the app will need to generate a new one to be used.

2FA codes can also be sent by SMS messaging, email and other methods.

By doing so, the SaaS is taking the role of not only validating the code but also generating it for the user to use. This is somewhat less secure but is acceptable as an additional security measure.

When sending the code via email, most chances are that the user will not be able to enter it in the 30 seconds timeframe. Instead of increasing the time window, it is possible to use the verification algorithm to check the code’s validity for several time windows past (e.g 5 minutes = 30sec * 10 windows)

CAPTCHA (Are you human?)

CAPTCHA stands for “Completely Automated Public Turing test to tell Computers and Humans Apart”

Basically it is a security measure dedicated to distinguish between humans and Bots. Automated tools and scripts can be used by malicious or innocent parties to scan websites, fill forms, create accounts or even for website attacks.

The basic idea of the CAPTCHA is to present the user with a test that needs to be performed and passed in order continue registering or entering the SaaS

This challenge is designed to differentiate between humans and automated bots or scripts.

As Bots become more and more sophisticated, so do the CAPTCHA tests have to evolve to incorporate machine learning and other advanced methods of overcoming this risk.

Here is an example of a CAPTCHA test that is simply asking the user to mark the checkbox to verify they are in fact human:

Below is a more complicated CAPTCHA test, asking the user the identify images in a photo and mark them according to the description:

It is recommended to integrate a CAPTCHA test into your SaaS, but keep in mind that the user experience does decrease with these tests as they can be somewhat confusing and cause delays to the users when trying to enter the application.

This can be mitigated by only triggering the CAPTCHA when the SaaS identifies a risk factor such as multiple wrong password entries or suspicious network activity.

There are several known CAPTCHA providers lead by reCAPTCHA by Google.

It is possible to design your own CAPTCHA service, but I would not recommend it as from a security point of view there is no harm in using a 3rd party for this and the complexity of creating a challenging yet user friendly CAPTCHA test.

GeoLocation Filtering

Some SaaS offerings are different from region to region. This could be due to regulation in certain countries or business considerations that could affect this decision.

In some cases, access from such a region could be blocked entirely or require additional charges or consent.

This can be achieved by implementing GeoLocation identification and filtering.

Basically the SaaS application will need to identify the IP address of the user’s device used for the request. Each device connected to the internet will have an assigned IP address which acts as the ‘Home Address’ of any network based requests such as browsing the internet.

There are global geoLocation databases which can determine the location of the IP address making the request.

For example, I am based in Israel and my outgoing IP address (as assigned by my ISP) is 172.31.77.67

Using one of the online IP location services I can see that:

From https://www.iplocation.net/ip-lookup

Not only can I see the country and region, but I also get even more details regarding my connection which can also be used by any SaaS that has this information public to them.

Extracting the incoming IP address from browser requests is quite straight forward. The origin address is usually located in the HTTP request headers but this can vary depends on the network architecture and request method.

For a direct HTTP request between a client and a server, the IP address is most commonly found in these headers:

[REMOTE_ADDR] = 172.31.77.67
[REMOTE_HOST] = 172.31.77.67

When there is a network proxy or load balancer involved, the IP address in the above headers will be of the proxy server and not the origin. In such cases, there will be a different header carrying the IP address:

[x-Forwarded-For] = 172.31.77.67

Once the IP address has been extracted, it can be used with one of the global geoLocation services to identify the origin and act accordingly.

Can the origin IP address be spoofed ?

It is important to understand the IP addresses can be manipulated by altering the network request packets to carry false information. This also can be achieved by using VPN technology that supplies the user with an origin IP address in a different region.

There are counter measures that can be taken to avoid IP spoofing but they should be the responsibility of an IT network specialist and commonly considered very complicated.

SSL/TLS Certificates

SaaS applications are hosted on the internet and are accessible usually over HTTP. This means that the website containing the SaaS sensitive data is accessible from any browser or other network tool with HTTP support.

The security risks here include:

Man in the Middle Attacks
Data exposure and leaks
Session Hijacking
and more …

To solve this issue, the application should be accessible only via HTTPS which adds a security level of encryption to the HTTP protocol by using SSL (Secure Sockets Layer) certificates.

SSL certificates are typically encoded in such formats as X.509 and base64 like this (fake) one:

 — — -BEGIN CERTIFICATE — — -
MIIDpDCCAoygAwIBAgIJAJYg97xU5S5iMA0GCSqGSIb3DQEBCwUAMIGLMQswCQYDVQQGEwJVUzET
MBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEOMAwGA1UEChMFR29v
Z2xlMQ8wDQYDVQQDEwZBbGkgQ2VydDAeFw0xODExMTYwNjUyMDdaFw0yODExMTQwNjUyMDdaMIGL
MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZyYW5jaXNj
RRxFn6lVNY8etOKbUfOxX4wDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAQEAAQ/4F
8yTo4mWabH0G94kXPt8lcH7R9NktxUbStDoxY+R+uJ4vRAKYnYjF/mWgORJZ57+I/TrVlcTpZb+o
9TgrGdcuTlN+ukIWKoMZiuSSrN72l9kWW6HmgUJqjmqr4PE3FkIUIKdCByfhXQSVe01FY0t2ETD1
tJ4ngPndjLrtNKoyYBsR72Igsx0bCdC8rR0eU9yHqfD4rN7SdJb1Bwr0THLZ5c7L4rGtiaRwJeYW
6G+X6PzYz8IHYBpamLLS+IMkSGTAVh4zznmXbcpP0vHY6tWNCeLfYbyo1hMbiBrYZykUTUH2Lzlj
Ntckzqbo+2RCrLg+UL77s2O3aWg==
 — — -END CERTIFICATE — — -

Certificates are a type of electronic documents that contain information about a host or web server. These certificates are generated by a CA (Certificate Authority) which acts as a trusted party between the user and the server.

The verification of the requests to the server are done via a pair of keys:

Public Key — Embedded in the certificate and is used for encrypting data

Private Key — Kept on the server and is used for decrypting data

When a user connects to a website over HTTPS, the website’s server presents its SSL/TLS (Transport Layer Security) certificate during the initial handshake process.

The user’s browser checks the certificate to verify its authenticity and if the certificate is signed and not expired, the browser establishes a secure connection and the user can receive the data and access the website.

Any attempts to intercept the data in transit will fail as the data is encrypted in this secure connection.

Since most browsers contain the root certificates of known and trusted CAs, the user is usually not even aware that this process is happening while accessing a secure website.

Firewall

In some cases, a potential security issue can occur even without hacking in to the SaaS application but simply knocking on it’s door in a violent way.

I am referring to DOS (Denial Of Service) or DDOS (Distributed DOS) attacks by Bots or scripts that flood a target system with network traffic which can cause it to shut down or misbehave, denying service to real users because of this.

There are some measures that can be applied within the application to manage such attacks, but for the most part it is best practice to employ a Firewall as a gate to the application for mitigation of such attacks.

Basically the Firewall is a piece of software that is designed to monitor access to your application according to a set of rules defined in advance.

For example, a classic DOS attack could simply bomb the login API of your application with made up username and passwords. This attack will cause the backend service which handles the login requests to be unavailable for ‘real’ users trying to log in.

A Firewall can mitigate such an attack by implementing some or all of the following options:

Rate Limiting — Blocking all requests from a single user once the rate of requests reaches a predefined limit (e.g. 100 in a minute)
BlackListing — Block requests from a predefined list of IP addresses or geoLocations
Monitoring — Attacks can sometimes be masked as healthy but heavy usage and load on the system. Monitoring helps to identify and analyze the traffic
CDN — Using a Content Distribution Network will help distribute the load of a DDOS attack so that the impact will be significantly smaller

Role Based Access (RBAC)

While the security measures described above are dealing mostly with access to the SaaS application, there are still levels of security that can be applied to logged in authenticated users.

Authorization is the process of granting or denying access to a set of features, capabilities and resources to a user or a group.

By granting various levels of authorization (i.e. Roles), we can securely control access within the application.

Permissions can also be used in order to create customizable roles that are made up of a set of permissions.

See in the example below how Roles (the colored rectangles) are built as a set of permissions (in the red circles) to enable specific features for the user or group: