Sponsored Content
Special Forums Cybersecurity Two Factor Authentication – Best for the UNIX/Linux Server Security Post 302998267 by bakunin on Sunday 28th of May 2017 06:21:06 PM
Old 05-28-2017
Quote:
Originally Posted by reve-secure
What is your thinking..??
OK, I'll have a take at it. A word of caution up front, though: we are a discussion forum. If you are genuinely interested in a discussion about security matters you are welcome whatever will make your stay here more enjoyable you may ask for. If, on the opposite, you think that just because you got some answer here you can use us as a free advertisement vehicle - think twice. You will be banned faster than you can spell "2FA" and we will close this thread after writing some rather negative comments about the business practices of your company (yes, we are well aware that you seem to represent a company - that is absolutely OK with us as long as you abide by the rules). These comments will stay here and will probably not have an advertising but rather the opposite effect. So, it is in your own as well as your companies interest that we get along fine.

Now, after this long introduction, lets get to the theme of the thread:

I think there are some misconceptions about "security" in general and UNIX/Linux security in particular. First, there is the "much helps much" misconception. If a 6-character password is good, then a 8-character password must be better. Or maybe would 12-characters be even better yet? And if changing the password regularly is good, wouldn't changing it more often be even better?

The usual outcome is: everybody needs to have a 12-character password with at least 7 special characters, one for every system and has to change it every other day, otherwise the account gets locked. This is so secure that it usually ends with most people having a piece of paper with their passwords under the keyboard - little unknown fact: nobody is able to memorise such password-monsters anew every second day.

Second: the "compliance"-fallacy. Instead of measuring "security" most often a system is tested to be "compliant" against some arbitrary standard, usually set forth by someone with no idea about the OS. I once had a customer who had a password rule that any password had to consist of at least three out of the four character classes: upper case, lower case, numbers, special chars.

Then they needed to audit and in the security standard it was declared that a "secure password" would consist of at least two of the character classes "upper case", "lower case" and "numbers". So, in fact they already had a system in place that guaranteed more complex passwords than were asked for. Guess what - this resulted in a "security finding" and they had to water down their rules to be "compliant". I leave it to the imagination of the reader if the purpose of security was served well with this.

Finally, and this is related to the first mentioned problem: if entering a password (or doing whatever else instead) is good, wouldn't be entering it twice be even better? When i log on to the customers site i work for right now, i have to enter: the password to log on to the client computer, then the passowrd again when i open the mail client, the the password again for the Jabber tool they are using. I might be mistaken but: let's suppose i obtained the password fraudulently - would entering the compromised password thrice instead of once slow me down in my criminal activity one bit?

bakunin
 

6 More Discussions You Might Find Interesting

1. Red Hat

microsoft Server 2008 Active authentication to a linux server

Hi, Please could someone advise I'm trying to use winscp from a Window server 2008 R2, but i need to add the authentication key to access the linux rh 5.4 servers ? What is the best way of approaching this ? If there are any web links that could help me do this, that would be good. ... (1 Reply)
Discussion started by: venhart
1 Replies

2. HP-UX

Multi-factor authentication

Is anyone here familiar with implementing multi-factor authentication on HP-UX 11.31? Either with a PIV card, or with an RSA token? We've been tasked with implementing this on our servers, but I'm not finding much in the way of products or information. To complicate matters, our servers are... (6 Replies)
Discussion started by: lupin..the..3rd
6 Replies

3. Linux

How to connect Linux server (configure two way authentication) with Windows server?

Hi my name is Manju. ->I have configure the two way authentication on my linux server. ->Now I am able to apply two way authenticator on particuler user. ->Now I want to map this linux server to my AD server. ->Kindly tell me how to map AD(Active Directory) with this linux server. ... (0 Replies)
Discussion started by: manjusharma128
0 Replies

4. UNIX and Linux Applications

UNIX and Linux authentication middleware or tools

Hi, We are looking for UNIX and Linux authentication middleware/tools which can replace our existing RSA SecurID - Two-Factor Authentication. Any suggestions or recommendations. Thanks, Gabar (2 Replies)
Discussion started by: Gabar Singh
2 Replies

5. Linux

Customized Linux Operating System with Security Authentication

Dear Gurus/Experts of UNIX/LINUX, Im Isravel from India, I've customized CentOS Installation ISO as per my new product requirements. I want to give serial key authentication to the clients who all are trying to install ISO file. Can anyone guide me how to create serial key authentication... (1 Reply)
Discussion started by: isravelraja
1 Replies

6. Solaris

User authentication failed while log in Solaris 8 client on Linux NIS server.

Based on the NIS migration tests I did and another question I posted earlier on. https://www.unix.com/solaris/272021-solaris-8-md5-encryption-support.html I tried to downgrade NIS linux encryption to DES to support solaris connection. So I modified /etc/pam.d/system-auth as below, password... (0 Replies)
Discussion started by: bestard
0 Replies
SHADOW(5)                                                  File Formats and Conversions                                                  SHADOW(5)

NAME
shadow - shadowed password file DESCRIPTION
shadow is a file which contains the password information for the system's accounts and optional aging information. This file must not be readable by regular users if password security is to be maintained. Each line of this file contains 9 fields, separated by colons (":"), in the following order: login name It must be a valid account name, which exist on the system. encrypted password Refer to crypt(3) for details on how this string is interpreted. If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in (but the user may log in the system by other means). This field may be empty, in which case no passwords are required to authenticate as the specified login name. However, some applications which read the /etc/shadow file may decide not to permit any access at all if the password field is empty. A password field which starts with an exclamation mark means that the password is locked. The remaining characters on the line represent the password field before the password was locked. date of last password change The date of the last password change, expressed as the number of days since Jan 1, 1970. The value 0 has a special meaning, which is that the user should change her password the next time she will log in the system. An empty field means that password aging features are disabled. minimum password age The minimum password age is the number of days the user will have to wait before she will be allowed to change her password again. An empty field and value 0 mean that there are no minimum password age. maximum password age The maximum password age is the number of days after which the user will have to change her password. After this number of days is elapsed, the password may still be valid. The user should be asked to change her password the next time she will log in. An empty field means that there are no maximum password age, no password warning period, and no password inactivity period (see below). If the maximum password age is lower than the minimum password age, the user cannot change her password. password warning period The number of days before a password is going to expire (see the maximum password age above) during which the user should be warned. An empty field and value 0 mean that there are no password warning period. password inactivity period The number of days after a password has expired (see the maximum password age above) during which the password should still be accepted (and the user should update her password during the next login). After expiration of the password and this expiration period is elapsed, no login is possible using the current user's password. The user should contact her administrator. An empty field means that there are no enforcement of an inactivity period. account expiration date The date of expiration of the account, expressed as the number of days since Jan 1, 1970. Note that an account expiration differs from a password expiration. In case of an account expiration, the user shall not be allowed to login. In case of a password expiration, the user is not allowed to login using her password. An empty field means that the account will never expire. The value 0 should not be used as it is interpreted as either an account with no expiration, or as an expiration on Jan 1, 1970. reserved field This field is reserved for future use. FILES
/etc/passwd User account information. /etc/shadow Secure user account information. /etc/shadow- Backup file for /etc/shadow. Note that this file is used by the tools of the shadow toolsuite, but not by all user and password management tools. SEE ALSO
chage(1), login(1), passwd(1), passwd(5), pwck(8), pwconv(8), pwunconv(8), su(1), sulogin(8). shadow-utils 4.5 01/25/2018 SHADOW(5)
All times are GMT -4. The time now is 08:55 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy