Other than that, the big improvement is the addition of a progress bar, and making the login process asynchronous.  This means that there’ll be a nice little progress bar to show you how far along in the login process the task is.  Note that it takes a second after you click “Login” for the task to start running.

Finally, there is a LOT more error checking in the Login process, so all errors should now be in plain English.  If you DO encounter an error, and you think you shouldn’t have, please let me know, and I’ll do my best to fix it.  I can’t test every situation!  Anyway, on to the download links for version 0.5:

Pre-compiled binary: cca-bypass-0.5-binary.zip (2.39 MB)

Source: cca-bypass-0.5-os.zip (38 KB)

Note: I’m still considering this beta because I haven’t been able to thoroughly test it.  It should be pretty, stable, though, so don’t be afraid of the “beta”!

As you may or may not know, I will be attending Valparaiso University this Fall as a Freshman.  When I attended Valparaiso’s Freshman orientation program, they taught us a lot about their online systems.  One thing I learned was that I will need to change my password every 185 days, and when I change it, it can’t be similar to whatever I had last time.  The idea here is that this will be more secure, because hackers will never know your password for an extended period.  However, I see a problem with this.

Forcing me to change my password to something completely different means forcing me to memorize a new password, something completely different, too.  Now, personally, I don’t think this will be much of a problem, because I’m pretty good at memorizing things.  However, if you aren’t that good at memorizing, this could cause a big problem: the urge to write down your password.  As anyone could tell you, writing down a password immediately creates a security risk, because anyone could see it written on a piece of paper, or take the paper, etc.  The safest place for a password is in your brain, and in your brain only.

So, is forcing users to change their password really more secure?  For some people, I think it will help, but I think it’s a practice that could only hurt others.  A better idea would be to enforce good password practice: have users create a nice, good length, password, containing at least one letter, number, capital letter, and special character.  Want to go for more security?  Force it to start and end with a letter.  Don’t just let the user tack an exclaimation mark on an otherwise easy-to-guess password.

Overall, I don’t think there will ever be a formula for password security.  There is no one end-all be-all tip I can give for keeping your password away from hackers.  Perhaps forcing people to change their password every x days really does help security.  But, I’d like to see some concrete proof of this before I believe it.

So, how does this work?  Did comcast come up with some super-secret way to encode this data so no one but them can use it?  Nope; they’re simply using XMPP.

For those unaware, XMPP is a very nice concept: an open messaging protocol.  This means that companies don’t need to invent their own protocol, or shell out big bucks to use another protocol.  Just grab a server and client, and you have an instant messaging system.  XMPP is also designed to be expandible.  Is there a feature you need that it’s missing?  Just code it in, following the current specifications.  The problem with this is that different clients can conform to different specifications for things that aren’t part of the official protocol, but that’s another discussion.

Comcast decided to not reinvent the wheel, and just use XMPP, with a little twist.  If you already know a bit about XMPP, I’ll give you the stanza as a client receives it:

<message to=”bob.graese@comcast.net/comcast” from=”callerid_alert@comcast.net/wcdc01b” id=”sn-30552863″ type=”headline”><CInfo>3NoAaS45q2vvGEmdgNb35TReIbQcE7F5d4vtkBu0l1bsyVdLRr3VxaTyWbV
nyXpEIgjAs1QbBV2CK1HJjIb+yvTDOMXh5uDGh+Q552jyV6vxPM10+tlhNBfTEvNjB7QJnTHkd2Mmj5
Cl3JCdoRRw8/RTGSzDGrSQwLAmpht6GmS7DNMGcHc=</CInfo></message>

(The line breaks above have been inserted by me in order to not destroy the layout)  So, what’s all this saying?  When your phone rings, comcast sends you a message over the XMPP protocol.  This message goes TO (your_main_account)@comcast.net, using the resource “comcast”, and comes FROM callerid_alert@comcast.net (very original naming), with a little resource tacked on the end there.  Each message has a unique ID, and a tag saying that the message is a “headline” (I’m not sure on the specifics of this, I’m guessing this would be used for news items in a XMPP client).  Then, Comcast starts the non-standard part.

When sending an IM over XMPP, there’s usually a body tag inside the message tag.  However, Comcast has invented a CInfo tag, which isn’t part of the XMPP specification.  Inside, there’s a long, encoded string.  Unfortunately, I haven’t worked out how they encode it (I’ll be working on that in the coming days; Any ideas?  Let me know!)

So, what does this mean?  It means that everything is unsecure (except the CInfo tag).  Theoretically, if comcast’s programming is dumb enough, I could send a caller ID message to any comcast user, and have it display on their TV and computer, even though their phone isn’t ringing.  Or, I could call their house, then send them a different caller ID message, and spoof my caller ID info.

Of course, this all hinges on the assumption that comcast figured no one would think of this.  I’m guessing that Comcast doesn’t check who the message is FROM.  If they do, and it needs to be from callerid_alert@comcast.net, then none of this will work.  However, if they don’t check, this could be a fun security excersise.

But first, I need to decode the information inside CInfo.  I don’t have much security expertise, so I can’t guarantee any progress on this.  If you have an idea, please let me know.  If you figure it out on your own, I’d also like to know.  If you use my ideas to expand into your own project, a small link is all I ask.

Stay tuned in the next couple of days to see if I can make any progress.

With a SQL database backend, it’s quite easy to figure out a login problem.  It’s a simple matter of searching the databse for a username that is equal to the one the user entered.  If the password of that row matches the password the user entered (generally md5 encoded), then the user can login.  If it doesn’t, they get the “incorrect password” message, and if the username search returns zero rows, they get an “incorrect username” message.  Simple and secure, right?

Wrong.  The problem with telling the user that the password was the incorrect data entered is that it lets them know that the username is correct.  For someone legitimately logging into the website, this is great.  They know exactly what to fix, they fix it and move on.  For someone who doesn’t actually own the account, however, this message is a lot more interesting.

Potentially, a script could be written to try thousands, even millions of usernames all with the same password.  Once an “incorrect password” message is reached, the script can then try another list of thousands to millions of passwords, until it gets an account.  All automated, and very simple.

So, the solution is to not let the user know what’s wrong.  Just say “incorrect login details.”  Something is wrong, but we’re not gonna tell you what.  Good luck!  This will stop any username-guessing script.  Now, you can’t tell a valid username from an invalid username.  However, some websites like to have lists of their members, or the hacker may already know a username for some reason.  So, how do we combat this?

Login try limits.  After 5 failed attempts, lock out the IP address in question.  Any user who just typed something wrong should be able to get it right within five tries, and blocking the IP will stop from additional attacks.  However, some robots are more complex than this.

When it comes down to it, if someone really wants to get into your website, they will.  A botnet will millions of different IP addresses could foil the above scheme.  Additionally, proxies could get around this block.  It would seem that there is no way to keep a website secure.

The responsibility falls on the user, really.  Most websites say somewhere that if someone breaks into your account, they aren’t responsible.  Website admins should have really long annoying to type passwords, because they can easily save the password somewhere, and normal users should have passwords that are strong enough.  If you’re really worried that someone will break into your account, choose a better, longer password.

Or, do we need to go above and beyond passwords?  Is there a level of security past passwords that we have yet to reach.  A lot of computers now have fingerprint readers.  Could we have websites that require your fingerprint as your password?  How about an image?  A website could issue you a completely random image for your password.  You save this image, and have to upload it any time you want to login.  The image would have to be small enough to let dial up users be able to upload the image, but it could be big enough to be very, very random.

So, security isn’t perfect.  I doubt it ever will be.  If someone really, really wants to break into something, they will.  This is why we have jails.