After april 8th 2014 Microsoft will no longer support Windows XP. Microsoft will publish no new security pathches for vulnerabilities and Security Essentials will only provide new malware signatures for a short while. Windows XP will be orphaned. By Microsoft. But many consumers and companies still use XP systems. They will be at risk. Because XP will not be orphaned by criminals. Vulnerabilities in newer Windows versions will be patched, but since all Windows versions since NT are related, chances are that a vulnerability in a more recent version is a vulnerability in XP too. While it will be fixed in Vista, 7 and 8 and will no longer be a vulnerability in those systems, such a vulnerability will still exist in XP and will be exploited by criminals. From april 8th this will be bad luck for XP users. At least for consumers. Most consumers will run a fully patched XP system, since Microsoft advises you to. So, for consumers to move to a more recent operating system is the only way to stay secure. But so far consumer pc's are not a big problem.
But there is an even bigger risk and it is not even a new risk: Enterprises and other organisations running XP systems. Those organisations have a serious problem. If they still run XP, then they have a change management problem. Commercial support for XP ended long time ago, meaning that they gambled that they would not need any support.
And we may have a big problem with that. In professional surroundings most workstations are managed centrally, from an update server. Patches are not downloaded directly from the Microsoft servers, but these organisation distribute patches in releases after they tested the patches. And such a process may take a while. Many companies roll-out new releases once in a while, two or three month intervals are common. Changing more frequent is often seen as a risk, because these (unsupported) systems better not be touched. Never change a winning team...
Will these systems be at risk after april 8th? Sure. Are they at risk now? You bet. If a company is still running XP at this moment, chances are that older patches have not been applied either. Stay away from organisations running XP, the problem is bigger than you imagined.
donderdag 27 maart 2014
woensdag 26 maart 2014
Complex passwords? As easy as 1-2-3
A
few posts back I promised you an new and easy method for
composing complex passwords that are, nevertheless easy to remember.
First
some background to password complexity.
Why do
we need complex passwords in the first place?
We
don't.
There
are two real reasons, we are told, why need complex passwords.
The
first one is that a complex password is more difficult to remember,
thereby reducing chances of password leakage. But at the same time
creating the Post-It note problem of people writing down the
password.
The
second is that a complex password takes more time to attack using
brute force password cracking techniques, but it doesn’t
in itself prevent the use of dictionary based password cracking
techniques. A dictionary based attack compares the hashed password in
a password file to a words in a dictionary that are hashed using the
same hashing algorithm.
If the hash of a word in a dictionary is the same as the hash in a
password file, then the corresponding word is the password. A clever
cracking tool subsequently tries several permutations
of the word, by replacing lower case letters by upper case letters or
numbers or symbols, 'P@ssw0rd' will be
discovered just as quick as 'password'.
That way using leetspeak
doesn't make password more secure that regular speak. If a word is
not in the dictionary, another technique is required: just trying out
all combinations to see is a hash resembles a hashed password of the
target account. And in all simplicity that means that the longer the
password, the more time it costs to crack it.
This
leads to 2 simple conclusions.
- First: if a cracker uses an English language dictionary, he will not find my Dutch language word, meaning that will have to resort to a brute force attack...
- Second: for a brute force attack the password '1234567890' is just as complex to crack as '6Gr*7jgkhi'. It will probably be found faster because clever cracking tools will know this too and will use this kind of 'semi-dictionary' cracking words too, but in a sense: if a word is not in a dictionary, brute force requires a lot more time if the password is longer.
Proof
of this principle:
The old
Windows OS uses the lanman hashing algorithm. A password was broken in
2 7-byte segments, that were hashed separately. The hash of a 7
character password was enlarged to a 14 character password by adding
a 7 character long Null string hash. If not more than 7 characters
were used, the second hash was always the same. So, although the
hashed password was 14 characters long, when the password was not
longer that 7 characters, cracking the first 7 characters was enough
to guess most passwords. If an 8th character was used, brute forcing
the complete 14 character password was required.
In effect, this is
the reason why many password policies prescribe the use of minimal 8
characters.
This
results in a few simple rules:
Use
long words that are not in a (regular) dictionary... German speaking
people have an advantage here...
Use
non-words that are long enough to make brute forcing a lengthy
operation but that are easy to remember.
My
advise:
Use
your telephone number, but use leetspeak backward.
Example:
phone number 01 234 567 89 consisting of only numbers.
Just
exchange a few numbers to letters/characters in such a way that you
feel comfortable with. A '0' can be an O (oh), or Z (for zero) or N
(for Nul), in lower case or upper case, your choice.
So,
this simple example may result in NE2D4vzZ8n or zOt3f5sse9. You just
need to remember the order of hashing, but you don't need to remember
the password, just remember the phone number used.
The
entered password may look familiar if you know the algorithm used,
but to a password cracking tool these passwords look all very
different (all MD5 hash examples):
0123456789
> 84D89877F0D4041EFB6BF91A16F0248F2FD573E6AF05C19F96BEDB9F882F7882
NE2D4vzZ8n
> 4DB3EA7E7894603A00091C8AABA25556B0366CF4C7045CF5B862477B44357040
zOt3f5sse9
> 4A384192BB6933877D9B7E29993DE7AF1EBC191DE6C30289F13F084EFD332B1B
Compare
that with:
password
> 5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8
If a
cracker can get at your hashed password, the cracker has no way of
knowing how you defined your password. Make it as easy as you can.
We
don't need complex passwords. And in a future post I will expand on
this some more.
donderdag 20 februari 2014
Facebook and Whatsapp, why worry?
The deal of the year, Facebook buys Whatsapp. And even before the dust settles, the privacy world is screaming murder. The privacy denying company buying a private messaging company spells doom for the privacy of hundreds of millions of users. You are warned to leave Whatsapp if you care for your privacy...
But is your privacy really at stake? Is the merger a new threat?
Facebook knows a lot about you. It knows your friends and relations, your likes, your updates, your whereabouts and it even knows what you would like to post but never really did. Facebook not only has access to your metadat, it has all content as well.
Whatsapp knows a lot about your telephone number. It knows the telephone numbers your phone number connects with and it has an enormous amount of metadata of all connections made.
And since both companies are American, you can bet that the NSA and it's friends have access to these (meta)data too.
But, and it's a big but, as long as a Facebook profile doesn't contain a telephone number, Facebook has no way to connect a profile with all Whatsapp metadata. There is no way to correlate a human profile with a phone profile.
It's a big but, but Facebook and Whatsapp live in different worlds en never the twain shall meet. So in my opinion there is no new privacy risk. If you really care for your privacy surely you would have left Facebook a long time ago?
So as far as I 'm concerned there is no need to dump Whatsapp. There are bigger threats to your privacy.
There's a second but, and that's a bit more tricky. A Facebook app and a Whatsapp app on a smartphone are different apps and they don't share between them, the operating system of the smartphone takes care of separation. Unless the operating system doesn't. I would say, stay away from any Facebook marketed phone...
So, until Facebook asks for your phone number, or you provide your phone number to Facebook, don't worry.
But is your privacy really at stake? Is the merger a new threat?
Facebook knows a lot about you. It knows your friends and relations, your likes, your updates, your whereabouts and it even knows what you would like to post but never really did. Facebook not only has access to your metadat, it has all content as well.
Whatsapp knows a lot about your telephone number. It knows the telephone numbers your phone number connects with and it has an enormous amount of metadata of all connections made.
And since both companies are American, you can bet that the NSA and it's friends have access to these (meta)data too.
But, and it's a big but, as long as a Facebook profile doesn't contain a telephone number, Facebook has no way to connect a profile with all Whatsapp metadata. There is no way to correlate a human profile with a phone profile.
It's a big but, but Facebook and Whatsapp live in different worlds en never the twain shall meet. So in my opinion there is no new privacy risk. If you really care for your privacy surely you would have left Facebook a long time ago?
So as far as I 'm concerned there is no need to dump Whatsapp. There are bigger threats to your privacy.
There's a second but, and that's a bit more tricky. A Facebook app and a Whatsapp app on a smartphone are different apps and they don't share between them, the operating system of the smartphone takes care of separation. Unless the operating system doesn't. I would say, stay away from any Facebook marketed phone...
So, until Facebook asks for your phone number, or you provide your phone number to Facebook, don't worry.
vrijdag 7 februari 2014
Trust is a one way affair
Cleaning up my blog and I found this snippet of text, waiting for further investigation. Feel free to join the discussion:
Any digital identity can only be trusted, as much as the identity provider (who provided the digital identity) can be trusted. If you don't trust an identity provider, you shouldn't trust it's identities. Seems logical. And even if you do trust the identity provider, you don't have to trust the digital identities from that provider. And you may trust the identity provider, but that is no guarantee that you can trust the digital identities. Or better... there is still no guarantee that there is a real individual behind the digital identity. It all depends on the identity management processes of the provider. But how can you tell which digital identities belong to real individuals?
What's the problem: if someone creates an account on my site, is that identity more reliable than an identity from a third party identity provider, that I may or may not trust?
If the identity is used only for identifying a website user for personalization purposes, then why not allow the use of any identity, trusted or not. If you allow extra permissions for that identity user, then that's up to you.
Allowing permissions for whatever task, should be based on a risk assessment, thereby taking into account classification of information and processes. Then you decide what level of trust is required. And it's up to you to decide what kind of identity is sufficient. It could imply that a gmail or twitter identity is enough for users to log into your site.
Perhaps that's why I don't like current trust models. They are too complex for most purposes. If people trust you to service them, that in itself is no need for you to trust them as well. Why should you? Only if you want them to service you, or get stuff from you and then pay you for it, then you should trust them. Until then, trust is a one way affair.
Any digital identity can only be trusted, as much as the identity provider (who provided the digital identity) can be trusted. If you don't trust an identity provider, you shouldn't trust it's identities. Seems logical. And even if you do trust the identity provider, you don't have to trust the digital identities from that provider. And you may trust the identity provider, but that is no guarantee that you can trust the digital identities. Or better... there is still no guarantee that there is a real individual behind the digital identity. It all depends on the identity management processes of the provider. But how can you tell which digital identities belong to real individuals?
What's the problem: if someone creates an account on my site, is that identity more reliable than an identity from a third party identity provider, that I may or may not trust?
If the identity is used only for identifying a website user for personalization purposes, then why not allow the use of any identity, trusted or not. If you allow extra permissions for that identity user, then that's up to you.
Allowing permissions for whatever task, should be based on a risk assessment, thereby taking into account classification of information and processes. Then you decide what level of trust is required. And it's up to you to decide what kind of identity is sufficient. It could imply that a gmail or twitter identity is enough for users to log into your site.
Perhaps that's why I don't like current trust models. They are too complex for most purposes. If people trust you to service them, that in itself is no need for you to trust them as well. Why should you? Only if you want them to service you, or get stuff from you and then pay you for it, then you should trust them. Until then, trust is a one way affair.
zondag 8 december 2013
Stepping up cybersecurity
We love hypes and in our profession cybersecurity is a hype that doesn't stop to be a hype. The #ditchcyber campaign is started to help busting the hype. Well, allright, let's just add to the hype.
Here are some links to documents that may help you deal with cybersecurity.
Confused? Just pick the 9 steps ebook (by Dejan Kosutic). He clearly shows that cybersecurity is just a subset of Information security.
Enjoy.
Here are some links to documents that may help you deal with cybersecurity.
- 3 steps to Cybersecurity
- 4 steps to Cybersecurity
- 5 steps to Cybersecurity
- 6 steps to Cybersecurity
- 9 steps to Cybersecurity
- 10 steps to Cybersecurity
- 10 steps to cybersecurity
- 12 steps to Cybersecurity (warning: direct pdf download)
- 21 steps to Cybersecurity
- Sensible steps to Cybersecurity
- Big step to Cybersecurity
- First step to Cybersecurity
Confused? Just pick the 9 steps ebook (by Dejan Kosutic). He clearly shows that cybersecurity is just a subset of Information security.
Enjoy.
donderdag 14 november 2013
Adobe lesson learned: do not use complex passwords!
By now we all learned about yet another password leak, this time at Adobe. Not just some incident, no, it's a big one, with some 130 million passwords in the open. A big scandal too. And of course we are amazed at the large number of too obvious passwords chosen by the Adobe customers. Passwords like '123456' and 'secret' are amongst the most frequently chosen passwords. Are we really surprised? No of course not. We already knew that people are not very aware about the security risks involved.
Who are those customers? They are people like you and me, consuming services anywhere on the internet, Services like those offered by Adobe. And for most of those services the provider wants to know who you are by asking you to register an account. So, many of us did.
Accounts
Let me tell you about the way I create accounts. In order to protect my privacy I have to protect both my identity and my behavior. So I try to separate my digital life from my real life as much as possible. And I bet that I'm not alone in this. My preferred method is to create an account using an alias. And since providers want to reach my alias, I need to provide an email address. If possible I use a disposable, or a fake email address. Next I have to pick a password. '123456' will do just fine. Why?This password is not there to authenticate, it's there because the provider wants me to provide a password to ensure my permission to use a service. But I didn't use a real digital identity, I just claimed some capacity to download whatever I want from the provider. I don't care about protecting it, because in real life it just doesn't exist, and in all fairness, it's worthless. In fact I may have created an Adobe account a long time ago, but I don’t even remember it. And if I don't care, it's just not relevant how secure it is or how complex the password is. The only thing that I need to take care of is to NOT use one of my regular identities and passwords.
That's my real protection. As long as a provider or a hacker for that matter, cannot link the non-existing identity with a real identity, there is no danger for my real privacy if the provider or hackers publish '123456'. I couldn't care less. So, lousy providers like Adobe are not really a risk for me. I was right in not trusting them.
A far better way for providers to connect to customers would be to let them use an external identity, that way you don't need to register an account with the provider and the provider doesn’t need to protect it, there is no password... If you are free to pick an external identity like facebook, Twitter or LinkedIn, then the risks of data leakage are far less. There's another privacy issue, because those identity providers know your interests because of the federation stuff. I will not elaborate on this issue, but if you have enough digital identities, every identity provider only knows part of your interests, part of your activities and thus part of your identity. Divide et Impera.
Threats
The Adobe leak led to a lot of noise in the security community. There were two main comments: Adobe is stupid by not enforcing better security, I agree. And: users are stupid for using simple passwords, well, I don't fully agree. And I will explain this:Account and identity management is tricky. There are two risks:
1) Someone knows you and tries to steal your identity.
2) Someone knows your password and your login name and tries to find out your real identity and reuse that information
The first risk can be real, but it need not be that big, provided that you think about a few best practices. Protect your behavior. If someone doesn't know to relate your real identity to a digital identity, not a lot of harm can be done in the digital world, in Cyberspace.
As I mentioned, the second risk can be neglected as well, if you understand it and act upon it. I hope/believe that most of the Adobe top 20 passwords are used by people who knew this. In my opinion most of the accounts used are disposable accounts. And preferably accounts that cannot be linked to real identities.
Password complexity
Both reactions to the Adobe leak came down to one issue: password complexity. Fact was that Adobe didn't enforce password complexity, not in the user space, not by using good practices for cryptography. Second fact: lots of users didn't use complex passwords.Password complexity is difficult. A password needs to be complex for a few reasons:
- You don't want it to be easily guessed by someone who knows your digital identity.
- You don't want it to be easily cracked by someone who has access to your encrypted password.
Yet at the same time you want it to be easily remembered, by yourself.
The first risk is in fact the risk that we need to manage to mitigate the threat of someone who knows you to steal your digital identity, that's the first identity risk. It's the risk of someone retrieving an identity => password combination based on known identity information.
The second risk is more difficult to manage. The enormous amounts of processing power makes this risk hard to mitigate, password cracking isn't that hard to do anymore. This risk works the other way around: someone tries to retrieve a password => account combination based on known password information. Encryption of the password in transit and in storage does help safeguarding the password information, but it will probably only help temporarily. So we are trying to use one measure, password complexity, to tackle different risks. This may seem efficient, but in fact it's not what we need to do.
In order to prevent identity => password retrieval, we need password complexity. No one should be able to retrieve a password based on identity knowledge alone.
One example is Phishing: an attacker tries to retrieve secret information from a known identity. That means that the real, or physical identity => digital identity => password trail needs to be protected. And since the password is the valuable item, the password needs to be secured. That means using complex passwords (and to fight phishing: educate users to not hand over secret information!).
To prevent retrieval of a valuable identity based on a found password, another mechanism is required. If someone retrieved a password, he may be able to retrieve the digital identity, but he should not be able to retrieve the real identity behind the digital identity. Why?
This might lead to misuse of the identity => password risk!
If the password => identity trail can be found, an attacker might gain knowledge to intercept other identity => password combinations. The identity is the valuable resource, so you need to protect your identity. And the best way is to use disposable identities or external identities in those cases that you have to trust providers.
This leads to an interesting conclusion
Adobe user accounts with complex passwords, may well be more at risk than accounts with easy to guess passwords: customers using a complex password may well have used a valuable identity, expecting the complex password to protect it. How about that?
In my next post I will introduce a real simple complex password method.
Labels:
federation,
identity,
password,
privacy,
security
vrijdag 4 oktober 2013
What US-Cert should have said about the Adobe hack
This is what US-Cert said in a rather pointless advise:
"US-CERT advises that Adobe customers be aware of possible fraudulent account activity."
What US-Cert should have said instead: Advise for Adobe customers: If you have an account at Adobe: Change your password.
But that's not all: If your Adove account has a username/password combination and/or emailaddress that you use for other websites services as well, change your password on all the other sites too.
And perhaps, if US-Cert could spare some time and effort (thank you #shutdown) they could have added this:
Advise for all service providers: Get rid of password management by moving to federation protocols like OAuth or OpenID Connect. If you don't store passwords, you can't lose them.
And an advise for Adobe and all other providers: Please don't ignore secure programming guidelines.
What US-Cert should have said instead: Advise for Adobe customers: If you have an account at Adobe: Change your password.
But that's not all: If your Adove account has a username/password combination and/or emailaddress that you use for other websites services as well, change your password on all the other sites too.
And perhaps, if US-Cert could spare some time and effort (thank you #shutdown) they could have added this:
Advise for all service providers: Get rid of password management by moving to federation protocols like OAuth or OpenID Connect. If you don't store passwords, you can't lose them.
And an advise for Adobe and all other providers: Please don't ignore secure programming guidelines.
Abonneren op:
Posts (Atom)