Wednesday, 29 May 2013

Snooping law = criminals 1 : public 0

The unfortunate event in Woolwich last week has opened a debate about police powers to monitor citizens' communications.
It has been proposed that ISPs are obliged to record "envelopes" of messages and website visited. This is not unusual given existing powers related to voice calls and text messages. However, then proposals seems to ignore how Internet works, and advances in open cryptography.

First, many people do not use their ISPs email service, and instead opt for 3rd party email services such as Gmail, Hotmail, Yahoo to name few. The common feature of these services is that the access to emails is performed over and encrypted channel. ISPs have not technology means, short of installing their root Certificate authorities into everyone's computers, to monitor these messages. In other words, the proposals would only allow monitoring of small percentage of citizens, very likely law abiding, who should NOT be in the snooping law focus.

Second, any computer skilled criminal will most likely use bespoke email provider, or end to end encrypted IM messages. There are open protocols, such as OTR, to enable this capability for open source IM services. There is not chance to snoop on the messages at the ISP level. The only viable place to see the messages is an end point computer where the IM message is sent or received.

Make no mistake, accepting taking our liberties for freedom and privacy of communication in the name of catching criminals will be used against us in non criminals procedures in the future. Let's make it clear this is not acceptable and the arguments for snooping are ill conceived.

Wednesday, 15 May 2013

Security Think Tank: context-aware security is business-aware security

This article first appeared in Computer Weekly in March. The original link is here: http://www.computerweekly.com/opinion/Security-Think-Tank-context-aware-security-is-business-aware-security


The static security policy decisions are over. Is your firewall still only a dumb IP based firewall that allows or blocks access based on IP addresses? What about contextual information such as: identity, location, data transferred and behaviour of the traffic?

Tuesday, 15 January 2013

Encryption in the Cloud - techniques for data protection

I will be talking about Cloud data security and encryption during BrightTalk summit on Cloud security tomorrow.
Please join me tomorrow (16th January 2013) at 9am GMT. The link to the webcast is here.
A BrightTALK Channel

Wednesday, 12 December 2012

Adobe limiting maximum password length - seems suspicious

Yet again, I have stumbled on a company that limits maximum password length. This time it is a giant software vendor, Adobe. I simply wanted to change my password on my Adobe account and generate a new strong password using Lastpass. However, the website limit the password length to 12 characters.
As you know there maybe various reasons why such a limit could be set. Not wanting to guest what the reason is I started a chat with the Adobe support representative. Here is the transcript:


Chat InformationThank you for choosing Adobe. A representative will be with you shortly. Your estimated wait time is 0 minute(s) and 17 second(s) or longer as there are 1 customer(s) in line ahead of you.
Chat InformationYou are now chatting with 'Amodh'
Amodh: Hello! Welcome to Adobe Customer Service.
Amodh: Hi Vladimir.
Vladimir Jirasek: Hello
Amodh: I understand you want to know why there a limit for maximum password length. Is that correct?
Vladimir Jirasek: yes, I am concerned about this restriction
Vladimir Jirasek: I want to use longer passwords
Amodh: Thank you for the confirmation.
Amodh: I will be glad to check and help you with this issue.
Vladimir Jirasek: well its not the issue. It's a problem
Vladimir Jirasek: Issue is defined as isolated while problem is typically systemic
Vladimir Jirasek: I am not the only one who is restricted by the password length
Vladimir Jirasek: I am a security professional and typically the password restriction like this indicates insecure practices in storing the passwords in the database
Amodh: Thank you for the Information.
Amodh: Thank you for your patience.
Vladimir Jirasek: so I am interested to know why there is this restriction and if my passwords are stored securely (hashed or encrypted)
Amodh: Vladimir, there is a limit of  maximum password length so that customer can remember the password.
Vladimir Jirasek: :) I am using a password manager to generate random passwords and remember it for me. If other customers want to use short passwords it's up to them but there is no reason to limit me in using strong passwords
Vladimir Jirasek: next question is: are the passwords stored securely?
Amodh: Yes, Your passwords stored securely.
Vladimir Jirasek: how
Amodh: Vladimir, In this case I request you to please contact our phone support, they are the specialized team to help you on this issue.  
Amodh: Here is the phone number to contact Phone support team:800-833-6687.
Amodh: Please do make a note of the above number.  
Amodh: Apart from this, Is there anything else I can help you with from my end?
Vladimir Jirasek: ok, thank you that all. Is that number UK?
Amodh: Here is the Phone Support number for UK: 0207 365 0735.
Amodh: I'm happy to help. Do you have anymore questions for me?
Vladimir Jirasek: Thank you. Have a good day

The poor guy (assuming I was chatting to male) did not have much choice but to follow the script. I will call the Adobe support on the number provided to find out more. At least the company has a response ready for such questions: "Convince for customers so they do not forget the passwords." 

To be continued ...

Friday, 16 November 2012

Speed degradation on Nexus 7 after enabling full encryption

I have had my new Nexus 7 for 2 weeks now. It's now been updates to Android 4.2 after which I enabled the full disk encryption. Unlike in iPad, the encryption requires per-boot password which can be different from the screen lock password.

The encryption process took around an hour. However when it finished and rebooted I was shocked! The fast and snappy user experience was gone. All this despite nexus having quad-core CPU and 12 core GPU. It almost seems like the operating system, especially the kernel module responsible for decryption operations , is not optimised for using the powerful hardware it runs on!

I am sure Google had not optimised this as not many people, probably just hard core security professionals, do enable encryption. This should be as wakeup call for Google! If nexus and android is to succeed in enterprises and governments the encryption needs to be enabled by default without performance penalty!

Now I face the dilemma: should I a) return the device to John Lewis based on this usability issue, b) accept performance degradation, or c) restore the device to factory settings and use it without encryption? What would you do?

Sunday, 30 September 2012

Password changes: how often is too much?

Passwords, this single factor authentication method, have been with us for a long time.

These groups of characters have one thing that annoys people using them: many corporations require regular password changes. For some unknown reasons, probably told by evening fired from generation to generation, many security standards require password changes. When you try to find out why, you get answers: "Required by PCI DSS..." Or "Our security policy requires that."

Let me just say that requiring password changes without actually understanding why is crime against poor user population. These users are taken hostage by security managers and as a result create weak passwords. In many cases the only character changing in these passwords is the number at the end, usually incrementally increasing.

Let's try analyse when it would make sense to force the password change:
1. When the password is compromised, i.e. stolen from the user or a system.
2. When suspicious activity is detected which suggests that it is not the legitimate user performing these actions.

Furthermore, I believe the password change interval should be function of the following:
1. Password complexity - the more complex password is the more difficult it is to brute force the password, or even capture it user shoulder surfing. The more complex password is the less frequently is must be changed
2. Level of monitoring of the password misuse - if I gave SIEM system and processes to analyse events and detect misuse then password do not need to be changed that often
3. Account lock-out settings - brute-force protection really helps in reducing frequency if required password changes
4. Use of two-factor authentication - this adds more protection to all points above

If points 1-3 are in place I argue that requiring password changes every 180 days is probably reasonable. Add two- factor authentication and the argument for password changes goes away.

What do you think?