You can make a password protected folder by following the blow steps
Step-1: Create a new folder (Right-click -> New -> Folder) and give it any name of your choice. For instance I name it as ABC.
Step-2: Now in this folder place all the important files, documents or any folders that you want to password protect.
Step-3: Now Right-click on this folder (ABC) and select the option Send To -> Compressed (zipped) Folder.
Step-4: Now a new compressed zipped folder gets created next this folder (ABC) with the same name.
Step-5: Double-click on this compressed zipped folder and you should see your original folder (ABC) here.
Step-6: Now goto the File menu and select the option Add a password.
ie: File -> Add a password
Now a small window will pop up and here you can set your desired password. Once the password is set, the folder will ask for the password every time it is opened. Thus you have now created the password protected folder.
Make this folder visible
by following the steps
Step-1: Now Right-click on this password protected folder and select Properties.
Step-2: At the bottom select the option Hidden and press OK. Now your folder gets invisible (hidden).
Step-3: In order to unhide this folder go to My Computer – >Tools -> Folder options. Switch to View tab, scroll down and under Hidden files and folders you’ll see the following two options
* Do not show hidden files and folders
* Show hidden files and folders
Now select the second option and press OK. Now the invisible folder becomes visible in it’s location. To access it you need the password. To make it invisible again repeat step -1 through step-3 and select the first option and click OK. Now the folder becomes invisible once again.
Showing posts with label Password Security Guide. Show all posts
Showing posts with label Password Security Guide. Show all posts
Friday, September 24, 2010
Monday, September 13, 2010
A bounce attack occurs when a spammer obscures message origins
A bounce attack occurs when a spammer obscures message origins by using one email server to bounce spam to an address on another server. The spammer does this by inserting a target address into the “Mail From” value in the envelope of their messages then sending those messages to another address.
Symantec Brightmail Gateway product does not come configured off the box to prevent bounce attacks.
Rule of thumb before doing this configuration is that all your outgoing e-mail should be going through Brightmail Gateway so that they can processed.
So here is what you need to do to configure the Brightmail to protect you against those attacks. (This procedure is accurate for Brightmail Gateway version 9.0.x. For earlier versions, you just need to find the proper configuration points for the same actions)
We basically need to do three configuration changes to prepare for these attacks:
A. Assigning a seed value
B. Configure policy groups
C. Creating a policy
A. Assigning a seed value
B. Configure policy groups
C. Creating a policy
So, step by step, here is what we need to do:
A. Assign a Seed Value- Login to Brightmail web console.
- Navigate to Administration > Settings > Control Center. And open Certificates tab.
- Type in an 8 character alpanumeric seed into the "Bounce attack prevention seed" box.
- Click Save.
(Click on image for original size)
This seed will be used when creating validation tags for outgoing messages.
You need to do this for each Brightmail which has a Control Center role in your environment.
You need to do this for each Brightmail which has a Control Center role in your environment.
B. Configure Policy Groups
- Navigate to Administration > Users > Policy Groups.
- Select the policy group you want to process and click Edit button.
- Click on Spam tab.
- Select the check box next to the option "Enable bounce attack prevention for this policy group".
- Click Save at the bottom of the page.
(Click on image for original size)
(Click on image for original size)
If you do not configure at least one policy group, bounce attack prevention will remain disabled.
C. Create a Spam Policy
You need a spam policy to define the action when there is a bounce attack. To do so:
- Navigate to Spam > Policies > Email.
- Click Add button.
- Name the policy, for example "Bounce attack policy"
- For If the following condition is met: condition, select "If a message fails bounce attack validation". (You'll notice that "Apply to" section will change to "Inbound messages" automatically.
- As for the action, select "Reject messages failing bounce attack validation" option and click "Add Action". (This is the recommended action, but you may chose something else as per your needs)
- Select the policy group you wish this rule to be applied.
- Click Save.
(Click on image for original size)
Now your Brightmail Gateway is ready to protect your environment against bounce attacks.
A bounce attack occurs when a spammer obscures message origins
A bounce attack occurs when a spammer obscures message origins by using one email server to bounce spam to an address on another server. The spammer does this by inserting a target address into the “Mail From” value in the envelope of their messages then sending those messages to another address.
Symantec Brightmail Gateway product does not come configured off the box to prevent bounce attacks.
Rule of thumb before doing this configuration is that all your outgoing e-mail should be going through Brightmail Gateway so that they can processed.
So here is what you need to do to configure the Brightmail to protect you against those attacks. (This procedure is accurate for Brightmail Gateway version 9.0.x. For earlier versions, you just need to find the proper configuration points for the same actions)
We basically need to do three configuration changes to prepare for these attacks:
A. Assigning a seed value
B. Configure policy groups
C. Creating a policy
A. Assigning a seed value
B. Configure policy groups
C. Creating a policy
So, step by step, here is what we need to do:
A. Assign a Seed Value- Login to Brightmail web console.
- Navigate to Administration > Settings > Control Center. And open Certificates tab.
- Type in an 8 character alpanumeric seed into the "Bounce attack prevention seed" box.
- Click Save.
(Click on image for original size)
This seed will be used when creating validation tags for outgoing messages.
You need to do this for each Brightmail which has a Control Center role in your environment.
You need to do this for each Brightmail which has a Control Center role in your environment.
B. Configure Policy Groups
- Navigate to Administration > Users > Policy Groups.
- Select the policy group you want to process and click Edit button.
- Click on Spam tab.
- Select the check box next to the option "Enable bounce attack prevention for this policy group".
- Click Save at the bottom of the page.
(Click on image for original size)
(Click on image for original size)
If you do not configure at least one policy group, bounce attack prevention will remain disabled.
C. Create a Spam Policy
You need a spam policy to define the action when there is a bounce attack. To do so:
- Navigate to Spam > Policies > Email.
- Click Add button.
- Name the policy, for example "Bounce attack policy"
- For If the following condition is met: condition, select "If a message fails bounce attack validation". (You'll notice that "Apply to" section will change to "Inbound messages" automatically.
- As for the action, select "Reject messages failing bounce attack validation" option and click "Add Action". (This is the recommended action, but you may chose something else as per your needs)
- Select the policy group you wish this rule to be applied.
- Click Save.
(Click on image for original size)
Now your Brightmail Gateway is ready to protect your environment against bounce attacks.
PHP Security Guide
Exposed Access Credentials
Most PHP applications interact with a database. This usually involves connecting to a database server and using access credentials to authenticate:
$host = 'example.org';
$username = 'myuser';
$password = 'mypass';
$db = mysql_connect($host, $username, $password);
?>
This could be an example of a file called db.inc that is included whenever a connection to the database is needed. This approach is convenient, and it keeps the access credentials in a single file.
Potential problems arise when this file is somewhere within document root. This is a common approach, because it makes include and require statements much simpler, but it can lead to situations that expose your access credentials.
Remember that everything within document root has a URL associated with it. For example, if document root is /usr/local/apache/htdocs, then a file located at /usr/local/apache/htdocs/inc/db.inc has a URL such as http://example.org/inc/db.inc.
Combine this with the fact that most web servers will serve .inc files as plaintext, and the risk of exposing your access credentials should be clear. A bigger problem is that any source code in these modules can be exposed, but access credentials are particularly sensitive.
Of course, one simple solution is to place all modules outside of document root, and this is a good practice. Both include and require can accept a filesystem path, so there's no need to make modules accessible via URL. It is an unnecessary risk.
If you have no choice in the placement of your modules, and they must be within document root, you can put something like the following in your httpd.conf file (assuming Apache):
Order allow,deny
Deny from all
It is not a good idea to have your modules processed by the PHP engine. This includes renaming your modules with a .php extension as well as using AddType to have .inc files treated as PHP files. Executing code out of context can be very dangerous, because it's unexpected and can lead to unknown results. However, if your modules consist of only variable assignments (as an example), this particular risk is mitigated.
My favorite method for protecting your database access credentials is described in the PHP Cookbook (O'Reilly) by David Sklar and Adam Trachtenberg. Create a file, /path/to/secret-stuff, that only root can read (not nobody):
SetEnv DB_USER "myuser"
SetEnv DB_PASS "mypass"
Include this file within httpd.conf as follows:
Include "/path/to/secret-stuff"
Now you can use $_SERVER['DB_USER'] and $_SERVER['DB_PASS'] in your code. Not only do you never have to write your username and password in any of your scripts, the web server can't read the secret-stuff file, so no other users can write scripts to read your access credentials (regardless of language). Just be careful not to expose these variables with something like phpinfo() or print_r($_SERVER).
SQL Injection
SQL injection attacks are extremely simple to defend against, but many applications are still vulnerable. Consider the following SQL statement:
$sql = "INSERT
INTO users (reg_username,
reg_password,
reg_email)
VALUES ('{$_POST['reg_username']}',
'$reg_password',
'{$_POST['reg_email']}')";
?>
This query is constructed with $_POST, which should immediately look suspicious.
Assume that this query is creating a new account. The user provides a desired username and an email address. The registration application generates a temporary password and emails it to the user to verify the email address. Imagine that the user enters the following as a username:
bad_guy', 'mypass', ''), ('good_guy
This certainly doesn't look like a valid username, but with no data filtering in place, the application can't tell. If a valid email address is given (shiflett@php.net, for example), and 1234 is what the application generates for the password, the SQL statement becomes the following:
$sql = "INSERT
INTO users (reg_username,
reg_password,
reg_email)
VALUES ('bad_guy', 'mypass', ''), ('good_guy',
'1234',
'shiflett@php.net')"; ?>
Rather than the intended action of creating a single account (good_guy) with a valid email address, the application has been tricked into creating two accounts, and the user supplied every detail of the bad_guy account.
While this particular example might not seem so harmful, it should be clear that worse things could happen once an attacker can make modifications to your SQL statements.
For example, depending on the database you are using, it might be possible to send multiple queries to the database server in a single call. Thus, a user can potentially terminate the existing query with a semicolon and follow this with a query of the user's choosing.
MySQL, until recently, does not allow multiple queries, so this particular risk is mitigated. Newer versions of MySQL allow multiple queries, but the corresponding PHP extension (ext/mysqli) requires that you use a separate function if you want to send multiple queries (mysqli_multi_query() instead of mysqli_query()). Only allowing a single query is safer, because it limits what an attacker can potentially do.
Protecting against SQL injection is easy:
Filter your data.
This cannot be overstressed. With good data filtering in place, most security concerns are mitigated, and some are practically eliminated.
Quote your data.
If your database allows it (MySQL does), put single quotes around all values in your SQL statements, regardless of the data type.
Escape your data.
Sometimes valid data can unintentionally interfere with the format of the SQL statement itself. Use mysql_escape_string() or an escaping function native to your particular database. If there isn't a specific one, addslashes() is a good last resort.
PHP Security Guide
Exposed Access Credentials
Most PHP applications interact with a database. This usually involves connecting to a database server and using access credentials to authenticate:
$host = 'example.org';
$username = 'myuser';
$password = 'mypass';
$db = mysql_connect($host, $username, $password);
?>
This could be an example of a file called db.inc that is included whenever a connection to the database is needed. This approach is convenient, and it keeps the access credentials in a single file.
Potential problems arise when this file is somewhere within document root. This is a common approach, because it makes include and require statements much simpler, but it can lead to situations that expose your access credentials.
Remember that everything within document root has a URL associated with it. For example, if document root is /usr/local/apache/htdocs, then a file located at /usr/local/apache/htdocs/inc/db.inc has a URL such as http://example.org/inc/db.inc.
Combine this with the fact that most web servers will serve .inc files as plaintext, and the risk of exposing your access credentials should be clear. A bigger problem is that any source code in these modules can be exposed, but access credentials are particularly sensitive.
Of course, one simple solution is to place all modules outside of document root, and this is a good practice. Both include and require can accept a filesystem path, so there's no need to make modules accessible via URL. It is an unnecessary risk.
If you have no choice in the placement of your modules, and they must be within document root, you can put something like the following in your httpd.conf file (assuming Apache):
Order allow,deny
Deny from all
It is not a good idea to have your modules processed by the PHP engine. This includes renaming your modules with a .php extension as well as using AddType to have .inc files treated as PHP files. Executing code out of context can be very dangerous, because it's unexpected and can lead to unknown results. However, if your modules consist of only variable assignments (as an example), this particular risk is mitigated.
My favorite method for protecting your database access credentials is described in the PHP Cookbook (O'Reilly) by David Sklar and Adam Trachtenberg. Create a file, /path/to/secret-stuff, that only root can read (not nobody):
SetEnv DB_USER "myuser"
SetEnv DB_PASS "mypass"
Include this file within httpd.conf as follows:
Include "/path/to/secret-stuff"
Now you can use $_SERVER['DB_USER'] and $_SERVER['DB_PASS'] in your code. Not only do you never have to write your username and password in any of your scripts, the web server can't read the secret-stuff file, so no other users can write scripts to read your access credentials (regardless of language). Just be careful not to expose these variables with something like phpinfo() or print_r($_SERVER).
SQL Injection
SQL injection attacks are extremely simple to defend against, but many applications are still vulnerable. Consider the following SQL statement:
$sql = "INSERT
INTO users (reg_username,
reg_password,
reg_email)
VALUES ('{$_POST['reg_username']}',
'$reg_password',
'{$_POST['reg_email']}')";
?>
This query is constructed with $_POST, which should immediately look suspicious.
Assume that this query is creating a new account. The user provides a desired username and an email address. The registration application generates a temporary password and emails it to the user to verify the email address. Imagine that the user enters the following as a username:
bad_guy', 'mypass', ''), ('good_guy
This certainly doesn't look like a valid username, but with no data filtering in place, the application can't tell. If a valid email address is given (shiflett@php.net, for example), and 1234 is what the application generates for the password, the SQL statement becomes the following:
$sql = "INSERT
INTO users (reg_username,
reg_password,
reg_email)
VALUES ('bad_guy', 'mypass', ''), ('good_guy',
'1234',
'shiflett@php.net')"; ?>
Rather than the intended action of creating a single account (good_guy) with a valid email address, the application has been tricked into creating two accounts, and the user supplied every detail of the bad_guy account.
While this particular example might not seem so harmful, it should be clear that worse things could happen once an attacker can make modifications to your SQL statements.
For example, depending on the database you are using, it might be possible to send multiple queries to the database server in a single call. Thus, a user can potentially terminate the existing query with a semicolon and follow this with a query of the user's choosing.
MySQL, until recently, does not allow multiple queries, so this particular risk is mitigated. Newer versions of MySQL allow multiple queries, but the corresponding PHP extension (ext/mysqli) requires that you use a separate function if you want to send multiple queries (mysqli_multi_query() instead of mysqli_query()). Only allowing a single query is safer, because it limits what an attacker can potentially do.
Protecting against SQL injection is easy:
Filter your data.
This cannot be overstressed. With good data filtering in place, most security concerns are mitigated, and some are practically eliminated.
Quote your data.
If your database allows it (MySQL does), put single quotes around all values in your SQL statements, regardless of the data type.
Escape your data.
Sometimes valid data can unintentionally interfere with the format of the SQL statement itself. Use mysql_escape_string() or an escaping function native to your particular database. If there isn't a specific one, addslashes() is a good last resort.
Password Security Guide
Passwords are the primary way Red Hat Linux verifies that the user logging into the system is who he claims to be. This is why password security is enormously important for protection of the user, the workstation, and the network.
For security purposes, the Red Hat Linux installation program defaults to using the Message-Digest Algorithm (MD5) and shadow passwords. It is highly recommended that you do not alter these settings.
If you deselect MD5 passwords during installation, the older Data Encryption Standard (DES) format is used. This format limits passwords to eight alphanumeric character passwords (disallowing punctuation and other special characters) and provides a modest 56-bit level of encryption.
If you deselect shadow passwords, all user passwords will be stored as a one-way hash in the world-readable file /etc/passwd. This opens up your system to offline password cracking attacks. If an intruder can gain access to the machine as a regular user, he can view the /etc/passwd file and run any number of password cracking programs against it on his own machine. If there is an insecure password in the file, it is only a matter of time before the password cracker discovers it.
Shadow passwords eliminate this type of attack by storing the password hashes in the file /etc/shadow which is readable only by the root user.
This forces a potential attacker to attempt password cracking remotely by logging into a network service on the machine, such as SSH or FTP. This sort of brute-force attack is much slower and leaves an obvious trail as hundreds of failed login attempts will appear in the log files. Of course, if the cracker starts an attack in the middle of the night and you have weak passwords, he may have gained access before dawn.
Beyond matters of format and storage is the issue of content. The single most important thing a user can do to protect his account is create a strong password, which make it less susceptible to a password cracking attack.
For security purposes, the Red Hat Linux installation program defaults to using the Message-Digest Algorithm (MD5) and shadow passwords. It is highly recommended that you do not alter these settings.
If you deselect MD5 passwords during installation, the older Data Encryption Standard (DES) format is used. This format limits passwords to eight alphanumeric character passwords (disallowing punctuation and other special characters) and provides a modest 56-bit level of encryption.
If you deselect shadow passwords, all user passwords will be stored as a one-way hash in the world-readable file /etc/passwd. This opens up your system to offline password cracking attacks. If an intruder can gain access to the machine as a regular user, he can view the /etc/passwd file and run any number of password cracking programs against it on his own machine. If there is an insecure password in the file, it is only a matter of time before the password cracker discovers it.
Shadow passwords eliminate this type of attack by storing the password hashes in the file /etc/shadow which is readable only by the root user.
This forces a potential attacker to attempt password cracking remotely by logging into a network service on the machine, such as SSH or FTP. This sort of brute-force attack is much slower and leaves an obvious trail as hundreds of failed login attempts will appear in the log files. Of course, if the cracker starts an attack in the middle of the night and you have weak passwords, he may have gained access before dawn.
Beyond matters of format and storage is the issue of content. The single most important thing a user can do to protect his account is create a strong password, which make it less susceptible to a password cracking attack.
Password Security Guide
Passwords are the primary way Red Hat Linux verifies that the user logging into the system is who he claims to be. This is why password security is enormously important for protection of the user, the workstation, and the network.
For security purposes, the Red Hat Linux installation program defaults to using the Message-Digest Algorithm (MD5) and shadow passwords. It is highly recommended that you do not alter these settings.
If you deselect MD5 passwords during installation, the older Data Encryption Standard (DES) format is used. This format limits passwords to eight alphanumeric character passwords (disallowing punctuation and other special characters) and provides a modest 56-bit level of encryption.
If you deselect shadow passwords, all user passwords will be stored as a one-way hash in the world-readable file /etc/passwd. This opens up your system to offline password cracking attacks. If an intruder can gain access to the machine as a regular user, he can view the /etc/passwd file and run any number of password cracking programs against it on his own machine. If there is an insecure password in the file, it is only a matter of time before the password cracker discovers it.
Shadow passwords eliminate this type of attack by storing the password hashes in the file /etc/shadow which is readable only by the root user.
This forces a potential attacker to attempt password cracking remotely by logging into a network service on the machine, such as SSH or FTP. This sort of brute-force attack is much slower and leaves an obvious trail as hundreds of failed login attempts will appear in the log files. Of course, if the cracker starts an attack in the middle of the night and you have weak passwords, he may have gained access before dawn.
Beyond matters of format and storage is the issue of content. The single most important thing a user can do to protect his account is create a strong password, which make it less susceptible to a password cracking attack.
For security purposes, the Red Hat Linux installation program defaults to using the Message-Digest Algorithm (MD5) and shadow passwords. It is highly recommended that you do not alter these settings.
If you deselect MD5 passwords during installation, the older Data Encryption Standard (DES) format is used. This format limits passwords to eight alphanumeric character passwords (disallowing punctuation and other special characters) and provides a modest 56-bit level of encryption.
If you deselect shadow passwords, all user passwords will be stored as a one-way hash in the world-readable file /etc/passwd. This opens up your system to offline password cracking attacks. If an intruder can gain access to the machine as a regular user, he can view the /etc/passwd file and run any number of password cracking programs against it on his own machine. If there is an insecure password in the file, it is only a matter of time before the password cracker discovers it.
Shadow passwords eliminate this type of attack by storing the password hashes in the file /etc/shadow which is readable only by the root user.
This forces a potential attacker to attempt password cracking remotely by logging into a network service on the machine, such as SSH or FTP. This sort of brute-force attack is much slower and leaves an obvious trail as hundreds of failed login attempts will appear in the log files. Of course, if the cracker starts an attack in the middle of the night and you have weak passwords, he may have gained access before dawn.
Beyond matters of format and storage is the issue of content. The single most important thing a user can do to protect his account is create a strong password, which make it less susceptible to a password cracking attack.
Password protection Guide
Ever wanted a specific directory in your site to be available only to people who you want it to be available to? Ever got frustrated with the seeming holes in client-side options for this that allowed virtually anyone with enough skill to mess around in your source to get in? htaccess is the answer!
There are numerous methods to password protecting areas of your site, some server language based (such as ASP, PHP or PERL) and client side based, such as JavaScript. JavaScript is not as secure or foolproof as a server-side option, a server side challenge/response is always more secure than a client dependant challenge/response. htaccess is about as secure as you can or need to get in everyday life, though there are ways above and beyond even that of htaccess. If you aren't comfortable enough with htaccess, you can password protect your pages any number of ways, and JavaScript Kit has plenty of password protection scripts for your use.
The first thing you will need to do is create a file called .htpasswd. I know, you might have problems with the naming convention, but it is the same idea behind naming the htaccess file itself, and you should be able to do that by this point. In the htpasswd file, you place the username and password (which is encrypted) for those whom you want to have access.
For example, a username and password of wsabstract (and I do not recommend having the username being the same as the password), the htpasswd file would look like this:
wsabstract:y4E7Ep8e7EYV
Notice that it is UserName first, followed by the Password. There is a handy-dandy tool available for you to easily encrypt the password into the proper encoding for use in the httpasswd file.
For security, you should not upload the htpasswd file to a directory that is web accessible (yoursite.com/.htpasswd), it should be placed above your www root directory. You'll be specifying the location to it later on, so be sure you know where you put it. Also, this file, as with htaccess, should be uploaded as ASCII and not BINARY.
Create a new htaccess file and place the following code in it:
AuthUserFile /usr/local/you/safedir/.htpasswd
AuthGroupFile /dev/null
AuthName EnterPassword
AuthType Basic
require user wsabstract
The first line is the full server path to your htpasswd file. If you have installed scripts on your server, you should be familiar with this. Please note that this is not a URL, this is a server path. Also note that if you place this htaccess file in your root directory, it will password protect your entire site, which probably isn't your exact goal.
The second to last line require user is where you enter the username of those who you want to have access to that portion of your site. Note that using this will allow only that specific user to be able to access that directory. This applies if you had an htpasswd file that had multiple users setup in it and you wanted each one to have access to an individual directory. If you wanted the entire list of users to have access to that directory, you would replace Require user xxx with require valid-user.
The AuthName is the name of the area you want to access. It could anything, such as "EnterPassword". You can change the name of this 'realm' to whatever you want, within reason.
There are numerous methods to password protecting areas of your site, some server language based (such as ASP, PHP or PERL) and client side based, such as JavaScript. JavaScript is not as secure or foolproof as a server-side option, a server side challenge/response is always more secure than a client dependant challenge/response. htaccess is about as secure as you can or need to get in everyday life, though there are ways above and beyond even that of htaccess. If you aren't comfortable enough with htaccess, you can password protect your pages any number of ways, and JavaScript Kit has plenty of password protection scripts for your use.
The first thing you will need to do is create a file called .htpasswd. I know, you might have problems with the naming convention, but it is the same idea behind naming the htaccess file itself, and you should be able to do that by this point. In the htpasswd file, you place the username and password (which is encrypted) for those whom you want to have access.
For example, a username and password of wsabstract (and I do not recommend having the username being the same as the password), the htpasswd file would look like this:
wsabstract:y4E7Ep8e7EYV
Notice that it is UserName first, followed by the Password. There is a handy-dandy tool available for you to easily encrypt the password into the proper encoding for use in the httpasswd file.
For security, you should not upload the htpasswd file to a directory that is web accessible (yoursite.com/.htpasswd), it should be placed above your www root directory. You'll be specifying the location to it later on, so be sure you know where you put it. Also, this file, as with htaccess, should be uploaded as ASCII and not BINARY.
Create a new htaccess file and place the following code in it:
AuthUserFile /usr/local/you/safedir/.htpasswd
AuthGroupFile /dev/null
AuthName EnterPassword
AuthType Basic
require user wsabstract
The first line is the full server path to your htpasswd file. If you have installed scripts on your server, you should be familiar with this. Please note that this is not a URL, this is a server path. Also note that if you place this htaccess file in your root directory, it will password protect your entire site, which probably isn't your exact goal.
The second to last line require user is where you enter the username of those who you want to have access to that portion of your site. Note that using this will allow only that specific user to be able to access that directory. This applies if you had an htpasswd file that had multiple users setup in it and you wanted each one to have access to an individual directory. If you wanted the entire list of users to have access to that directory, you would replace Require user xxx with require valid-user.
The AuthName is the name of the area you want to access. It could anything, such as "EnterPassword". You can change the name of this 'realm' to whatever you want, within reason.
Password protection Guide
Ever wanted a specific directory in your site to be available only to people who you want it to be available to? Ever got frustrated with the seeming holes in client-side options for this that allowed virtually anyone with enough skill to mess around in your source to get in? htaccess is the answer!
There are numerous methods to password protecting areas of your site, some server language based (such as ASP, PHP or PERL) and client side based, such as JavaScript. JavaScript is not as secure or foolproof as a server-side option, a server side challenge/response is always more secure than a client dependant challenge/response. htaccess is about as secure as you can or need to get in everyday life, though there are ways above and beyond even that of htaccess. If you aren't comfortable enough with htaccess, you can password protect your pages any number of ways, and JavaScript Kit has plenty of password protection scripts for your use.
The first thing you will need to do is create a file called .htpasswd. I know, you might have problems with the naming convention, but it is the same idea behind naming the htaccess file itself, and you should be able to do that by this point. In the htpasswd file, you place the username and password (which is encrypted) for those whom you want to have access.
For example, a username and password of wsabstract (and I do not recommend having the username being the same as the password), the htpasswd file would look like this:
wsabstract:y4E7Ep8e7EYV
Notice that it is UserName first, followed by the Password. There is a handy-dandy tool available for you to easily encrypt the password into the proper encoding for use in the httpasswd file.
For security, you should not upload the htpasswd file to a directory that is web accessible (yoursite.com/.htpasswd), it should be placed above your www root directory. You'll be specifying the location to it later on, so be sure you know where you put it. Also, this file, as with htaccess, should be uploaded as ASCII and not BINARY.
Create a new htaccess file and place the following code in it:
AuthUserFile /usr/local/you/safedir/.htpasswd
AuthGroupFile /dev/null
AuthName EnterPassword
AuthType Basic
require user wsabstract
The first line is the full server path to your htpasswd file. If you have installed scripts on your server, you should be familiar with this. Please note that this is not a URL, this is a server path. Also note that if you place this htaccess file in your root directory, it will password protect your entire site, which probably isn't your exact goal.
The second to last line require user is where you enter the username of those who you want to have access to that portion of your site. Note that using this will allow only that specific user to be able to access that directory. This applies if you had an htpasswd file that had multiple users setup in it and you wanted each one to have access to an individual directory. If you wanted the entire list of users to have access to that directory, you would replace Require user xxx with require valid-user.
The AuthName is the name of the area you want to access. It could anything, such as "EnterPassword". You can change the name of this 'realm' to whatever you want, within reason.
There are numerous methods to password protecting areas of your site, some server language based (such as ASP, PHP or PERL) and client side based, such as JavaScript. JavaScript is not as secure or foolproof as a server-side option, a server side challenge/response is always more secure than a client dependant challenge/response. htaccess is about as secure as you can or need to get in everyday life, though there are ways above and beyond even that of htaccess. If you aren't comfortable enough with htaccess, you can password protect your pages any number of ways, and JavaScript Kit has plenty of password protection scripts for your use.
The first thing you will need to do is create a file called .htpasswd. I know, you might have problems with the naming convention, but it is the same idea behind naming the htaccess file itself, and you should be able to do that by this point. In the htpasswd file, you place the username and password (which is encrypted) for those whom you want to have access.
For example, a username and password of wsabstract (and I do not recommend having the username being the same as the password), the htpasswd file would look like this:
wsabstract:y4E7Ep8e7EYV
Notice that it is UserName first, followed by the Password. There is a handy-dandy tool available for you to easily encrypt the password into the proper encoding for use in the httpasswd file.
For security, you should not upload the htpasswd file to a directory that is web accessible (yoursite.com/.htpasswd), it should be placed above your www root directory. You'll be specifying the location to it later on, so be sure you know where you put it. Also, this file, as with htaccess, should be uploaded as ASCII and not BINARY.
Create a new htaccess file and place the following code in it:
AuthUserFile /usr/local/you/safedir/.htpasswd
AuthGroupFile /dev/null
AuthName EnterPassword
AuthType Basic
require user wsabstract
The first line is the full server path to your htpasswd file. If you have installed scripts on your server, you should be familiar with this. Please note that this is not a URL, this is a server path. Also note that if you place this htaccess file in your root directory, it will password protect your entire site, which probably isn't your exact goal.
The second to last line require user is where you enter the username of those who you want to have access to that portion of your site. Note that using this will allow only that specific user to be able to access that directory. This applies if you had an htpasswd file that had multiple users setup in it and you wanted each one to have access to an individual directory. If you wanted the entire list of users to have access to that directory, you would replace Require user xxx with require valid-user.
The AuthName is the name of the area you want to access. It could anything, such as "EnterPassword". You can change the name of this 'realm' to whatever you want, within reason.
Password Security Guide
Password Security
Passwords are the primary method Red Hat Enterprise Linux uses to verify a user's identity. This is why password security is enormously important for protection of the user, the workstation, and the network.
For security purposes, the installation program configures the system to use Message-Digest Algorithm (MD5) and shadow passwords. It is highly recommended that you do not alter these settings.
If MD5 passwords are deselected during installation, the older Data Encryption Standard (DES) format is used. This format limits passwords to eight alphanumeric character passwords (disallowing punctuation and other special characters) and provides a modest 56-bit level of encryption.
If shadow passwords are deselected during installation, all passwords are stored as a one-way hash in the world-readable /etc/passwd file, which makes the system vulnerable to offline password cracking attacks. If an intruder can gain access to the machine as a regular user, he can copy the /etc/passwd file to his own machine and run any number of password cracking programs against it. If there is an insecure password in the file, it is only a matter of time before the password cracker discovers it.
Shadow passwords eliminate this type of attack by storing the password hashes in the file /etc/shadow, which is readable only by the root user.
This forces a potential attacker to attempt password cracking remotely by logging into a network service on the machine, such as SSH or FTP. This sort of brute-force attack is much slower and leaves an obvious trail as hundreds of failed login attempts are written to system files. Of course, if the cracker starts an attack in the middle of the night on a system with weak passwords, the cracker may have gained access before dawn and edited the log files to cover his tracks.
Beyond matters of format and storage is the issue of content. The single most important thing a user can do to protect his account against a password cracking attack is create a strong password.
Creating Strong Passwords
When creating a secure password, it is a good idea to follow these guidelines:
Do Not Do the Following:
Do Not Use Only Words or Numbers — Never use only numbers or words in a password.
Some insecure examples include the following:
8675309
juan
hackme
Do Not Use Recognizable Words — Words such as proper names, dictionary words, or even terms from television shows or novels should be avoided, even if they are bookended with numbers.
Some insecure examples include the following:
john1
DS-9
mentat123
Do Not Use Words in Foreign Languages — Password cracking programs often check against word lists that encompass dictionaries of many languages. Relying on foreign languages for secure passwords is not secure.
Some insecure examples include the following:
cheguevara
bienvenido1
1dumbKopf
Do Not Use Hacker Terminology — If you think you are elite because you use hacker terminology — also called l337 (LEET) speak — in your password, think again. Many word lists include LEET speak.
Some insecure examples include the following:
H4X0R
1337
Do Not Use Personal Information — Steer clear of personal information. If the attacker knows your identity, the task of deducing your password becomes easier. The following is a list of the types of information to avoid when creating a password:
Some insecure examples include the following:
Your name
The names of pets
The names of family members
Any birth dates
Your phone number or zip code
Do Not Invert Recognizable Words — Good password checkers always reverse common words, so inverting a bad password does not make it any more secure.
Some insecure examples include the following:
R0X4H
nauj
9-DS
Do Not Write Down Your Password — Never store a password on paper. It is much safer to memorize it.
Do Not Use the Same Password For All Machines — It is important to make separate passwords for each machine. This way if one system is compromised, all of your machines are not immediately at risk.
Do the Following:
Make the Password At Least Eight Characters Long — The longer the password, the better. If using MD5 passwords, it should be 15 characters or longer. With DES passwords, use the maximum length (eight characters).
Mix Upper and Lower Case Letters — Red Hat Enterprise Linux is case sensitive, so mix cases to enhance the strength of the password.
Mix Letters and Numbers — Adding numbers to passwords, especially when added to the middle (not just at the beginning or the end), can enhance password strength.
Include Non-Alphanumeric Characters — Special characters such as &, $, and > can greatly improve the strength of a password (this is not possible if using DES passwords).
Pick a Password You Can Remember — The best password in the world does little good if you cannot remember it; use acronyms or other mnemonic devices to aid in memorizing passwords.
With all these rules, it may seem difficult to create a password meeting all of the criteria for good passwords while avoiding the traits of a bad one. Fortunately, there are some steps one can take to generate a memorable, secure password.
Secure Password Creation Methodology
There are many methods people use to create secure passwords. One of the more popular methods involves acronyms. For example:
Think of a memorable phrase, such as:
"over the river and through the woods, to grandmother's house we go."
Next, turn it into an acronym (including the punctuation).
otrattw,tghwg.
Add complexity by substituting numbers and symbols for letters in the acronym. For example, substitute 7 for t and the at symbol (@) for a:
o7r@77w,7ghwg.
Add more complexity by capitalizing at least one letter, such as H.
o7r@77w,7gHwg.
Finally, do not use the example password above for any systems, ever.
While creating secure passwords is imperative, managing them properly is also important, especially for system administrators within larger organizations. The following section details good practices for creating and managing user passwords within an organization.
Creating User Passwords Within an Organization
If there are a significant number of users within an organization, the system administrators have two basic options available to force the use of good passwords. They can create passwords for the user, or they can let users create their own passwords, while verifying the passwords are of acceptable quality.
Creating the passwords for the users ensures that the passwords are good, but it becomes a daunting task as the organization grows. It also increases the risk of users writing their passwords down.
For these reasons, most system administrators prefer to have the users create their own passwords, but actively verify that the passwords are good and, in some cases, force users to change their passwords periodically through password aging.
Forcing Strong Passwords
To protect the network from intrusion it is a good idea for system administrators to verify that the passwords used within an organization are strong ones. When users are asked to create or change passwords, they can use the command line application passwd, which is Pluggable Authentication Manager (PAM) aware and therefore checks to see if the password is easy to crack or too short in length via the pam_cracklib.so PAM module. Since PAM is customizable, it is possible to add further password integrity checkers, such as pam_passwdqc (available from http://www.openwall.com/passwdqc/) or to write a new module. For a list of available PAM modules, refer to http://www.kernel.org/pub/linux/libs/pam/modules.html. For more information about PAM, refer to the chapter titled Pluggable Authentication Modules (PAM) in the Red Hat Enterprise Linux Reference Guide.
It should be noted, however, that the check performed on passwords at the time of their creation does not discover bad passwords as effectively as running a password cracking program against the passwords within the organization.
There are many password cracking programs that run under Red Hat Enterprise Linux although none ship with the operating system. Below is a brief list of some of the more popular password cracking programs:
Passwords are the primary method Red Hat Enterprise Linux uses to verify a user's identity. This is why password security is enormously important for protection of the user, the workstation, and the network.
For security purposes, the installation program configures the system to use Message-Digest Algorithm (MD5) and shadow passwords. It is highly recommended that you do not alter these settings.
If MD5 passwords are deselected during installation, the older Data Encryption Standard (DES) format is used. This format limits passwords to eight alphanumeric character passwords (disallowing punctuation and other special characters) and provides a modest 56-bit level of encryption.
If shadow passwords are deselected during installation, all passwords are stored as a one-way hash in the world-readable /etc/passwd file, which makes the system vulnerable to offline password cracking attacks. If an intruder can gain access to the machine as a regular user, he can copy the /etc/passwd file to his own machine and run any number of password cracking programs against it. If there is an insecure password in the file, it is only a matter of time before the password cracker discovers it.
Shadow passwords eliminate this type of attack by storing the password hashes in the file /etc/shadow, which is readable only by the root user.
This forces a potential attacker to attempt password cracking remotely by logging into a network service on the machine, such as SSH or FTP. This sort of brute-force attack is much slower and leaves an obvious trail as hundreds of failed login attempts are written to system files. Of course, if the cracker starts an attack in the middle of the night on a system with weak passwords, the cracker may have gained access before dawn and edited the log files to cover his tracks.
Beyond matters of format and storage is the issue of content. The single most important thing a user can do to protect his account against a password cracking attack is create a strong password.
Creating Strong Passwords
When creating a secure password, it is a good idea to follow these guidelines:
Do Not Do the Following:
Do Not Use Only Words or Numbers — Never use only numbers or words in a password.
Some insecure examples include the following:
8675309
juan
hackme
Do Not Use Recognizable Words — Words such as proper names, dictionary words, or even terms from television shows or novels should be avoided, even if they are bookended with numbers.
Some insecure examples include the following:
john1
DS-9
mentat123
Do Not Use Words in Foreign Languages — Password cracking programs often check against word lists that encompass dictionaries of many languages. Relying on foreign languages for secure passwords is not secure.
Some insecure examples include the following:
cheguevara
bienvenido1
1dumbKopf
Do Not Use Hacker Terminology — If you think you are elite because you use hacker terminology — also called l337 (LEET) speak — in your password, think again. Many word lists include LEET speak.
Some insecure examples include the following:
H4X0R
1337
Do Not Use Personal Information — Steer clear of personal information. If the attacker knows your identity, the task of deducing your password becomes easier. The following is a list of the types of information to avoid when creating a password:
Some insecure examples include the following:
Your name
The names of pets
The names of family members
Any birth dates
Your phone number or zip code
Do Not Invert Recognizable Words — Good password checkers always reverse common words, so inverting a bad password does not make it any more secure.
Some insecure examples include the following:
R0X4H
nauj
9-DS
Do Not Write Down Your Password — Never store a password on paper. It is much safer to memorize it.
Do Not Use the Same Password For All Machines — It is important to make separate passwords for each machine. This way if one system is compromised, all of your machines are not immediately at risk.
Do the Following:
Make the Password At Least Eight Characters Long — The longer the password, the better. If using MD5 passwords, it should be 15 characters or longer. With DES passwords, use the maximum length (eight characters).
Mix Upper and Lower Case Letters — Red Hat Enterprise Linux is case sensitive, so mix cases to enhance the strength of the password.
Mix Letters and Numbers — Adding numbers to passwords, especially when added to the middle (not just at the beginning or the end), can enhance password strength.
Include Non-Alphanumeric Characters — Special characters such as &, $, and > can greatly improve the strength of a password (this is not possible if using DES passwords).
Pick a Password You Can Remember — The best password in the world does little good if you cannot remember it; use acronyms or other mnemonic devices to aid in memorizing passwords.
With all these rules, it may seem difficult to create a password meeting all of the criteria for good passwords while avoiding the traits of a bad one. Fortunately, there are some steps one can take to generate a memorable, secure password.
Secure Password Creation Methodology
There are many methods people use to create secure passwords. One of the more popular methods involves acronyms. For example:
Think of a memorable phrase, such as:
"over the river and through the woods, to grandmother's house we go."
Next, turn it into an acronym (including the punctuation).
otrattw,tghwg.
Add complexity by substituting numbers and symbols for letters in the acronym. For example, substitute 7 for t and the at symbol (@) for a:
o7r@77w,7ghwg.
Add more complexity by capitalizing at least one letter, such as H.
o7r@77w,7gHwg.
Finally, do not use the example password above for any systems, ever.
While creating secure passwords is imperative, managing them properly is also important, especially for system administrators within larger organizations. The following section details good practices for creating and managing user passwords within an organization.
Creating User Passwords Within an Organization
If there are a significant number of users within an organization, the system administrators have two basic options available to force the use of good passwords. They can create passwords for the user, or they can let users create their own passwords, while verifying the passwords are of acceptable quality.
Creating the passwords for the users ensures that the passwords are good, but it becomes a daunting task as the organization grows. It also increases the risk of users writing their passwords down.
For these reasons, most system administrators prefer to have the users create their own passwords, but actively verify that the passwords are good and, in some cases, force users to change their passwords periodically through password aging.
Forcing Strong Passwords
To protect the network from intrusion it is a good idea for system administrators to verify that the passwords used within an organization are strong ones. When users are asked to create or change passwords, they can use the command line application passwd, which is Pluggable Authentication Manager (PAM) aware and therefore checks to see if the password is easy to crack or too short in length via the pam_cracklib.so PAM module. Since PAM is customizable, it is possible to add further password integrity checkers, such as pam_passwdqc (available from http://www.openwall.com/passwdqc/) or to write a new module. For a list of available PAM modules, refer to http://www.kernel.org/pub/linux/libs/pam/modules.html. For more information about PAM, refer to the chapter titled Pluggable Authentication Modules (PAM) in the Red Hat Enterprise Linux Reference Guide.
It should be noted, however, that the check performed on passwords at the time of their creation does not discover bad passwords as effectively as running a password cracking program against the passwords within the organization.
There are many password cracking programs that run under Red Hat Enterprise Linux although none ship with the operating system. Below is a brief list of some of the more popular password cracking programs:
Password Security Guide
Password Security
Passwords are the primary method Red Hat Enterprise Linux uses to verify a user's identity. This is why password security is enormously important for protection of the user, the workstation, and the network.
For security purposes, the installation program configures the system to use Message-Digest Algorithm (MD5) and shadow passwords. It is highly recommended that you do not alter these settings.
If MD5 passwords are deselected during installation, the older Data Encryption Standard (DES) format is used. This format limits passwords to eight alphanumeric character passwords (disallowing punctuation and other special characters) and provides a modest 56-bit level of encryption.
If shadow passwords are deselected during installation, all passwords are stored as a one-way hash in the world-readable /etc/passwd file, which makes the system vulnerable to offline password cracking attacks. If an intruder can gain access to the machine as a regular user, he can copy the /etc/passwd file to his own machine and run any number of password cracking programs against it. If there is an insecure password in the file, it is only a matter of time before the password cracker discovers it.
Shadow passwords eliminate this type of attack by storing the password hashes in the file /etc/shadow, which is readable only by the root user.
This forces a potential attacker to attempt password cracking remotely by logging into a network service on the machine, such as SSH or FTP. This sort of brute-force attack is much slower and leaves an obvious trail as hundreds of failed login attempts are written to system files. Of course, if the cracker starts an attack in the middle of the night on a system with weak passwords, the cracker may have gained access before dawn and edited the log files to cover his tracks.
Beyond matters of format and storage is the issue of content. The single most important thing a user can do to protect his account against a password cracking attack is create a strong password.
Creating Strong Passwords
When creating a secure password, it is a good idea to follow these guidelines:
Do Not Do the Following:
Do Not Use Only Words or Numbers — Never use only numbers or words in a password.
Some insecure examples include the following:
8675309
juan
hackme
Do Not Use Recognizable Words — Words such as proper names, dictionary words, or even terms from television shows or novels should be avoided, even if they are bookended with numbers.
Some insecure examples include the following:
john1
DS-9
mentat123
Do Not Use Words in Foreign Languages — Password cracking programs often check against word lists that encompass dictionaries of many languages. Relying on foreign languages for secure passwords is not secure.
Some insecure examples include the following:
cheguevara
bienvenido1
1dumbKopf
Do Not Use Hacker Terminology — If you think you are elite because you use hacker terminology — also called l337 (LEET) speak — in your password, think again. Many word lists include LEET speak.
Some insecure examples include the following:
H4X0R
1337
Do Not Use Personal Information — Steer clear of personal information. If the attacker knows your identity, the task of deducing your password becomes easier. The following is a list of the types of information to avoid when creating a password:
Some insecure examples include the following:
Your name
The names of pets
The names of family members
Any birth dates
Your phone number or zip code
Do Not Invert Recognizable Words — Good password checkers always reverse common words, so inverting a bad password does not make it any more secure.
Some insecure examples include the following:
R0X4H
nauj
9-DS
Do Not Write Down Your Password — Never store a password on paper. It is much safer to memorize it.
Do Not Use the Same Password For All Machines — It is important to make separate passwords for each machine. This way if one system is compromised, all of your machines are not immediately at risk.
Do the Following:
Make the Password At Least Eight Characters Long — The longer the password, the better. If using MD5 passwords, it should be 15 characters or longer. With DES passwords, use the maximum length (eight characters).
Mix Upper and Lower Case Letters — Red Hat Enterprise Linux is case sensitive, so mix cases to enhance the strength of the password.
Mix Letters and Numbers — Adding numbers to passwords, especially when added to the middle (not just at the beginning or the end), can enhance password strength.
Include Non-Alphanumeric Characters — Special characters such as &, $, and > can greatly improve the strength of a password (this is not possible if using DES passwords).
Pick a Password You Can Remember — The best password in the world does little good if you cannot remember it; use acronyms or other mnemonic devices to aid in memorizing passwords.
With all these rules, it may seem difficult to create a password meeting all of the criteria for good passwords while avoiding the traits of a bad one. Fortunately, there are some steps one can take to generate a memorable, secure password.
Secure Password Creation Methodology
There are many methods people use to create secure passwords. One of the more popular methods involves acronyms. For example:
Think of a memorable phrase, such as:
"over the river and through the woods, to grandmother's house we go."
Next, turn it into an acronym (including the punctuation).
otrattw,tghwg.
Add complexity by substituting numbers and symbols for letters in the acronym. For example, substitute 7 for t and the at symbol (@) for a:
o7r@77w,7ghwg.
Add more complexity by capitalizing at least one letter, such as H.
o7r@77w,7gHwg.
Finally, do not use the example password above for any systems, ever.
While creating secure passwords is imperative, managing them properly is also important, especially for system administrators within larger organizations. The following section details good practices for creating and managing user passwords within an organization.
Creating User Passwords Within an Organization
If there are a significant number of users within an organization, the system administrators have two basic options available to force the use of good passwords. They can create passwords for the user, or they can let users create their own passwords, while verifying the passwords are of acceptable quality.
Creating the passwords for the users ensures that the passwords are good, but it becomes a daunting task as the organization grows. It also increases the risk of users writing their passwords down.
For these reasons, most system administrators prefer to have the users create their own passwords, but actively verify that the passwords are good and, in some cases, force users to change their passwords periodically through password aging.
Forcing Strong Passwords
To protect the network from intrusion it is a good idea for system administrators to verify that the passwords used within an organization are strong ones. When users are asked to create or change passwords, they can use the command line application passwd, which is Pluggable Authentication Manager (PAM) aware and therefore checks to see if the password is easy to crack or too short in length via the pam_cracklib.so PAM module. Since PAM is customizable, it is possible to add further password integrity checkers, such as pam_passwdqc (available from http://www.openwall.com/passwdqc/) or to write a new module. For a list of available PAM modules, refer to http://www.kernel.org/pub/linux/libs/pam/modules.html. For more information about PAM, refer to the chapter titled Pluggable Authentication Modules (PAM) in the Red Hat Enterprise Linux Reference Guide.
It should be noted, however, that the check performed on passwords at the time of their creation does not discover bad passwords as effectively as running a password cracking program against the passwords within the organization.
There are many password cracking programs that run under Red Hat Enterprise Linux although none ship with the operating system. Below is a brief list of some of the more popular password cracking programs:
Passwords are the primary method Red Hat Enterprise Linux uses to verify a user's identity. This is why password security is enormously important for protection of the user, the workstation, and the network.
For security purposes, the installation program configures the system to use Message-Digest Algorithm (MD5) and shadow passwords. It is highly recommended that you do not alter these settings.
If MD5 passwords are deselected during installation, the older Data Encryption Standard (DES) format is used. This format limits passwords to eight alphanumeric character passwords (disallowing punctuation and other special characters) and provides a modest 56-bit level of encryption.
If shadow passwords are deselected during installation, all passwords are stored as a one-way hash in the world-readable /etc/passwd file, which makes the system vulnerable to offline password cracking attacks. If an intruder can gain access to the machine as a regular user, he can copy the /etc/passwd file to his own machine and run any number of password cracking programs against it. If there is an insecure password in the file, it is only a matter of time before the password cracker discovers it.
Shadow passwords eliminate this type of attack by storing the password hashes in the file /etc/shadow, which is readable only by the root user.
This forces a potential attacker to attempt password cracking remotely by logging into a network service on the machine, such as SSH or FTP. This sort of brute-force attack is much slower and leaves an obvious trail as hundreds of failed login attempts are written to system files. Of course, if the cracker starts an attack in the middle of the night on a system with weak passwords, the cracker may have gained access before dawn and edited the log files to cover his tracks.
Beyond matters of format and storage is the issue of content. The single most important thing a user can do to protect his account against a password cracking attack is create a strong password.
Creating Strong Passwords
When creating a secure password, it is a good idea to follow these guidelines:
Do Not Do the Following:
Do Not Use Only Words or Numbers — Never use only numbers or words in a password.
Some insecure examples include the following:
8675309
juan
hackme
Do Not Use Recognizable Words — Words such as proper names, dictionary words, or even terms from television shows or novels should be avoided, even if they are bookended with numbers.
Some insecure examples include the following:
john1
DS-9
mentat123
Do Not Use Words in Foreign Languages — Password cracking programs often check against word lists that encompass dictionaries of many languages. Relying on foreign languages for secure passwords is not secure.
Some insecure examples include the following:
cheguevara
bienvenido1
1dumbKopf
Do Not Use Hacker Terminology — If you think you are elite because you use hacker terminology — also called l337 (LEET) speak — in your password, think again. Many word lists include LEET speak.
Some insecure examples include the following:
H4X0R
1337
Do Not Use Personal Information — Steer clear of personal information. If the attacker knows your identity, the task of deducing your password becomes easier. The following is a list of the types of information to avoid when creating a password:
Some insecure examples include the following:
Your name
The names of pets
The names of family members
Any birth dates
Your phone number or zip code
Do Not Invert Recognizable Words — Good password checkers always reverse common words, so inverting a bad password does not make it any more secure.
Some insecure examples include the following:
R0X4H
nauj
9-DS
Do Not Write Down Your Password — Never store a password on paper. It is much safer to memorize it.
Do Not Use the Same Password For All Machines — It is important to make separate passwords for each machine. This way if one system is compromised, all of your machines are not immediately at risk.
Do the Following:
Make the Password At Least Eight Characters Long — The longer the password, the better. If using MD5 passwords, it should be 15 characters or longer. With DES passwords, use the maximum length (eight characters).
Mix Upper and Lower Case Letters — Red Hat Enterprise Linux is case sensitive, so mix cases to enhance the strength of the password.
Mix Letters and Numbers — Adding numbers to passwords, especially when added to the middle (not just at the beginning or the end), can enhance password strength.
Include Non-Alphanumeric Characters — Special characters such as &, $, and > can greatly improve the strength of a password (this is not possible if using DES passwords).
Pick a Password You Can Remember — The best password in the world does little good if you cannot remember it; use acronyms or other mnemonic devices to aid in memorizing passwords.
With all these rules, it may seem difficult to create a password meeting all of the criteria for good passwords while avoiding the traits of a bad one. Fortunately, there are some steps one can take to generate a memorable, secure password.
Secure Password Creation Methodology
There are many methods people use to create secure passwords. One of the more popular methods involves acronyms. For example:
Think of a memorable phrase, such as:
"over the river and through the woods, to grandmother's house we go."
Next, turn it into an acronym (including the punctuation).
otrattw,tghwg.
Add complexity by substituting numbers and symbols for letters in the acronym. For example, substitute 7 for t and the at symbol (@) for a:
o7r@77w,7ghwg.
Add more complexity by capitalizing at least one letter, such as H.
o7r@77w,7gHwg.
Finally, do not use the example password above for any systems, ever.
While creating secure passwords is imperative, managing them properly is also important, especially for system administrators within larger organizations. The following section details good practices for creating and managing user passwords within an organization.
Creating User Passwords Within an Organization
If there are a significant number of users within an organization, the system administrators have two basic options available to force the use of good passwords. They can create passwords for the user, or they can let users create their own passwords, while verifying the passwords are of acceptable quality.
Creating the passwords for the users ensures that the passwords are good, but it becomes a daunting task as the organization grows. It also increases the risk of users writing their passwords down.
For these reasons, most system administrators prefer to have the users create their own passwords, but actively verify that the passwords are good and, in some cases, force users to change their passwords periodically through password aging.
Forcing Strong Passwords
To protect the network from intrusion it is a good idea for system administrators to verify that the passwords used within an organization are strong ones. When users are asked to create or change passwords, they can use the command line application passwd, which is Pluggable Authentication Manager (PAM) aware and therefore checks to see if the password is easy to crack or too short in length via the pam_cracklib.so PAM module. Since PAM is customizable, it is possible to add further password integrity checkers, such as pam_passwdqc (available from http://www.openwall.com/passwdqc/) or to write a new module. For a list of available PAM modules, refer to http://www.kernel.org/pub/linux/libs/pam/modules.html. For more information about PAM, refer to the chapter titled Pluggable Authentication Modules (PAM) in the Red Hat Enterprise Linux Reference Guide.
It should be noted, however, that the check performed on passwords at the time of their creation does not discover bad passwords as effectively as running a password cracking program against the passwords within the organization.
There are many password cracking programs that run under Red Hat Enterprise Linux although none ship with the operating system. Below is a brief list of some of the more popular password cracking programs:
How To Make A Strong Password
Refresher – Password Usage
Let’s be honest, passwords are annoying. These days, we need a password or PIN everywhere. We have so many that we can’t keep track of them all. We forget to update them; and when we do, it’s difficult to come up with effective ones that we can still remember, so we procrastinate changing them for months, even years. We all know this is bad, but the alternative – the painful, irritating password creation and memorization process – is sometimes more than we can tolerate. There is hope! Passwords don’t have to be complex cryptograms. A few simple methods can help make living with passwords a little easier.
While we may find them annoying, and even take them for granted, it is important to remember why passwords are important: passwords are often the first (and possibly only) defense against intrusion (MacGregor). They protect personal information – information we don’t want anyone and everyone to know. In our personal lives, this means financial information, health data, and private documents. In a professional context, this may encompass anything considered crucial to the success of the organization: trade secrets, financial data, intellectual property, customer lists, etc.
Passwords are simpler and cheaper than other, more secure forms of authentication like special key cards, fingerprint ID machines, and retinal scanners. They provide a simple, direct means of protecting a system or account. For the sake of this article, we’ll define a ‘password’ as a word, a phrase, or combination of miscellaneous characters that authenticates the identity of the user. Passwords are generally used in combination with some form of identification, such as a username, account number, or e-mail address. While a username establishes the identity of the user for the computer or system, the password, which is known only to the authorized user, authenticates that the user is who he or she claims to be. This means that their function is to “prove to the system that you are who you say you are” (Russell).
Password Cracking
While passwords are a vital component of system security, they can be cracked or broken relatively easily. Password cracking is the process of figuring out or breaking passwords in order to gain unauthorized entrance to a system or account. It is much easier than most users would think. (The difference between cracking and hacking is that codes are cracked, machines are hacked.) Passwords can be cracked in a variety of different ways. The most simple is the use of a word list or dictionary program to break the password by brute force. These programs compare lists of words or character combination against password until they find a match. If cracking codes seems like science fiction, search “password cracker” on Packetstorm orPasswordportal.net. There are also numerous password cracking tools available that any average person can use. (For more information on password cracking tools, please see the SecurityFocus article Password Crackers - Ensuring the Security of Your Password.)
Another easy way for potential intruders to nab passwords is through social engineering: physically nabbing the password off a Post-It from under someone’s keyboard or through imitating an IT engineer and asking over the phone. Many users create passwords that can be guessed by learning a minimal amount of information about the person whose password is being sought. (For more information on social engineering please see the SecurityFocus series Social Engineering Fundamentals) A more technical way of learning passwords is through sniffers, which look at the raw data transmitted across the net and decipher its contents. “A sniffer can read every keystroke sent out from your machine, including passwords” (University of Michigan). It’s possible that someone out there has at least one of your passwords right now.
How To Choose Good Passwords
Now that we have established the importance of passwords and some of the ways in which they may be vulnerable to cracking, we can discuss ways of creating good, strong passwords. In creating strong, effective passwords it is often helpful to keep in mind some of the methods by which they may be cracked, so let’s begin with what NOT to do when choosing passwords.
No Dictionary Words, Proper Nouns, or Foreign Words
As has already been mentioned, password cracking tools are very effective at processing large quantities of letter and number combinations until a match for the password is found, as such users should avoid using conventional words as passwords. By the same token, they should also avoid regular words with numbers tacked onto the end and conventional words that are simply written backwards, such as ‘nimda’. While these may prove to be difficult for people to figure out, they are no match for the brute force attacks of password cracking tools.
No Personal Information
One of the frustrating things about passwords is that they need to be easy for users to remember. Naturally, this leads many users to incorporate personal information into their passwords. However, as is discussed in the Social Engineering Fundamentals, it is alarmingly easy for hackers to obtain personal information about prospective targets. As such, it is strongly recommended that users not include such information in their passwords. This means that the password should not include anything remotely related to the user’s name, nickname, or the name of a family member or pet. Also, the password should not contain any easily recognizable numbers like phone numbers or addresses or other information that someone could guess by picking up your mail.
Length, Width and Depth
A strong, effective password requires a necessary degree of complexity. Three factors can help users to develop this complexity: length, width & depth. Length means that the longer a password, the more difficult it is to crack. Simply put, longer is better. Probability dictates that the longer a password the more difficult it will be to crack. It is generally recommended that passwords be between six and nine characters. Greater length is acceptable, as long as the operating system allows for it and the user can remember the password. However, shorter passwords should be avoided.
Width is a way of describing the different types of characters that are used. Don’t just consider the alphabet. There are also numbers and special characters like ‘%’, and in most operating systems, upper and lower case letters are also known as different characters. Windows, for example, is not always case sensitive. (This means it doesn’t know the difference between ‘A’ and ‘a’.) Some operating systems allow control characters, alt characters, and spaces to be used in passwords. As a general rule the following character sets should all be included in every password:
- uppercase letters such as A, B, C;
- lowercase letters such as a, b,c;
- numerals such as 1, 2, 3;
- special characters such as $, ?, &; and
- alt characters such as µ, £, Æ. (Cliff)
Depth refers to choosing a password with a challenging meaning – something not easily guessable. Stop thinking in terms of passwords and start thinking in terms of phrases. “A good password is easy to remember, but hard to guess.” (Armstrong) The purpose of a mnemonic phrase is to allow the creation of a complex password that will not need to be written down. Examples of a mnemonic phrase may include a phrase spelled phonetically, such as ‘ImuKat!’ (instead of ‘I’m a cat!’) or the first letters of a memorable phrase such as ‘qbfjold*’ = “quick brown fox jumped over lazy dog.”
What may be most effective is for users to choose a phrase that is has personal meaning (for easy recollection), to take the initials of each of the words in that phrase, and to convert some of those letters into other characters (substituting the number ‘3’ for the letter ‘e’ is a common example). For more examples, see the University of Michigan’s Password Security Guide.
Extra Protection
All of the good password cracking programs include foreign words, backwards words, etc. And the easiest way to steal a password is by asking for it, so it’s simpler to never give it away.
In some cases, a good password is enough protection to keep out intruders. In others, it’s just a start. Encryption and one-time passwords add extra protection to systems. Encryption means garbling the password to protect from sniffers or other onlookers, through a particular scheme that can be deciphered from the other end of the connection. One-time passwords (S/key is the most commonly used) are just that. They can be used only once. This requires carrying a list of passwords or having a special password calculator or SecureCard, but can be a very reliable method of password security.
There are also certain behaviors that users should practice in order to maximize the effectiveness of their passwords. Users should avoid using the same password on multiple accounts. Doing this creates a single point of failure, which means that if an intruder gains access to one account, he or she will have access to all of the user’s accounts. Users should never disclose their passwords to anybody unless they know them to be authorized (i.e., systems administrators). Even then, passwords should only be disclosed in person (not over the phone or by e-mail) to a known, trusted source.
Users should exercise extreme caution when writing down or storing passwords. Stories of hackers obtaining passwords through shoulder-surfing and dumpster diving are not urban myths, they are real. Users should resist the temptation to write down passwords on Post-It notes stuck to their monitors or hidden under their keyboards. Instead, they should choose passwords that they will be able to remember – not an easy task given the complexity required of strong, effective passwords.
There are always extraneous circumstances where we must write down passwords. This is not recommended, but if it must be done, it should be done with forethought, not haphazardly. The extreme example of too many passwords is contract system administrators, who have multiple clients and machines. For these people, the only advice is to write down the phrases or some sort of related thought to jog your memory and put it on a piece of paper carried on your person. Maybe photocopy that and leave that stored in a safe place at home. Never put it on a Post-It. Never store it online. An obscured hint might be okay, but never the actual password or even an encrypted version.
Changing & Storing Passwords and PINs
In order to ensure their ongoing effectiveness, passwords should be changed on a regular basis. Changing passwords securely is fairly simple. Windows passwords are changed through the Control Panel and in UNIX, the ‘passwd’ command generally does the trick. A good rule of thumb is to change passwords as close to the actual account as possible. For example, if it’s an ISP account, don’t telnet through three other machines to change that password. If it’s an office computer, users should be on that computer and not on a co-worker’s when changing it. Don’t let anybody watch while typing the old and new passwords. If at all possible, the password should be changed over a secure connection like a secure shell (SSH).
How often one should change passwords really depends on the account. Online financial accounts should be changed every month or two. Corporate network passwords should be changed every 3-4 months. A recent 2600 article recommended considering the “sensitivity of the resources which you are trying to protect” and suggested “enforcing password changes somewhere between once per fiscal year and once per fiscal quarter” (Thomas). Just use good judgment and don’t be lazy. Changing a password is relatively quick and painless compared to the irritating and expensive process of combating identity theft.
Tips for Organizations and Network Administrators
Managers and administrators can enhance the security of their networks by setting strong password policies. Password requirements should be built into organizational security policies. Network administrators should institute by regular changes/updates of passwords. They should also regularly remind users of how easy it is for hackers to get their passwords through social engineering and online attacks. New users should be taught about good password practices. Providing intranet resources on network security and password security can also be helpful. Finally, the organization’s password policy should be integrated into the security policy, and all readers should be made to read the policy and sign-off on it.
Systems administrators should implement safeguards to ensure that people on their systems are using adequately strong passwords. They should set password expiration dates on all programs being run on the organization’s systems. Keep a password history to prevent reuse, and lock of accounts after 3-5 password attempts. Keep the number of people in the organization who have these passwords as small as possible. The organization should also use newer versions of OSs that have more secure password files and authentication protocols. Keep your individual account passwords updated as well. Finally, when installing new systems, make sure default passwords are changed immediately.
New Year’s Resolution
Obviously, passwords are just one piece of the puzzle. Other pieces are general user education, good physical security, plugging network holes, and installing strong firewalls. These provide much more global protection in the controlled corporate environment than passwords alone, but in areas where the only method of control users have is a PIN or password, the best thing we can do is be aware of security risks and keep up with their password controls.
References
Armstrong, Del and Simonson, John: “Password Guessing” and “Password Sniffing,” An Intro to Computer Security, School of Engineering & Applied Sciences, University of Rochester, Oct. 25, 1996.
http://www.seas.rochester.edu:8080/CNG/docs/Security/security.html
http://www.seas.rochester.edu:8080/CNG/docs/Security/security.html
Belgers, Walter: “UNIX Password Security,” JANET-CERT, Dec. 6, 1993.
http://www.ja.net/CERT/Belgers/UNIX-password-security.html
http://www.ja.net/CERT/Belgers/UNIX-password-security.html
Cliff, A.: “Password Crackers - Ensuring the Security of Your Password”, Security Focus, Feb. 19, 2001.
http://online.securityfocus.com/infocus/1192
http://online.securityfocus.com/infocus/1192
Cons, Lionel: CERN Security Handbook (Practical computer security for CERN users), Version 1.2, 12 December 1996.
http://consult.cern.ch/writeups/security/security_3.html#SEC7
http://consult.cern.ch/writeups/security/security_3.html#SEC7
Donovan, Craig: “Strong Passwords,” SANS Institute, June 2, 2000. http://www.sans.org/infosecFAQ/policy/password.htm
Garfinkel, Simson and Spafford, Gene: Practical UNIX Security, O’Reilly & Associates, Inc. Sebastopol, CA, 1991 & 1996.
MacGregor, Tina: “Password Auditing and Password Filtering to Improve Network Security”, SANS Institute, May 13, 2001.
http://rr.sans.org/authentic/improve.php
http://rr.sans.org/authentic/improve.php
“Password Security: A Guide for Students, Faculty, and Staff of the University of Michigan,” University of Michigan, Information Technology Division, Reference R1192, Revised April 1997.
http://www.umich.edu/~policies/pw-security.html
http://www.umich.edu/~policies/pw-security.html
Russell, Deborah and Gangemi Sr., G.T.: Computer Security Basics, O’Reilly & Associates, Inc. Sebastopol, CA, 1991.
Thomas, Stephen: “Popular Myths on Password Authentication,” 2600, Summer 2001
http://www.2600.com
http://www.2600.com
Visser, Joe: “On NT Password Security,” Open Solution Providers, 1997.
http://www.osp.nl/infobase/ntpass.html
http://www.osp.nl/infobase/ntpass.html
Subscribe to:
Posts (Atom)