Read this whole guide offline with no ads, for a low price!
Click Here!
Use coupon code "certiguide" to save 20%!
(Expires 2004/12/31)

Need more practice? 300 additional Security+ questions!
Get It Here!

Custom Search







Table Of Contents  CertiGuide to Security+
 9  Chapter 1:  General Security Concepts (Domain 1.0; 30%)
      9  1.2  Authentication

Previous Topic/Section
1.2.3  Certificates
Previous Page
Pages in Current Topic/Section
1
Next Page
1.2.5  Tokens
Next Topic/Section

1.2.4  Username/Password

Although digital certificates are becoming more popular, most systems today require each user to identify himself to the system by furnishing a username and password. This is an example of authenticating yourself based on “what you know.” We’ve already seen this in our discussions of authentication protocols like Kerberos and CHAP.

The username is unique to each individual user. It is a humanly readable name which typically, 'under the hood', is associated with a number set or hashed value that was generated at the time the user account was created. The password is supposed to be kept secret and should be sufficiently long enough to prevent a brute force (trying all the possible permutations of characters) attack from succeeding. Furthermore, a password should not be a name found in a native language to prevent a dictionary attack. It should also not be something easily guessable such as the username, the user’s first name, their child’s name, etc.

Different OSs and applications perform user/password validation with different levels of intelligence and naiveté’. For example, some encrypt the password before sending it across the wire, some don’t. Some store the password in strongly encrypted form on the server; some store the password on the server using weak or no encryption.

As networks became more common, network “sniffers” which inspect traffic as it travels across a network became more common, and computers got faster (permitting encryption to be brute-forced), engineers began looking for better solutions that provided a higher level of security. Simple user/password authentication is still used today by a variety of services, but many security professionals and real-world-savvy network administrators recommend avoiding those services and going instead for those that use stronger authentication methods, due to limitations in the user/password approach:

  • The often-existing requirement that the password be sent over the network, sometimes without being encrypted.

  • The ease with which passwords can be stolen (or guessed) by unauthorized personnel, and then used to impersonate someone’s identity.

  • The fact that passwords are often entangled with “people” issues that complicate security – staff use their children’s and pets’ names as passwords for ease of memorization, they write down passwords too complex to remember, and tend to dislike changing their passwords on a regular basis.

Previous Topic/Section
1.2.3  Certificates
Previous Page
Pages in Current Topic/Section
1
Next Page
1.2.5  Tokens
Next Topic/Section

If you find CertiGuide.com useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider buying an inexpensive PDF equivalent of the CertiGuide to Security+ from StudyExam4Less.com. (Use coupon code "certiguide" by December 31, 2004 to save 20%!) Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



Home - Table Of Contents - Contact Us

CertiGuide for Security+ (http://www.CertiGuide.com/secplus/) on CertiGuide.com
Version 1.0 - Version Date: November 15, 2004

Adapted with permission from a work created by Tcat Houser et al.
CertiGuide.com Version Copyright 2004 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.