Security Corner


November 24, 2012  1:48 PM

Serious Skype security flaw uncovered, then fixed



Posted by: Ken Harthun
Secure Computing, Security, Security best practice, Vulnerabilities

A serious security flaw in Microsoft-owned Skype allowed hackers to hijack accounts just by knowing the user’s email addresses. Details from this article at TechCrunch:

Skype faced a fairly serious security threat today [Nov. 14, 2012], thanks to a flaw in the system replicated by The Next Web that allowed people to sign up with email addresses already in use by other users and then force password resets for any accounts associated with those emails. Reset tokens could be delivered to the Skype client itself, meaning people didn’t need access to email accounts to reset passwords associated with them.

Very shortly after The Next Web notified Microsoft, the issue was fixed.

The flaw was actually more of a design issue than a security hole, according to Steve Gibson of Security Now! He discussed this flaw in Security Now! Episode #378:

Microsoft shut down the vulnerability, the aspect of vulnerability, which was password recovery. They took that part offline immediately, then looked at the problem, understood it, fixed it, and then brought password recovery back. So that’s what I mean by this being a design problem. As soon as someone told them, they’re like, oh, my god. And so it was easy to fix.

November 19, 2012  9:52 PM

Physical security fail II



Posted by: Ken Harthun
Security, Security best practice

After an incident the other day where a student attempted to break into our bookstore with a credit card, I decided I had better test my office (even though I have a sturdy combination lock on it). It took me about 5 seconds to open my locked door. So, we installed additional measures to prevent anyone from using credit cards, tools, or whatever to open my door. Here’s the solution we used:

This prevents any card, tool, etc. from being slipped into the door. Any door latch guard will work. This one just happened to be available at the locksmith shop down the street.


November 11, 2012  10:53 PM

Secret splitting



Posted by: Ken Harthun
Encryption, Security, Security best practice

In my post “Distributed passwords: A simple security precaution that works,” I gave a method to split up passwords that one writes down into a “secret” part and and a “public” part. It is a practical and secure way to keep a record of passwords. In doing further research, I came across a fascinating site maintained by Dutch cryptology enthusiast and historian Dirk Rijmenants. He has a page on secret splitting that goes into great detail and also provides a secure code splitter template (PDF). Here’s a good explanation of secret splitting and why it is super secure:

Secret Splitting, also called Secret Sharing in cryptography, is a method to split numbers, text or computer data into two or more parts, also called keys or shares. All shares are required to retrieve the original information. It is mathematically impossible to obtain the original information if one of the shares is not available . The information, obtained from separate shares does not reveal any information or partial information about the original, and does not assist in any way in retrieving the original information. Therefore, Secret Splitting offers mathematically absolute security as long as the shares are separated. 

If you need to ensure access to assets but want to keep said access secure, this is the way to do it.


November 11, 2012  2:51 PM

Final update on physical security failure



Posted by: Ken Harthun
physical security, Security, Security best practice, Security management

As you may recall, last month I had a physical security issue at one of my campuses. This post gave an update and on Wednesday of last week, I put in place what I consider the final portion of the solution: RJ-45 cable locks. The locks I chose are Panduit(TM) brand locks that I purchased from CableOrganizer.com (photo below). I chose the recessed ones.

As part of the installation, I had a good discussion with the building management’s rep about physical security for the data closets.

Realize that this solution will not prevent anyone with malicious intent from doing damage, but it will certainly prevent an absent-minded technician from messing with the cables and forgetting to put them back. The locks require a special key to remove them.

If you have had any similar issues, I highly suggest you install these cable locks.


October 31, 2012  5:51 PM

Cryptography contest solution



Posted by: Ken Harthun
Security

So, if you haven’t figured it out already, the code I posted last night is from Edgar Allen Poe’s “The Gold Bug.” From Wikipedia:

The Gold-Bug” is a short story by Edgar Allan Poe. Set on Sullivan’s Island, South Carolina, the plot follows William Legrand, who was recently bitten by a gold-colored bug. His servant Jupiter fears Legrand is going insane and goes to Legrand’s friend, an unnamed narrator who agrees to visit his old friend. Legrand pulls the other two into an adventure after deciphering a secret message that will lead to a buried treasure.

The decoded ciphertext reads as follows:

A good glass in the bishop’s hostel in the devil’s seat
forty-one degrees and thirteen minutes northeast and by north
main branch seventh limb east side shoot from the left eye of the death’s-head
a bee line from the tree through the shot fifty feet out.

Have a Happy Halloween, everyone!


October 30, 2012  11:05 PM

A cryptography contest



Posted by: Ken Harthun
Edgar Allen Poe, Encryption, Fun stuff, Security

Huge kudos (and an as-yet-unspecified major award) go to the first person who deciphers the following message (hint–the photo is the key to the source of the message):

53‡‡†305))6*;4826)4‡.)4‡);806*;48†8¶60))85;1‡(;:‡*8†83(88)5*†;46(;88*96*?;8)*‡(;485);5*†2:*‡(;4956*2(5*—4)8¶8*;4069285);)6†8)4‡‡;1(‡9;48081;8:8‡1;48†85;4)485†528806*81(‡9;48;(88;4(‡?34;48)4‡;161;:188;‡?;

Post your comment with the cleartext here. The solution will be posted tomorrow on Halloween.


October 30, 2012  4:31 PM

Update on physical security failure



Posted by: Ken Harthun
Security, Security best practice, Security management

Hollering on the right channels seems to have gotten results. Here’s the update on the physical security problem I mentioned in my last post. These are excerpts from emails.

Us: We are experiencing another issue with our network cable in the Phone/Data Closet.  Our server was down again this morning.  Our Network Administrator, Ken, noticed that our network cables were not plugged into the correct jack.  He is extremely concerned about this.  Ken placed a sign in the Phone/Data Closet near our network cables stating for no one to touch our cables.

Building Management: To my knowledge, no one has been in the data closet. The key for the closet is secured and to my knowledge, have not provided access to the closet recently. On Monday, I will talk with Steve and see what we can do to improve security of your equipment.

Us: We are taking extra precautions to ensure that the cables will not be easily removed, however I glad to hear that  building management is making an effort in securing the closet.  So thank you for your immediate response.

My response to the above: They need to change the code for the key vault kept on the third floor and provide a list of people who have access to the code. Ms. <redacted>  may not have knowledge of who was in there, but someone surely knows who has the code. Tampering with data communications equipment is a federal offense, but I cannot take appropriate action unless I have some documentation as to who has access to the equipment and I do intend to report it to the proper authorities if this happens again.

Building Management: Maintenance changed the code on the key box this morning. As of right now, <redacted> is the only one with the new code. We will log any tenant/vendor requests to access the data closets. Keep in mind that we have a tenant expansion on the second floor that just commenced and you will be expanding your premises shortly, so there will be contractors accessing these closets periodically during construction. Upon the completion of these projects, we will change the access code again .


October 27, 2012  12:50 PM

Tale from the trenches: Physical security failure



Posted by: Ken Harthun
Physical security, Security, Security best practice, Security management

Last Friday, a trouble ticket came in saying someone from our satellite campus could not access our database application. I immediately attempted to log in remotely and was unable to do so. The next check revealed that our NLAN link was down and had been since approximately 7 p.m. the night before. Our service provider checked the circuit and found no problems, but did not see a link to our router. An on-site investigation was in order.

Upon arrival, I checked the router and there was no link on the WAN port. Our closet is on the third floor and the connection runs to the phone/data closet on the second floor. The key to the closet is locked in a key vault with (supposedly) limited access to the code. The key opens all doors on all electrical and phone/data closets in the building. When I opened the door, the problem was obvious — someone had unplugged both cables to our third floor closet. I replaced them in the demarcation box and the network link was back.

Yesterday, while attempting to log into the remote server for user account maintenance, I discovered that the link was down again. This time, I had someone on site go to the closet and verify that the cables had not been unplugged again. I was told they were in place. I made another trip to the site.

Again, no link light on the router. I checked the closet and, sure enough, the cables were in place, but they had been moved to different (inactive) ports. I won’t print here the string of choice expletives that reverberated down the hallway! Once again, I corrected the problem. Then I placed a sign on the demarcation point that informs whoever is responsible for this that I will report further incidents to Federal authorities.

Several outpoints are present in this physical security failure:

  1. Anyone who has the key vault code can access critical infrastructure equipment;
  2. There is no list of who has been given access to the code;
  3. There is no way to log who accesses the key vault;
  4. There are no security cameras in the building, and;
  5. In both instances, the network went down on a Thursday evening.

It’s not likely that I will discover who did this (or who continues to do it, if it happens again) without cooperation of the building management. They don’t seem to be too concerned, but if it happens again, you can bet I will be making their lives miserable and withholding some lease payments until they put tighter security measures in place. For my part, I will be installing patchcord locks as soon as I can get them (see photo below).

 


October 25, 2012  1:54 AM

The 25 most popular (and most insecure) passwords of 2012



Posted by: Ken Harthun
Password, Secure Computing, Security, Security best practice

Halloween is only a week away and everyone is breaking out their scariest costumes. No doubt there will be plenty of fright going around on October 31 — all in good fun, of course — but there is some real-life scary stuff out there that would make Beelzebub squirm. I’m talking about the list of the 25 most popular passwords of 2012 published by Yahoo! on their Plugged In blog. It’s true horror at its best, at least for we Net Admins. Imagine the digital carnage that will certainly ensue, heaven forbid on our own networks.

Here’s the full list, along with how the popularity of the phrase has increased or decreased in the past year:

1. password (Unchanged)
2, 123456 (Unchanged)
3. 12345678 (Unchanged)
4. abc123 (Up 1)
5. qwerty (Down 1)
6. monkey (Unchanged)
7. letmein (Up 1)
8. dragon (Up 2)
9. 111111 (Up 3)
10. baseball (Up 1)
11. iloveyou (Up 2)
12. trustno1 (Down 3)
13. 1234567 (Down 6)
14. sunshine (Up 1)
15. master (Down 1)
16. 123123 (Up 4)
17. welcome (New)
18. shadow (Up 1)
19. ashley (Down 3)
20. football (Up 5)
21. jesus (New)
22. michael (Up 2)
23. ninja     (New)
24. mustang (New)
25. password1 (New)

I wonder how long “password” has been a popular password (probably forever). Will people never learn? Cripes! How hard is it to remember to at least pad it with some random characters. 89password(* is so much more secure and not at all difficult to remember. Send anyone you know who is guilty of using such weak passwords to Steve Gibson’s Password Haystacks page so they can learn how to create a personal padding pattern. Then, they can use all the simple (padded) passwords they want.


October 20, 2012  10:22 PM

Distributed passwords: A simple security precaution that works



Posted by: Ken Harthun
Password, Secure Computing, Security, Security best practice, Security management

Everyone of us has one: A user who has a “book” of passwords sitting in plain view at their workstation. This person absolutely insists on keeping passwords written down in longhand and refuses to use any type of password manager software. Yes, the book is usually closed and it’s not obviously labeled Passwords! in 72 pt. Arial Bold, but this means little in the way of true security. Any determined person could sneak in and look around. It’s a bad idea. Keeping the password list in your wallet is significantly more secure, but if you have a large list of passwords, this can be cumbersome. There is, however, one simple security precaution that works for those persons who insist on having a written list: Distributed passwords.

Distributed passwords derive from Public-key cryptography where there are two keys, one private, one public. Applying this principle to the password book, one simply splits the passwords into two sets of characters, writes one set down in the “public” book that remains visible and writes the other set down in a “private” book that is kept secret (perhaps by locking it up when not in use). This is extremely simple to implement and results in a much greater level of security. Here’s how:

Book 1                Book 2
Bank: 1234            Bank: 5678
Credit: 9876          Credit: 5432

You get the idea. The bank password is 12345678 and the Credit password is 98765432

This could be implemented with stored notes or spreadsheets as well, but if you are going to go through the effort of typing them and storing them securely, you may as well just use a password manager like KeePass or my favorite, LastPass.

In a future post, I’ll apply this principle to password succession in estate planning. Stay tuned.

 


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: