
Archive for the ‘computer security’ Category
Passwords: Beating the Dead Horse
December 14th, 2010 - Be the First Comment!
Edit: Any comments expanding on password security would be great.
It seems that everyone who is security oriented in computing knows that everyone who isn’t security oriented in computing doesn’t manage passwords properly. It is even the case that some people who do know a lot about security manage their passwords poorly as well. In my eyes the main reasons for poor passwords is 3 fold.
- Poor enforcement
- Lack of education
- Loss of Convenience
Poor enforcement and loss of convenience I believe are the developers fault and I will discuss them later. Lack of education is not entirely the developers fault in my opinion. There is no reason this issue still plagues the internet. We have classes in school about learning basic computer skills and yet we don’t cover password security. To me it is as important or more important then learning things like Excel and Word. A mere day of password security in school could go a long way.
Rolling your own
First and foremost I blame developers for the state of password based security. Developer’s are the front line when it comes to security. If we don’t contemplate security, it is likely the rest of the organization won’t either. Gawker’s recent password debacle is a prime example of what not to do. It is amazing to me that a network that has technically oriented sites like LifeHacker can use such horrible password procedures (DES with 8 char max). Here are the results and some evidence of encryption failures.
If you are going to roll your own password security at least look into a little bit before you develop a million plus user database. Three of the basics everyone should know are:
- Use hashes, not encryption to store your passwords. Also you’ll probably want to use SHA2-512 or SHA3 once it is available. MD5 and SHA1 are both vulnerable to collision based attacks already and it will only get worse as time progresses. In PHP it is as simple as
hash('sha512', $pswd) - Salt the passwords before hashing. Salting is adding a “secret” phrase to the password.
$pswd = "secret".$pswd."phrase";
- Password Complexity Requirements. Passwords like “password” or “password1″ should never be used. You should enforce some type of password complexity requirement on your site that prevents them from being used. Including symbols, numbers, as well as upper and lower case letters with a minimum length of 12 is what I would consider secure.
To create a very basic authentication system using these concepts you would have a user input their password, then append your salt (secret phrase) to it, and last hash the password. This hashed result is stored (if they’re signing up) or compared (if they’re logging in) to the user information stored in the database. There are many other things to consider when developing an authentication system, but those are basics ANYONE should know (except Gawker apparently).
OAuth, the Single Sign On (SSO) of the internet
All of that being said, I support using OAuth. They may have their weaknesses, but I believe it is the most effective way to create a secure internet infrastructure. One reason I believe so is that it eliminates the convenience problem discussed below. By making it more convenient for users you may be able to encourage them to use more secure passwords. Since you are basically using a SSO for the entire internet, you can create more complex password policies on the SSO and add very little inconvenience which then translate into better security for all the websites involved. It also centralizes the focus of security on the large OAuth suppliers like Google. Eventually we may be able to complete solve the password problem, but until then I think OAuth are a step in the right direction.
Convenience is the enemy of most security. This is really unfortunate because it encourages people to be less secure to regain convenience. Passwords are something everyone has and most people hate. Even I hate when my domain credentials at work need to be changed. Coming up with a decently secure password that you can remember is a pain. OAuth allow you to only have one painful password instead of many.
Note: OpenID is another similar concept to OAuth that could also work.
Reality
OAuth aren’t widely used yet.
The solution I use involves creating individual passwords for most sites, and a common password for sites I don’t care about. I then store these passwords for recovery purposes in an encrypted database that I can retrieve. Although it might sound complicated to some, it isn’t. It is however inconvenient. You can use programs like KeePass to help you manage and encrypt your passwords if this interests you, but for most it won’t because it is still inconvenient.
Hopefully someone will be touched by this post and understand a little more about password security and the basic concepts surrounding it.
[ Tags ]: 512, Gawker, keepass, LifeHacker, md5, oauth, openid, password, passwords, security, sha1, sha2
[ Category ]: computer security, programming
Single Sign On (SSO)
March 19th, 2010 - 3 Comments
Recently at work I have been trying to integrate a MediaWiki’s login with our SSO. My boss explained to me how SSO works. I decided to make a diagram of the way it works and write up a blog post about it. This is a basic overview of SSO. I made an image
Step 1: Step one is the initial request from the client to view a page that requires signing in. When the page receives it checks to see if the client is logged in. Login information is stored in a cookie which I will explain more in the last step. If they are logged in, they are allowed to view the page. Otherwise move to Step 2.
Step 2: Redirect the user to the CAS (Central Authentication Service) server. In the URL used for the redirection urlencode and pass the current webpage as a parameter in the url to the CAS server (Example: https://cas.brokenbytes.info/login/?service=http://admin.brokenbytes.info/index.php). This will be used later (in step 3). CAS provides a login page to the user where they can enter their credentials. If it fails, let them attempt it again. If validation is successful, generate a SSO Token ID (Example: 165asdefASD5). This is a unique token for this single sign on for the client. It will be used for only this session. In memory or a database associate the client with that token. Now move to Step 3.
Step 3: In step 3 the client has just been validated. In this step we need to redirect the user back to the Web Server, but first we must modify the URL to pass the SSO Token ID back to the Web Server. So something like this will be your redirect address: http://admin.brokenbytes.info/index.php?token=165asdefASD5.
Step 4: When the Web Server receives this request, it sees the token variable and then it knows to check the CAS server for its validity. This check to see if the token is valid is between the Web Server and the CAS Server. The client is not involved at all. In PHP you can do this by using file_get_contents(“https://cas.brokenbytes.info/login/validate?token=165asdefASD5″) or similar. If the CAS server replies with an okay, true, yes, etc response then you generate an encrypted cookie for the user to authenticate them. From this point forward they authenticate with the cookie until deleted or time out.
Notes: The SSO Token ID should only be valid for a few minutes or until used and then it should be unassigned.
Downfalls: Session hijacking can still happen because the cookie is stored on the clients machine.
[ Tags ]: Single Sign On, SSO
[ Category ]: computer security, programming
Knowledge
January 12th, 2010 - Be the First Comment!
Knowledge is the most powerful tool that is available to humans. For this reason sharing knowledge is a wonderful thing. In an effort to disperse knowledge I will posting some this I have been reading. I will probably also be commenting on whether i found them useful to look at or think they are definite skip.
People who know me, know that I love computer security. I’m still at meager beginnings but I enjoy learning about it. This passion has lead to my discovery of many security related sites. Here are a couple and what I think of them.
Infinity Exists is a very interesting site. It is probably on the lesser known side and has a bunch of tutorial type videos relating to computer security. There are a few videos unrelated to it as well. I like this site. They are very open and it comes from someone in the same position as me. Someone starting out with a interest in security and learning. The production quality is low budget but still pretty decent.
Heorot is another site that I like. I recently bought a book called “Professional Penetration Testing: Creating and Operating a Formal Hacking Lab” and am really enjoying it so far. The guy who wrote the book maintains the Heorot site. The author is the creator of De-Ice. De-Ice is a bootable CD that is built for you to try to break into, but doesn’t contain unpatched software. It is based on misconfiguration discovery and exploitation. They also contain multiple levels of difficulty.
[ Tags ]: computer security, de-ice, penetration testing, starting out in security
[ Category ]: computer security
Drupal and wireless security
October 11th, 2009 - Be the First Comment!
I’m starting a project for my networking class that is going to cover wireless security. After it is finished I will probably post the material up here for people to look at if they would like. It will include a proposal, presentation, and paper about wireless security methodologies. Any programs and such (if any) I make related to this project I will also release. I plan to collect local data about wireless access points as well which will be available.
Recently I have also been working on a project for my friends in drupal. I have been learning how to implement a website in drupal and include forums and other things. It is for Legion (guild) in Aion (video game) called The Fifth Column. It can be found at www.5column.org
[ Tags ]: networking, wireless, wireless security
[ Category ]: computer security





