Tag: security

cca-bypass 0.5

by on Dec.04, 2009, under realbasic

Now this is what I call rapid development! One day of coding, and I have a new and much improved version of cca-bypass. This version still has two binaries, but it has my own sec_cloak_apply, instead of sec_cloak. Basically, sec_cloak_apply allows me to do some additional things with the code, backing up the registry values, and allowing you to restore them later. This could come in handy.

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: (2.39 MB)

Source: (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”!

Leave a Comment :, , , , more...

Changing Password Every x Days

by on Jun.13, 2009, under life, thoughts

This will be the second in my series of security topics from a non-security expert, I suppose. I just calls ’em hows I sees ’em.

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.

1 Comment :, , more...

Comcast’s Caller ID

by on May.23, 2009, under thoughts

Comcast has recently added a new feature to their digital voice service: caller ID anywhere. Simply download a program on your computer, enter your username and password, and you’ll get a small alert any time you get a call. The same system allows comcast to show caller ID alerts on your TV.

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: (continue reading…)

23 Comments :, , , , , more...

The Danger of “Incorrect Password”

by on May.11, 2009, under thoughts, website

I’m sure you’ve seen the message before. You try to log into a website you go to every now and then, and forget which password you used for it, or type something in wrong. ”Sorry, this password is incorrect,” says the website. You grumble to yourself and try again, paying little attention to the harmless message. From a programmer’s perspective, it’s a bit more interesting than that.

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.

2 Comments :, , , more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Visit our friends!

A few highly recommended friends...