Have You Set OTP protection To Fortify Your Server Login | Carbonio CE

Server security should be top priority for any organization. Securing the login process is crucial in keeping unauthorized access at bay. Strong passwords, two-factor authentication, and limiting the number of unsuccessful login attempts can all significantly improve server security. The last thing you want is for sensitive data or private information to fall into the wrong hands due to weak login methods. Cyber threats are constantly present, and gaps in security can result in severe breaches.

• A report from Verizon shows that 81% of hacking-related breaches involve stolen or weak passwords.
• Additionally, research conducted by Google and Harris Poll indicates that 52% of users use the same password for multiple accounts, significantly elevating their vulnerability to cyber attacks.

Courtesy: https://services.google.com/fh/files/blogs/google_security_infographic.pdf

• The 2023 Verizon Data Breach Investigations Report (DBIR) emphasizes the situation’s urgency, revealing that 61% of data breaches are due to compromised credentials.
• Akamai’s findings show a staggering 193 billion credential-stuffing attacks worldwide in 2020, highlighting the extensive exploitation of vulnerable passwords.

Look at this infographic stats conducted in the USA:

Courtesy: https://storage.googleapis.com/gweb-uniblog-publish-prod/documents/PasswordCheckup-HarrisPoll-InfographicFINAL.pdf

These alarming figures underscore the urgent need to move beyond traditional password-only authentication methods. By adopting more robust solutions like key-based authentication and OTP-based SSH logins, we can significantly enhance server security and protect against relentless cyber threats. It’s time to rethink our approach to server login security and implement stronger, more reliable authentication methods.

Securing server login methods is a critical aspect of enhancing overall server security. By implementing robust login mechanisms, organizations can protect against unauthorized access, data breaches, and cyberattacks.

Commonly Used Server Login Method

Most commonly used server login methods are simple password-based authentication and key-based authentication. A report by LastPass indicates that 91% of respondents use passwords as their primary authentication method for accessing online accounts.

• Password-Based Authentication
• Key-Based Authentication

Though, there are still some more secured methods like Multi-Factor Authentication (MFA), Public Key Infrastructure (PKI), Single Sign-On (SSO) and few others. But these methods requires additional resources and advanced mechanism to deploy these methods. Therefore the bullet point mechanisms are the used methods for most of our users. So in this article, we will see how we can strengthen them:

Password-Based Authentication With OTP protection

As you all familier with the password based login method, it recommends that you need to:

• Use a minimum length of 14-character password.
• Make mandatory use both Upper & Lower case letters in a password.
• Make mandatory use of numeric characters in a password. (0-9)
• Make mandatory use of special characters in a password. (e.g. ~!@#$%^&*()_-+=)
• Do not use word or series of words from any dictionary.
• Do not use personal information (i.e. user ID, name, pet, designation etc.) in the password.
• Do not use sequential characters (i.e. 1234) or repeated characters (i.e. aaaa)
• Do not use same password in multiple sites or accounts.
• Do not reuse password if possible.
• Use passphrase instead of password using above mentioned parameters. Check out this link to know more about passphrase. You can also check out this link to generate some cool passphrase.

We have an article on how you can strengthen the user email account password. If you are interested, then you can read it here and can find many useful information including NIST Password Guidelines.

But what about adding an additional layer of securirty in this method!

I am sure you all have used OTP based authentication in many of your login methods. Then why not adding an OTP layer in your password based authentication. Let me tell you how you can do that without any additional resources:

So let’s see how we can enable OTP for our simple password based authentication.

This procedure has been tested on Ubuntu 22.04LTS.

• Install libpam-google-authenticator package in your server.

root@mail:~# apt install libpam-google-authenticator
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  linux-image-5.4.0-105-generic linux-modules-5.4.0-105-generic
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  libqrencode4
The following NEW packages will be installed:
  libpam-google-authenticator libqrencode4
0 upgraded, 2 newly installed, 0 to remove and 2 not upgraded.
Need to get 69.7 kB of archives.
After this operation, 205 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://asi-fs-d.contabo.net/ubuntu jammy/universe amd64 libqrencode4 amd64 4.1.1-1 [24.0 kB]
Get:2 http://asi-fs-d.contabo.net/ubuntu jammy/universe amd64 libpam-google-authenticator amd64 20191231-2 [45.7 k                                                 B]
Fetched 69.7 kB in 0s (1,113 kB/s)
Selecting previously unselected package libqrencode4:amd64.
(Reading database ... 150419 files and directories currently installed.)
Preparing to unpack .../libqrencode4_4.1.1-1_amd64.deb ...
Unpacking libqrencode4:amd64 (4.1.1-1) ...
Selecting previously unselected package libpam-google-authenticator.
Preparing to unpack .../libpam-google-authenticator_20191231-2_amd64.deb ...
Unpacking libpam-google-authenticator (20191231-2) ...
Setting up libqrencode4:amd64 (4.1.1-1) ...
Setting up libpam-google-authenticator (20191231-2) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for libc-bin (2.35-0ubuntu3.7) ...
root@mail:~#

• Modify the /etc/pam.d/ssh file to use Google Authenticator PAM module. Add “auth required pam_google_authenticator.so” at the end of the /etc/pam.d/ssh file.

root@mail:~# tail -n 5 /etc/pam.d/sshd
# Standard Un*x password updating.
@include common-password


auth required pam_google_authenticator.so
root@mail:~#

• Now modify the /etc/ssh/sshd_config file as mentioned below.

Change ChallengeResponseAuthentication from no to yes

Ensure that the PasswordAuthentication value is set to yes.

• Now Restart the ssh service.

• It’s time to configure te Google Authenticator.

root@mail:~# google-authenticator

Do you want authentication tokens to be time-based (y/n) y

Once you scan the code with your google authenticator app then you need to provide the code into the terminal to activate the app.

• After activating the app, you will be prompted for few more settings as follows:

Enter code from app (-1 to skip): 445566
Code confirmed
Your emergency scratch codes are:
  11223344
  55667788
  11335577
  22446688
  11336688

Do you want me to update your "/root/.google_authenticator" file? (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n) y

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) y
root@mail:~#

• With the completion of previous prompts, you are all set to use the OTP from Google Authenticator to login your server using the simple password based method.
• So now when you will try to login into your server, you will get be asked about the user and the password. But this time using the password will not be enough.

Now, insert the verification code from your Google Authenticator App to login into the server.

So that’s how you can strengthen your simple password based authentication with OTP from Google Authenticator.

Key-Based Authentication

With this type of authentication, you do not need any passwords. Therefore the attack vector for your server login reduces significantly. Let’s take a quick look at the the bullet points of the overview of this mechnism:

• Generate keys (public & private) using PuTTygen

• Once keys are generated save them in a safe location.

• So here, the private key is the secret key that should belong to the user and the privte key should be stored in the server. Therefore, only when the right private key used by the right user and it matches the public key stored in the server, only then the user will be able to logged into the server.
• let’s store the public key into the server. The designated location for storing the public key is the home diretory of the user who has the private key. In this case the user is root.

It is always the best practice to not to enable/allow root login into any server. Create any regular user, elivate it’s privillage with sudo.

If the home directory does not have the .ssh directory, then create it.

• Modify the vi /etc/ssh/sshd_config as mentioned below:

#Set UsePAM value
UsePAM no

#PermitRootLogin no
PermitRootLogin prohibit-password

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes

• Restart the ssh service

root@mail:~/.ssh# systemctl restart sshd

• So we are all set to go. Open the PuTTy.

• Go to Connection > SSH > Auth > Credentials and upload the private key and try to login.

• You will get following confirmation and will be successfully logged in.

There are some other types of authentication also but like the below mentioned ones. But these required additional resources and advanced mechanism.

• Multi-Factor Authentication (MFA)
• Public Key Infrastructure (PKI)
• Biometric Authentication
• Single Sign-On (SSO)

But if you use any one of the first two mechanism, the attack vector on your server will reduce significantly.

In today’s digital landscape, securing your server login is more critical than ever. By implementing robust authentication methods such as OTP-based and key-based authentication, you can significantly enhance the security of your Carbonio CE server. Each method offers unique advantages in mitigating attack vectors, resisting brute force attempts, and protecting against server compromises.

By combining these unbeatable tips, you unlock the ultimate security for your server, ensuring your data remains safe and your operations run smoothly. Stay ahead of potential threats and fortify your Carbonio CE server login with these proven strategies.

For more in-depth guides and expert advice on securing your IT infrastructure, keep exploring our resources. Your journey to a secure and resilient server environment starts here.