Posts tagged ‘Passwords’

« Previous Entries
Next Entries »

Thanks for Nothing Google

June 10, 2010, 3:46 pm

Yesterday I wrote about the importance of using good passwords because people are trying to bruteforce your email and social networking accounts.  Today I logged into GMail and received a dire red letter message. “your email has been accessed from the United States.”  

  Upon reviewing the Gmail account activity log, I see access to my account from United States (CA) (204.176.49.44).  An IPWhois wasn’t very helpful , its been registered to Verizon Business/MCI/UUNet.  A google happened to include reverse DNS in the results showing me that 204.176.49.44 resolves to host44.tivo.com.   After verifying that that host44.tivo.com also resolves to 204.176.49.44, I recalling using TiVo to watch some Youtube clips the other night.   I used my Google account to log into Youtube from the Tivo.   Mystery solved.

Apparently Google’s GMail tripwire is catching all Google authentications.     Either that TiVo took my Google credentials and logged into GMail as well as youtube.   The timestamp for the authentication doesn’t really line up with when I was watching the Youtube.   Make me wonder if this is as innocent as I’d like to believe.   Google really should differentiate between email access and authentications to other Google services.

Tags: , , ,
Category: General  |  1 Comment

Yes, You really do need a good password

June 9, 2010, 9:54 pm

Mark Kellner, a technology reporter at the Washington Times, bravely owns up to using crappy passwords.   Most users think they have nothing to hide and nothing of value.   “Who would possibly be interested in me” they ask.   So “why”, they ask, “should I bother with a good password.”

Kellner’s Gmail account was compromised by an IP address in China.  While Kellner could have been targeted as a journalist, those with political motives would have had to have been rather clever to cover their trail by sending out spam from the mailbox.  Even if your mailbox doesn’t contain a lot of your online passwords or have contact info for important people, a regular mailbox can still be used as a trusted platform from which to spam or con people out of money in your name.

Kellner admits to using a simple one word password.  Even in the dark ages when I got my Yahoo mail account, the default/provided password combined two words and appended two numbers.

The lesson for normal people who don’t read infosec blogs is even if you think no one would ever target you, you are at risk and need to use password common sense.  

At best-
Dont reuse passwords on online accounts
change them every 3-6 months
Don’t use dictionary words, common names or sports teams. 
Letters Numbers Special Characters.
If someone emails you your password during an account set up or password reset, you need to change the password.

At a minimum
Dont reuse passwords on important accounts
Dont leave a copy of your passwords in your mailbox. 
There are many memorable ways to make a password.   A single word doesn’t cut it.

The author is a Mac guy.  He ran anti-mailware on the computer anyway.  So it is likely this wasn’t a password stolen from his computer.

Tags:
Category: General  |  7 Comments

On Password Changes

April 13, 2010, 4:44 pm

Cormac Herlye’s paper So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users raises some interesting issues about security policy. Sadly I see this research paper not as causing people to challenge assumptions, but instead its ammunition for the anti-IT/anti-security forces. They’re the ones who want to argue about every decision as if they were in operation or security. So my knee-jerk reaction is to argue with it. Then I stop and think for a bit.
1. By definitions password expiration leaves you exposed until the password expires. If the password expires every 90 days, that means on average the account is exposed for 45 days. Are there any other security defenses designed to expose your accounts for 45 days on average?
2. Frequent password change requirement is believed to have its roots in the attacker’s ability to crack passwords. The password is stored in a enciphered format called a hash. If a hacker obtains the hash, they can try to guess the password through guessing all possible combinations. This is known as brute forcing the password. Other methods of attacking a hash are precalculated (also called Rainbow) tables. Checking dictionary words (with substitutions is another form off attack). If a hash was obtained, it should in be impossible to determine the real password from the hash before the password expires and must be changed. If password reuse is also banned, then the security of the password is sustained.
Are there legitimate reasons to expire passwords?
Changing passwords limits exposure. It makes it more difficult for people to share accounts. Sharing accounts is a policy violation.
Even though it seems like closing the barn door after the cattle have escaped, it does eventually limit damages.
The common complaint is its too hard to remember. Many responding to this article claim they would pick better passwords if they didn’t have to change them all the time. I think that if users had to use long passphrases they would be easy to remember. They would also be more secure due to the length and that would allow the 90 day change to be increased to 120. Of course at my company we have compliance requirement that would prevent us from taking that action.
The author seems focused on banks and paypal. My focus is on the corporate accounts. I just dont see the cost to the user of changing the password. In my experience web accounts DONT force you to change the password so that alone will cause the corporate password to be different from the user’s other accounts. That is a good thing.

Tags: ,
Category: General  |  1 Comment

iPhone (in)security in the enterprise – Followup

April 7, 2010, 8:32 pm

Back in November I wrote a summary of several concerns we have about the iPhone in the enterprise.
Four months later lets take a look at see what’s changed.
One of the other guys at work took that list of concerns to our AT&T rep, who then took them to a unnamed, untitled Apple contact. Next they ran it the questions by the magic 8 ball. The responses are below.
Problem 1: Encryption and PIN bypasses reported at iPhoneinsecurity.com
Apple’s Response:
We take iPhone security very seriously and have made consistent improvements in all areas.For example, in the most recent iPhone 3.1.3 update we made the changes detailed in the following KB – http://support.apple.com/kb/HT4013 One to highlight is CVE-ID: CVE-2010-0038 related to recovery mode. This is a big improvement to thwart those who are using tools to modify the iPhone software.
That doesn’t really answer the question though. Is the encryption bypass which Zdziarski is only talking to law enforcement about fixed or not? Due to the lack of public disclosure there is no way to know. Zdziarski does mention using recovery mode so it is possible that the attack is patched. But I dont give the benefit of the doubt to non-disclosers.
I suppose some would argue that the evil maid attack allows bypass of Full Disk Encryption on computers so I shouldn’t have my data there either. Of course using a smart card or bitlocker with TPM I could protect myself from this attack.
The evil maid attack requires an attacker to have physical access to the device. Then I log in. The the maid returns to harvest the results. The iPhone encryption bypass can occur when you leave the iPhone unattended for a few minutes. I dont think that is comparable.
2. iphoneinsecurity shows a password bypass in addition to the encryption bypass.
Apple’s” response indicates that the enterprise passcode policy is completely different than the consumer four diget pin and thus not vulnerable. I’m not sure I’m buying that.
3. Lack of Centralized Config Management
Apple’s Response indicates that its possible to force the iphone to have enterprises configuration in order to be able to connect in order to connect to the enterprise. I’m not sure exactly how that is supposed to be done.
Further Apple claims that the iPhone is more secure than the Blackberry because its Unix. Its also more secure because you can only run one application at a time and every app is approved by Apple. lolz.
4. Patching
With the BES we can deploy them as forced updates over the air.
Apple’s Response:
We (Apple) don’t view them as patches, but as major, free OS upgrades and updates..a typical OS update for us is 200-300 meg ( very unwieldy to do OTA) and is packed with useful new features , security upgrades, OS enhancements, etc…
“we dont view them as patches”. Sorry, I didn’t read the rest. Laughing too hard.
5. iTunes
Apple Responded that its best practice to not supply full itunes to everyone. Apparently there is some way to skinny down itunes so its basically a sync software.
6. App Store
This issue goes back to is this a business device or not. Are the users going to have the device on their Apple account and take the applications with them or what?
Apple’s response was basically, yes the user takes the app with them when they leave the company even though the company bought the app.
7. Jailbroken phones maybe less secure.
Apple’s response is dont let jailbroken phones connect to the network. No word on how to do that. Authentication alone doesn’t do that. Is ActiveSync going to check for that? I think not.
8. Repeaters. This is more an ATT issue. If we buy X iphone’s can we get repeaters for free.

Tags: , , , ,
Category: Apple  |  Comment

BitLocker vs Third Party FDE

March 30, 2010, 9:59 am

Like many organizations, we skipped Vista. So with Windows 7 we are facing the question “is Windows 7 good enough” or do we still need to pay for a third-party full disk encryption (FDE) product.

This question was asked back in 2006 at the SANS Desktop Encryption Summit. The FDE vender’s felt their product was better because:
1. Better Management tools
2. Mature product
3. Multiple OS support
4. No requirement for TPM.

BitLocker is no longer a first gen product. Let’s look at today’s reasons for purchasing or continuing to use a third-party FDE product.
BitLocker Minimum Requirements
“BitLocker stores its own encryption and decryption key in a hardware device that is separate from your hard disk, so you must have either a computer with a Trusted Platform Module (TPM) or a removable USB memory device.”
USB memory devices would tend to be stored in the laptop bag, so that isn’t a secure solution.
TPMs are an additional thing to manage. Perhaps it’s not as difficult as I envision. When I did a WAVE eval, I had to go into the BIOS to enable the TPM and set a master TPM password. That doesn’t scale.
“The computer must have been configured with an additional separate active partition to be used as a system partition.”
This extra step now happens automatically, so I don’t think that is a big deal.
“The BIOS must be compatible with TPM and/or support usb devices during computer startup”
It may be necessary to upgrade the BIOS. While probably not an issue on the newer computers we would be using, this could be an issue on upgrades in place.
None of these prerequisite requirements is particularly burdensome. However it leaves out one key minimum requirement: Vista or Windows 7 Enterprise. Our XP systems would still be on the current FDE product requiring two management methods.

OTHER BitLocker Considerations
1. Provable Encryption
With the current FDE product, if a computer is lost I would be able to tell that it was actually encrypted when it was last seen on $date $time. Can BitLocker say the same? I don’t know.
Many states have an encryption safe harbor. Meaning if the lost system was provably encrypted, breach notification provisions do not apply.
2. Usability
The current FDE product syncs the domain password to the pre-boot environment. The user does not need to know a second password. The normal password requirements apply.
With BitLocker the PIN is just that. An enhanced PIN can be required but it is possible that some system BIOS will not support alphanumeric entry in the pre-boot environment. Does this PIN ever expire? It doesn’t seem like it.
3. Recoverability
The standard recovery method is to use a recovery password. This is a 48 digit number backed up to Active Directory. Enjoy typing that in when the user forgets their password.
This method is not FIPS compliant and must be disabled. Instead there are other two options
A recovery key is a 256 bit key that is saved to a flash drive. This method must be done by the end-user and they need to store the key securely. Obviously that isn’t enterprise ready.
The third option is a data recovery agent. A public key is distributed to all BitLocker protected devices. Someone with the matching private key (e.g. me) would need to be physically present at the computer. Apparently even then the OS drive must be installed on another computer running Windows 7 as a data drive.
So basically no recovery options work for us.
4. Standby
BitLocker protection is in effect only when the computer is turned off or in hibernation.
Our current FDE product protects in standby, hibernation or when the computer is off.
Update:This is is no longer true.   a preboot authentication in standby is a false sense of security.
5. Enterprise Manageability
While BitLocker has caught up with third-party encryption products in its ability to encrypt USB drives there are still other areas where FDE vender’s shine. Many FDE vender’s can also encrypt phones and managed hardware based encryption products. It’s a lot more convenient to manage these devices through one vendor.
From my limited reading it seems that there are still a number of items that argue for the continued use of a non-Microsoft FDE product.

Tags: , , , ,
Category: FDE, Microsoft  |  4 Comments

Protecting Sensitive Data in Email

March 29, 2010, 11:25 am

State laws, company/client policy and common sense mandate the encryption of some forms of data. Whether its company secrets, PII (personally identifying information that isn’t already considered public), or ePHI (Electronic Protected Health Information) it is required that users encrypt this data when sent outside of the company, and it is on the IT Department to provide the right tools so this can occur. Bonus points for making it occur seamlessly and automatically.
This post looks at methods for protecting this data in transit via email.
1. S/MIME Encryption using Digital Certificates
S/MIME is built into most email clients. Once the certificate is installed, it is relatively easy to use if both sides have a digital certificate. When the otherside doesn’t have a digital certificate, unless you’re the 800 pound gorilla, good luck getting them to purchase a certificate and learning how to use it.
Most web mail clients do not support S/MIME. One exception is Outlook Web Access.
Cost and the difficulty getting the external user to use a digital certificate make this solution difficult.
2. PGP
PGP is another standards based email encryption solution. While there are free versions, they didn’t work well with Outlook the last time I used them.
This has the same problem as S/MIME in that the external person needs to be running PGP. Again good luck getting your external contact to change their ways.
3. A phone call
In a lot of cases we aren’t talking about moving a Excel spreadsheet of Social Security Numbers. We’re talking just one. A phone call (not leaving a voice mail) could be a lot more secure than email.
4. Encrypted Zip File
Encrypted ZIP files are easy to use, and use software already on many computers.
There are also many problems with Encrypted Zip files. The external mail server may be configured to block encrypted archives. It may not allow zip files at all.
You must pick a password that is good. Then communicate that password to the recipient over a separate channel (not email). If the user wants to use that file at a later date, they are probably going to go back to the original email. They wont have the decryption password anymore, and most likely neither will you. There isn’t a enterprise recovery option.
Encryption in zip files last time I checked was not really a standard. Winzip encryption at AES strength wouldn’t open in other zip clients. That may or may not be the case anymore.
5. Password protected Office document
You could password protect the Office document themselves. I haven’t checked if there are issues with password protected files between Microsoft Office versus Open Office. I do believe to get the best protection you need to use the current version of Office and then earlier versions of Office will have issues.
The same password lifecycle issues that occur with Encrypted Zip files also occur with Office documents.
6. Secure File Transfer Server
Products like Accellion can be used to transfer sensitive documents. These systems work most securely when you set up an account for the external person and communicate the password to them out-of-band. If the system automatically sends a link to the external user when a file is uploaded for them, anyone reading the email who gets there first can snag the file. At least it should be obvious that this has occurred. But the idea is moving files more securely.
7. Mandatory TLS to customer Site
TLS/SSL is what you are most likely using when accessing your bank site with a HTTPS://. It is possible to work with your customer/clients and set up mandatory routes that require TLS on all messages between the two domains.
The main drawback of this is it would need to be done for every customer domain that you deal with. It also encrypts all mail. TLS requires a bit more processing power. Shouldn’t be a problem for well spec’ed servers.
The mail is only encrypted in transport and is stored in the clear on the recipient and sender mailbox.
8. Opportunistic TLS
Opportunistic TLS attempts to use TLS on every mail connection. If it is not supported it sends the email in the clear.
While this means you only have to configure your mail server, you never know for sure that sensitive email is encrypted.
9. Hold for pickup
There are some mail systems that detect sensitive data in transport an then transparently act like the Server File Transfer Server. They notify the recipient that they have a message to pickup. The message is then picked up over SSL.
There are issues with each method of moving sensitive data via Email. But there are many options.

Tags: , ,
Category: General  |  4 Comments

Symantec Password Survey

March 26, 2010, 8:12 pm

Symantec published the results of a survey regarding password habits of people who read their Security Response Weblog. Nearly 450 readers responded. As you readers of a security blog, their responses probably are far from the norm.
Links: http://www.symantec.com/connect/blogs/password-survey-results
Not surprisingly, the respondents have a lot of passwords. 66 percent report having more than 10 passwords. Its hard to keep track of that many passwords. This leads people to do dumb things.
23 percent of respondent let the browser keep track of their passwords. While Firefox can use a master password to secure these stored passwords, I suspect most people dont use that feature. Browser password caches are merely obfuscated and are not a secure place for your passwords.
7% have a note near their computer. This is ok if your office is secured from outside visitors. But even the home office of a hermit occasionally has workman visiting.
11% use a Word document on the computer. Word or Excel documents can be lost if the computer isn’t backed up. It is also not a secure way to store the passwords. If you’re putting all your financial passwords in one place, wouldn’t it be a good idea to secure them. Perhaps they are in Word and password protected. But that wasn’t specified in the survey.
59% rely on memory. Passwords for work should never be in memory only. If you are hit by the proverbial truck how much productivity will be lost regaining access. For more personal accounts, memory indicates possible password reuse at worse or use of a password scheme at best.
33% use a password manager. That’s great but I found out in 2009 that you need to make sure your backups work if you’re relying on this method.
Check out the link for the rest of the results of this Symantec survey.

Tags: , , ,
Category: General  |  Comment

Grade Hacking

March 12, 2010, 8:46 pm

There is a grade changing scandal over at Walt Whitman High School locally in Montgomery County Maryland. A teacher noticed that the grades in the system did not match what he or she entered. Investigation has found 54 changes.
Montgomery County Schools CTO Sherwin Collette said they believe teacher’s passwords were obtained through the use of hardware keystroke logging.
Hardware keystroke loggers are readily available online. Check out this video from irongeek if you aren’t familiar with hardware keystroke loggers. Basically its just like it sounds. A transparent USB or PS2 device that sits between the keyboard and the computer port.
Remember Microsoft’s Immutable Laws of Security number 3. If a bad guy has unrestricted physical access to your computer, then its not your computer anymore.
The best solution to this sort of problem is multifactor authentication. The thinking is that if the password is stolen then it cant be used again later. Of course some systems will allow concurrent logons allowing an attacker to immediately use the learned password. (That wouldn’t work with this device, but keystroke loggers can also use wireless/bluetooth to send the learned information immediately.
People who don’t use multifactor authentication always thinks it costs too much. I wonder how much Montgomery County has spent on this incident. The cost of securing the data should have been part of the original decision to put the grade system online.
Even without strong authentication, other things could be done to protect against this sort of attack. Its not clear if the attackers used the teachers computer. If they didn’t that might get flagged in anomaly detection. Noting that the account was normally used during the day from location A but suddenly was also used from location B at another time.
Displaying last logon and location to the user might have helped. If someone was unusually observant they might notice they didn’t use the account then.
The Post reports that Montgomery County Schools will now have a 120 day password expiration policy. That indicates before they didn’t expire passwords at all. This means a stolen password is only good for one school year. Still a long time.
Some people are taking a “boys will be boys” attitude about this. They dont understand why the police are investigating this as a criminal matter. If they’d stolen a facebook password and vandalized the teachers Facebook page, I might be laughing. With grades they had to know they were doing wrong. And worse yet these false grades were likely used to fraudulently gain admission to college potentially depriving a more deserving person.
Right now all we can do is speculate based on media reports. And worry about whether the businesses we deal with are ready for 21st century attacks.

Tags: , ,
Category: Physical Security  |  1 Comment

Dear Abby on Password Secrecy

February 17, 2010, 8:28 pm

Today’s Dear Abby contained a letter about passwords. It’s the third letter at this link

The letter writer warns against sharing your passwords with anyone. The writer recounts instances where a password shared at one point in a relationship becomes a weapon when the relationship turns sour. People, after the divorce is finalized you need to make sure your ex doesn’t have your bank passwords.

Didn’t expect to be getting security advice from Dear Abby. If these people had followed the standard security advice to use different passwords for each account and change them regularly that alone would have prevented this breach.

Tags:
Category: Uncategorized  |  1 Comment

Common Sense

February 8, 2010, 8:23 pm

Does anyone really think that sneezing into your arm is common sense? I suspect that if you do you must have small kids and have been trained by some sort of Elmo video. I don’t recall any mass agreement on sending snot flying into my shirt sleeve as a method of good hygiene.
At Shmoocon Bruce Potter compared the common sense of sneezing into your sleeve (to him apparently a good thing) with common sense security steps. Maybe he’s right, a password policy is kind of like getting snot all over yourself.
My notes seem to have mangled the opening remarks from Shmoocon 2010. The general summary is that it’s a waste to spend a boatload of money on security when you don’t have your policies and procedures clear. You’ve got to start with the basics.
A password policy needs to be applied consistently across all systems. Often the development can be compromised and then hop back across to the production systems. The dev systems need policy as well.
Network segmentation is important. Soft gooey center anyone?
Auditing. If you aren’t watching, how do you know something bad happened.
We laugh at the TSA, but they have fair less fail in their results.

Tags: ,
Category: General  |  5 Comments
« Previous Entries
Next Entries »