FLASH: Hansard: Minister admits: “There is no offence of cybercrime in law” /ht @gwire #cybersecurity

Cybercrime: 13 Feb 2013: Hansard Written Answers and Statements – TheyWorkForYou.

Parliamentary Under-Secretary of State for Crime and Security:

Screen Shot 2013-02-15 at 14.27.43

Quote:

The Government’s Cyber Security Strategy made it clear that there are crimes which only exist in the digital world, in particular those that target the integrity of computer networks and online systems. However, the internet is also used to commit crimes such as theft and fraud, often on an industrial scale.

The internet has provided new opportunities for those who seek to exploit children and the vulnerable.

There is no offence of cybercrime in law. Offences involving illegal access to computer systems may be prosecuted under the Computer Misuse Act 1990, but many other offences committed online would be prosecuted under legislation dealing with the substantive offence, such as fraud.

The walls are starting to crack. Massive hat-tip to @gwire

Eventually a tech reporter notices the fracas and chimes in to tell us the whole Infosec community is a bunch of jerks

In a nutshell, this keeps happening:

Silent Circle’s an interesting case, since it’s gotten some gentle criticism lately from a variety of folks — well, mostly Nadim Kobeissi — for being partially closed-source and for having received no real security audits. Nadim’s typical, understated critique goes like this:

And is usually followed by the whole world telling Nadim he’s being a jerk. Eventually a tech reporter notices the fracas and chimes in to tell us the whole Infosec community is a bunch of jerks:

And the cycle repeats, without anyone having actually learned much at all. (Really, it’s enough to make you think Twitter isn’t the right place to get your Infosec news.)

Yep. And we need more, diverse and less judgemental reporters.

Update: Incidentally, the Tweet that Quinn took exception to is this:

How this is juvenile Why we should do without charm and humour when on Twitter and amongst our own kind, eludes me. Perhaps infosec people are meant to be serious about everything?

Massive HT to @matthew_d_green and @marshray

Regrettably @Mat Honan is Entirely Wrong about “Killing Passwords” /cc @Wired

I’ve read Mat’s article and I know where he’s coming from.

Mat’s article does make some sense – and his story is near tragic:

This summer, hackers destroyed my entire digital life in the span of an hour. My Apple, Twitter, and Gmail passwords were all robust—seven, 10, and 19 characters, respectively, all alphanumeric, some with symbols thrown in as well—but the three accounts were linked, so once the hackers had conned their way into one, they had them all. They really just wanted my Twitter handle: @mat. As a three-letter username, it’s considered prestigious. And to delay me from getting it back, they used my Apple account to wipe every one of my devices, my iPhone and iPad and MacBook, deleting all my messages and documents and every picture I’d ever taken of my 18-month-old daughter.

…but he suggests a course of action – disposing of password security – borne out of fear rather than reason; and unfortunately passwords are architecturally very sound.

I’ll recap some of those architectural principles in a moment.

But look at the arguments that Mat makes about passwords:

Requiring you to remember a 256-character hexadecimal password might keep your data safe, but you’re no more likely to get into your account than anyone else. Better security is easy if you’re willing to greatly inconvenience users, but that’s not a workable compromise.

This risk is solvable using password management software. Won’t work for 100% of situations but can be made to work for better than 95% of them.

He then makes a weird argument for privacy from the following thought experiment.

Imagine a miracle safe for your bedroom: It doesn’t need a key or a password. That’s because security techs are in the room, watching it 24/7, and they unlock the safe whenever they see that it’s you. Not exactly ideal. Without privacy [from the security techs] we could have perfect security, but no one would accept a system like that.

Well, actually, it is ideal, and also viable so long as you get away from his strawman argument; I discuss the desirability of being able to demonstrate who you are rather than use identity proxies (such as driving licenses, passwords or digital certificates) in Hankering For A World Without “Identity” or “Federation”.

But what he’s trying to say is that having systems somehow be smart enough to know it’s you is not really acceptable from a privacy perspective, and I can agree with that for some perspectives in authentication.

There’s a long diatribe slinging mud at passwords in general – mentioning some upstart software like John the Ripper in process 🙂 – and pads out the article with stories of people who have suffered.

Then there’s a sidebar called How to Survive the Password Apocalypse which is actually full of really good advice; it’s the sort of stuff that everyone should do even if it contains suggestions like “give bogus answers to security questions” – a topic that British MPs and Tabloids are apt to get exercised about.

Then there’s a complaint that “passwords are hard to remember”, and then there is cybermafia padding and “How One Guy Had His Google 2-Step Authentication Broken”, and then we get down to:

The age of the password has come to an end; we just haven’t realized it yet. And no one has figured out what will take its place. What we can say for sure is this: Access to our data can no longer hinge on secrets—a string of characters, 10 strings of characters, the answers to 50 questions—that only we’re supposed to know. The Internet doesn’t do secrets. Everyone is a few clicks away from knowing everything.

Instead, our new system will need to hinge on who we are and what we do: where we go and when, what we have with us, how we act when we’re there. And each vital account will need to cue off many such pieces of information—not just two, and definitely not just one.

No. Sorry but no. The problem of password security is eminently solvable:

  • don’t let users choose guessable passwords
  • encourage/force users to use password management software
  • protect the hashes on the backend with something decent ie: bcrypt()

…and this needs to happen because the benefits of passwords as a technology are huge:

  1. passwords are easy to deploy
  2. passwords are easy to manage
  3. passwords don’t require identity linkage between silos – so your Google username can be different from your Skype username, can be different from your SecretFetishPornSite.com username
  4. passwords are scalable – you can use as many different ones as you like
  5. passwords can be varied between silos so that loss of one does not impact the others
  6. passwords don’t (necessarily) expire
  7. passwords are the purest form of authentication via ‘something you know’, and thus ideal for the network or “cyber” environment.
  8. you don’t need to pay an intermediary or third-party a surcharge just to get a new password, nor to maintain an old one

…so long as you ameliorate each of the related disbenefits:

  1. passwords are easy to deploy
    which means they’re used everywhere
  2. passwords are easy to manage
    which means they’re managed haphazardly
  3. passwords don’t require identity linkage between silos
    but people are generally too lazy to maintain more than one or two identities
  4. passwords are scalable
    but people are generally too lazy to remember more than one or two passwords
  5. passwords can be varied between silo
    but people are generally … see above
  6. passwords don’t expire
    but most of them are guessable in a matter of minutes or hours
  7. passwords are ‘something you know’
    and so anyone who knows your password is indistinguishable from you

…which amelioration the above “use password managers to protect decent passwords, and keep them well” solution largely does.

So, why? Why do I insist we cling on to passwords in the face of Mat’s suggestion that:

Two factors should be a bare minimum. Think about it: When you see a man on the street and think it might be your friend, you don’t ask for his ID. Instead, you look at a combination of signals. He has a new haircut, but does that look like his jacket? Does his voice sound the same? Is he in a place he’s likely to be? If many points don’t match, you wouldn’t believe his ID; even if the photo seemed right, you’d just assume it had been faked.

…which all sounds terribly secure?

The reason to cling onto passwords is that they are a distributed, non-hierarchical technology.

In short: there’s a lot less that can go wrong when the identities are discrete and thinly spread.

So, sorry Mat. You’re wrong all the way up to this point – but then you go and add:

The security system will need to draw upon your location and habits, perhaps even your patterns of speech or your very DNA.

We need to make that trade-off, and eventually we will. The only way forward is real identity verification: to allow our movements and metrics to be tracked in all sorts of ways and to have those movements and metrics tied to our actual identity. We are not going to retreat from the cloud—to bring our photos and email back onto our hard drives. We live there now. So we need a system that makes use of what the cloud already knows: who we are and who we talk to, where we go and what we do there, what we own and what we look like, what we say and how we sound, and maybe even what we think.

That shift will involve significant investment and inconvenience, and it will likely make privacy advocates deeply wary. It sounds creepy. But the alternative is chaos and theft and yet more pleas from “friends” in London who have just been mugged. Times have changed. We’ve entrusted everything we have to a fundamentally broken system. The first step is to acknowledge that fact. The second is to fix it.

…and I’m afraid that if I were to enumerate the fearmongering number of ways that you’re wrong here, I would not finish this posting tonight.

Perhaps I’ll come back to it.

In the meantime, please reach out to Privacy International.

Regulators, Password Hashing & Crypto considered as a Branding Exercise: #bcrypt #security /cc @schneierblog @glynwintle

Pardon the rambling, mildly-edited nature of this, but: earlier this year, Whit Diffie mailed me and asked:

What is your view of BCrypt and how does it relate to the algorithm you did for Sun? I can’t recall whether yours was earlier or later, so I don’t know whether to ask why you didn’t use BCrypt.

…and I replied, cc’ing Ulrich Drepper:

Hi Whit, [cc: and Hi Ulrich]

On 15 Jun 2012, at 05:19, Whitfield Diffie wrote:

What is your view of BCrypt

  • Niels Provos
  • Good guy
  • Blowfish based
  • Limited to [72 character] passwords but that’s OK/ish.
  • Good (i.e.: memory hungry) expansion phase means it’s unlikely to be put on a GPU any time real soon.**
  • Strong branding – relevant function name with few ambiguous clashes – unlike SHA256-FOO-PBKDF2-BAR branding of some password-hashing-friendly algorithms that confuse web developers who only hear SHA-256 and use that instead

If you want to take a message to your next crypto conference, please tell them that they need to start branding their algorithms because the ignorant code monkeys get confused easily.

For all of of the above reasons – especially the latter, no joke – I recommend bcrypt() to the universe for almost ALL applications of password hashing.

[…deletia…]

and how does it relate to the algorithm you did for Sun?

[It was an] Elegant, amusing hack which addresses some, perhaps most of the issues that bcrypt() does – but which suffers from:

  • being from Oracle now
  • being based on MD5 which though quite legitimate in these circumstances has had its reputation trashed amongst the semi-literate security geeks
  • having the name SunMD5 which contains the name MD5 which – previous point aside – means people think they can use any old MD5 library and get most of the benefit for cheap; but the reputation-trashing has also done for that

Had we called it hiccough or something bizarre, it might have taken off and survived to this day.

I can’t recall whether yours was earlier or later, so I don’t know whether to ask why you didn’t use BCrypt.

Because the point was not to come up with a new algorithm, that was just a sideline to generate some new ideas and to show off the benefits of the new Pluggable Crypt API that Casper, Darren and I designed; and it evidently worked:

http://en.wikipedia.org/wiki/Crypt_(Unix)#SHA2-based_scheme

The commonly used MD5 based scheme has become easier to attack as computer power has increased. Although the Blowfish-based system has the option of adding rounds and thus remain a challenging password algorithm, it does not use a NIST-approved algorithm. In light of these facts, Ulrich Drepper of Red Hat led an effort to create a scheme based on the SHA-2 (SHA-256 and SHA-512) hash functions. The printable form of these hashes starts with $5$ or $6$ depending on which SHA variant is used. Its design is similar to the MD5-based crypt, with a few notable differences:

  • It avoids adding constant data in a few steps.
  • The MD5 algorithm would repeatedly add the first letter of the password; this step was changed significantly.
  • Inspired by Sun’s crypt() implementation, functionality to specify the number of rounds the main loop in the algorithm performs was added. The specification and sample code have been released into the public domain.

…but RedHat made the cardinal mistake of calling the algorithm SHA2 which means that nobody is going to use it because normal people can’t distinguish between that and the family of other cryptographic hash functions.

If they had named it bongweasel or something the community would be all over it now.

Perhaps it’s time to do a Pidgin-like rebranding exercise on it?

…Drepper – being the author of the algo above – replied:

You’re missing the reasons for the new implementation and also why anything like bcrypt is completely unusable: regulators.

The regulators in certain industries only “know” that

  1. MD5 == bad
  2. SHA-2 == tested and not broken
  3. any other crypto algo == [extra] work for them

This is why SHA-2 was used and why having SHA in the name is necessary.

I don’t say that these are good reasons. But you deal with the government and InfoSec departments…

Drepper has credentials with financial services; however I responded:

I get that; however I think it’s easy to say “PseudoBrandableName, which is based on the SHA-2 algorithm” – compare: “bcrypt() which is based on Blowfish” – this is not meant as a criticism of you/RedHat but I honestly believe that the wrong naming decision was made in terms of encouraging adoption.

In conversations with non-cryppies (i.e.: most devs) who asked me for advice on this I several times had to go chasing after them and say “No, no! not SHA256!“, when I heard them repeating [the error] to their friends; the poor kids hear SHA-2 and their brain fills in the (incorrect) rest, and they pull in a SHA-256 library and roll their own hashes… which is disastrous.

And they tell their fellow devs, which is worse.

So if you don’t care to consider changing the naming that’s your decision, and I can see why. That’s fine. I wish I had named SunMD5 something better, but I did not understand this back then.

But I care less about mildly confusing a supposedly-ignorant regulator than I do about fixing the certainly-ignorant free market and so will be doing what most of the UK pentester geeks I know are also doing, which is recommending Bcrypt() until such time as something better-and-unambiguous comes along; here in the UK the government agencies are adopting open-source tools to replace proprietary solutions, and because of this movement they are getting BCrypt because that’s the best we can provide them with in terms of (say) widespread support in WordPress/Drupal/Alfresco/Java/PHP.

UK regulatory approval of Bcrypt() will follow in the wake of that.

So that’s what I’m thinking: we need better branding. Bcrypt() and Scrypt() is on the fringes of having a good name and having bcrypt() confused with its parental Blowfish is only acceptable because it requires particularly tenacious developer ignorance to deploy a symmetric encryption algorithm as a hashing function* without realising ones’ mistake.

And I still think “bongweasel” would be an excellent hashing algorithm name.


Footnotes:

* Yes, I do know the history of DES-based Morris crypt() and realise the irony of this sentence. But the point stands.

** Bcrypt footnote from Glyn Wintle:

Just for clarity, Blowfish encryption itself is implementable faster on GPUs but only with the same key

http://researchweb.iiit.ac.in/~rishabh_m/gpu_crypto.pdf

The key setup is where the problem lies, maintain separate large S-boxs per key causes all sorts of problems.

Also for referance using john assuming that its set to 1024 iterations ($2a$10 prefix) the kind of numbers you get on a cpu are a few thousand c/s in other words in the real world at the momment with non stupid passwords, this is a very good password hash. Now as you and I know the definition of a stupid password is where the fun starts …

John currently has a GPU version, blowfish-opencl that runs on a 7970, its half the speed of the cpu code at the momment. The fact you can dial up the difficulty of bcrypt is the long term win. 🙂

On a diffrent note, Sha512 (insert correct letters here to make Alec happy) is very doable on a GPU, the biggest issue is that you have to do 64 bit maths so this slow things down a little bit because gpus are optimised for 32 bit math, so you end up haveing to do two 32 bit operations.

The solution to password guessability is this…

Extracts from three other posts:

Password Cracking in a Nutshell

The solution to guessability – even via brute force – is to get users to choose unguessable passwords; for that [see extract below].

And those passwords that they choose must most certainly be defended with the best algorithms possible on the server side to help keep them economically unguessable, hence bcrypt() or PBKDF2 implemented by security-aware developers.

I am no longer convinced that it is possible to wean people away from the method of reusable passwords, and fear that to do so may in other ways be unwise.

…I could make three password guesses per second…

There’s a pendulum that swings from structured-guessing to brute-force, and I think we’re on the return path at the moment; the complementary solution to widespread adoption of bcrypt() and PBKDF2 is to fix the user password management problem.

For me that means:

  • adoption of long pseudorandom passwords; plucking a number out of the air I go around telling people to use 16-character random mixed-case alphanumerics with punctuation, which are clearly untenable for human use especially when you…
  • change your passwords on a schedule – once a quarter, once a year, whatever the schedule it’s in case someone has picked specifically your ciphertext to break and is throwing a few thousand bucks’ worth of AWS and Hashcat at it specifically – so you need to change before their likely time-to-break is exceeded; because this is all such a pain you will need to…
  • use a decent password management tool like 1Password, PasswordSafe, whatever, so you can stop whining about how long the passwords are and how hard it is to choose and change them because most of the work is done for you; and finally you need…
  • user education and motivation. But you knew that already didn’t you?

And finally: seven basic rules for developers setting up password systems

  1. If any part of your user interface or code truncates password plaintext input at a length of less than 255 characters, it’s a bug.
  2. If you can’t cope with password plaintexts that contain SPACE and TAB characters (update: or if you impose any charset restrictions) it’s a bug.
  3. If your passwords are not hashed, it’s a bug.
  4. If you’re hashing your passwords with anything other than Bcrypt, it’s a bug; bcrypt() maxes out at 72 character passwords, but that’s not your fault…
  5. If you allow people to use a password of less than 12 characters, it’s a bug.
  6. If you do not encourage people to select a unique password for your service, it’s a bug.
  7. If you do not encourage people to use passphrases, it’s a bug.

Yes, the rules are opinionated. They are even biased and make sweeping assumptions. They don’t even address issues like UNICODE. But if you address these seven points in every application in the world, you’ll make password cracking a phenomenally tougher job.