Anatomy of a 419 Scam

A few weeks ago, I received the following scammy e-mail:

Received: from real.edu.ee ([195.250.188.110] [195.250.188.110])
Received: from localhost (unknown [127.0.0.1]) by real.edu.ee (Postfix)
Received: from real.edu.ee ([127.0.0.1]) by localhost (server [127.0.0.1])
Received: by real.edu.ee (Postfix, from userid 30)
Reply-to: peg.morrison@yahoo.dk
From: Peggy Morrison <peg.morrison@yahoo.dk>
Subject: Hello
Sender: wwwrun@real.edu.ee
To: alecm

From: Lady Peggy Morrison,
4 Old Church Street,
Chelsea, SW3, England.

Here writes Lady Peggy Morrison, suffering from cancerous ailment. I am married to Engineer Richard Morrison an Englishman who is dead. He was into private practice all his life before his death. Before his death, he deposited the sum of 20Million ( 20Mil lion Great Britain Pounds Sterling) which was derived from his vast estates and investment in capital market with his bank here in UK. I have decided to donate this fund to you and want you to use this gift which comes from my husbands effort to fund the u pkeep of widows, widowers, rphans, destitute etc. Awaits your reply.

Lady Peggy Morrison.
peg.morrison@yahoo.dk
4 Old Church Street,
Chelsea, SW3, England.

…I just love the grammar of these things (Here writes Lady Peggy Morrison, suffering from cancerous ailment, vast estates, etc) reflecting perhaps a post-colonial grammar combined with poor education, nor the badly forged headers (from Denmark via Estonia?) but the thing which caught my eye about this was the address. A 419-scam in Chelsea, dahling?

That an address was given at all was unusual, and that it cited a truncated postcode (“SW3”) to lend credibility was even more amusing — in case you don’t know, British zip/postcodes are in two parts of the form “SW3 1XX” or similar, the first part designating a large region, the latter part narrows the area to within a few houses, perhaps only a dozen. To cite a partial postcode in your own address is sloppy, ignorant or poseurish, depending on your intent.

I was due to have dinner with a friend who lives in that area, that very evening. A quick GoogleMap showed the address to be 200m from the restaurant we were dining, so after a lovely dinner at Cheyne Walk Brasserie (try the salmon tartare) – we wandered over to take a look.

Intrepid Co-investigator

intrepid co-investigator

I’d forgotten the exact address by the time we got to Old Church Street, but as soon as we saw the house I knew we’d found it…

The Address

the address

…a house out of action, under renovationwhere letters can be delivered and stockpiled by builders, perhaps innocently or perhaps in association with the scammers who will pick up the mail once a week in exchange for a small stipend, perhaps.

The Door Doorbell Extremely Out of Action

the doorway (detail)

Curiously (amusingly?) there is a security camera:-

Security Camera

camera?

…but given the state of the interior I strongly doubt that it is working and/or would be able to record anything.

Renovation Renovation

interior undecor

So that’s how it works, folks – a classic Dead Drop with amateur funding and intent to rip-off the ignorant, trusting masses. I’d speculated upon turning up with fake creds, pretending to be a tax inspector insisting Lady Peggy must submit to a tax assessment for death duties, but alas…

Oh – and walking further up the street, we worked out the reason for the truncated postcode:

Hmmm...

They couldn’t even be bothered to use the postcode finder.

Not merely scammers, but lazy gits, too.

A Demonstration Of The Importance Of Architecture And Infrastructure

*** Experiment Number 1 ***

1. Security is an essential, core enabler of online business. Security must not be an afterthought, a necessary evil, or a function forced by government regulation. It is more properly recognized as a key business enabler. The modern business paradigm of delivering highly personalized service to individual consumers demands that Security is at the core of the business process.

2. Security can provide a competitive advantage. Properly delivered Security services can enable enhanced user experience while securely protecting confidential data, thus increasing feelings of trust and customer satisfaction. Companies that leverage these factors will have a competitive edge in the online marketplace.

3. Security strategy must be tightly aligned with business strategy. As a critical enabler of business sucess, Security services must evolve in harmony with business objectives. For example, global business initiatives will demand global Security infrastructure. New business models may demand new Security services. Large business scale will require commensurate Security services scale.

4. Security should be delivered as an integrated set of web services. When Security is a core business function, services such as authentication, authorization, personal preference and federated relationships should be services accessible to every business application, whether such applications are provided by the enterprise or by its business partners.

5. Security services must be highly available with very low latency. Security services in an online environment are mission critical. Like we depend on five-nines availability for telephone dialtone and very low latency for telephone call connection, we should expect Security services to be virtually always available with mimimal impact on the duration of a business transaction.

*** Experiment Number 2 ***

1. Network Infrastructure is an essential, core enabler of online business. Network Infrastructure must not be an afterthought, a necessary evil, or a function forced by government regulation. It is more properly recognized as a key business enabler. The modern business paradigm of delivering highly personalized service to individual consumers demands that Network Infrastructure is at the core of the business process.

2. Network Infrastructure can provide a competitive advantage. Properly delivered Network Infrastructure services can enable enhanced user experience while securely protecting confidential data, thus increasing feelings of trust and customer satisfaction. Companies that leverage these factors will have a competitive edge in the online marketplace.

3. Network Infrastructure strategy must be tightly aligned with business strategy. As a critical enabler of business sucess, Network Infrastructure services must evolve in harmony with business objectives. For example, global business initiatives will demand global Network infrastructure. New business models may demand new Network Infrastructure services. Large business scale will require commensurate Network Infrastructure services scale.

4. Network Infrastructure should be delivered as an integrated set of web services. When Network Infrastructure is a core business function, services such as authentication, authorization, personal preference and federated relationships should be services accessible to every business application, whether such applications are provided by the enterprise or by its business partners.

5. Network Infrastructure services must be highly available with very low latency. Network Infrastructure services in an online environment are mission critical. Like we depend on five-nines availability for telephone dialtone and very low latency for telephone call connection, we should expect Network Infrastructure services to be virtually always available with mimimal impact on the duration of a business transaction.

*** Explanation ***

Often when I come across verbiage on the web which evangelises the importance of some whizbang new architecture, I play a game of global substitution and see how sensible (or unexciting) the underlying document becomes.

During 2005/2006 it was particularly funny to remove the word “Grid” from the text of articles on C|Net and other news resources, so that the exciting Grid Security will be critical in 2006 becomes the less-exciting Security will be critical in 2006.

Another fertile field for such word-substitution games are the reports produced by Gartner et al. Try it sometime.

The two examples above are straightforward edits of an original blog posting that is held elsewhere; if you want to know what the posting said originally then I suggest you go read it because I agree with the author wholeheartedly. I think the simple search-and-replace has worked well, especially in the first example although the latter one sounds pretty good, too – however the reason I am posting this particular example is to make a point:

Whenever you encounter a sentence like FOO is an essential, core enabler of online business, perhaps you should stop to consider what other kinds of FOO are also core enablers of online business, and whether and why you should focus upon one sort of FOO more than another sort of FOO.

Examples of the sorts of FOO that I care about, include:

  • Performance is an essential, core enabler of online business
  • Integrity is an essential, core enabler of online business
  • Operational Discipline is an essential, core enabler of online business
  • Authorisation Management is an essential, core enabler of online business
  • Backups and Disaster Recoverability is an essential, core enabler of online business
  • Networking is an essential, core enabler of online business
  • Availablilty is an essential, core enabler of online business
  • Scalability is an essential, core enabler of online business
  • Security is an essential, core enabler of online business
  • Design is an essential, core enabler of online business

Historically, within Sun Microsystems these systemic matters have been referred to by the awkward term “-Ilities”, reflecting their collective focus upon qualities, abilities or functionalities of a given solution, be it hardware, software, or whatever…

So – to return to editorialising – why is it that Sun have so much infrastructure dedicated to just one small aspect of this larger “Ilities” issue?

Perhaps it’s because we have a software product associated with it, and that product, like other products, can be sold like a hamburger – a discrete item which provides “point satisfaction” but requires little integration into a larger, quality-laden, consumption experience?

Easy AppleID Password & Account Theft

This afternoon I received an e-mail:

Subject: We’re Unable to Reset Your Apple Password
From: AppleID@apple.com
Date: Tue, 21 Nov 2006 02:55:15 +0000 (GMT)

Dear alec muffett,

We apologize but we were unable to verify your account information with the answers you provided to our security questions.

Because too many invalid attempts were made to answer these questions, you will not be able to reset your password for the next 8 hours.

If you need further assistance, please visit:

http://survey.info.apple.com/feedback/appleid.html

Thank You.

…which perplexed me mightily, because I have not touched my Apple Store account for several weeks. Therefore there is only one conclusion that could be drawn: someone is trying to hack into my Apple Store account to retreive my credit card details. It can’t be an accident, it’s not like my name is particularly common, or that many people with that name would share my birthday.

But that shouldn’t be possible, right?

Well, it turns out that it is possible.

You see, it used to be that if you wanted to change your Apple ID password, you would receive an e-mail which looked like:

(example from 2004)

Date: Wed, 21 Apr 2004 14:11:45 +0000 (GMT)
From: AppleID@apple.com
Subject: How to Reset Your Apple Password

Dear Alec Muffett,

To reset your Apple password, please click on the link below or copy and paste the address onto your web browser’s address window. Once you’re on the web page, you will be instructed to enter and confirm your new password.

https://iforgot.apple.com/cgi-bin/resetPassword.cgi?key=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ&language=US-EN

Please note that this link will expire 3 hours from the time it was sent.

If you require further assistance in resetting your password, please visit:

http://survey.info.apple.com/feedback/appleid.html

Thank you for contacting Apple.

…but no more.

It now appears that the dialogue merely requires you to answer your “security question” for password recovery, typically some pievce of trivia, which in association with your month and year of birth will be all that is necessary to retreive your credit card numbers and billing address.

The confirmatory e-mail and requirement to click on a password-change confirmation link has been rescinded, so unless your “password recovery” question is really really obscure, then knowing your birthdate someone can trivially get at your details and mess around, possibly stealing stuff off of your account and billing it to you.

I know this works, because I just tried it on myself as a proof-of-concept.

This is a dreadful situation, and I implore Apple to reinstate the extra HTTP security check at soonest opportunity.

If you have an Apple ID and you want to check how easy it is to change your password without any requirement for external authentication, go to http://store.apple.com/ and click on Sign in or create your own personal account.

Then click Did you forget your password? Click here for assistance.

A pop-up window will be created; either enter your Apple ID directly, or click on the Forgot your Apple ID? button which will accept any recent e-mail address of an Apple customer.

Then try guessing, or supply the answer to the Security Question. If you manage it, you can set a new password and Voila! you have access to your patsy’s credit card details.

Tell your friends: This sucks. Randomise the answer to your security question immediately, and store that answer in a safe place.

And complain to Apple. Hell, this is an old hack, it’s not far removed from the way Paris Hilton had her phone hacked. A company like Apple should be beyond this sort of thing, even in the name of usability.

UPDATE: For those who want to walk through the dialogue – or who for local circumstances or cookies will not be able to reproduce it – I’ve snapshotted the whole thing here; I reckon the only things which saved me from being ripped-off are that:

  • My cat is not a single colour
  • I lied about the colour anyway, and chose something different
  • I almost never save my credit details with a vendor

But I am paranoid. Lots of people are not.

Start At The Top Now Sign In Oops I Forgot My Password, Honest Guv... I Even Forgot My Login Name Option 2 Is The Fraudster's Route What's Your Birthday? Answer The Security Question If you choose unwisely...
…but if you guess right, you 0wn the user’s account.

On Argument…

I cringed when I read the following text, especially since it entangles much of with what I agree, with that fluffiness which I so much detest.

First: some stuff I agree with, randomly extracted:

http://www.stevepavlina.com/blog/2005/08/how-to-win-an-argument/

How do you handle the situation where the other person continually sucks you into an argument that you never seem to be able to win?

In a typical argument, each person tries to prove themselves right and the other person wrong.

An argument cannot be won with resistance. You will only strengthen the other person’s resolve. At best you will both leave in a state of stubbornness, but little communication will have actually occurred.

Now, let’s set it in context:

How do you handle the situation where the other person continually sucks you into an argument that you never seem to be able to win?

In a typical argument, each person tries to prove themselves right and the other person wrong. Of course, we all know what happens in the end – each person only ends up more entrenched in their views, regardless of who seems to deliver the most dominant argument.

An argument cannot be won with resistance. You will only strengthen the other person’s resolve. At best you will both leave in a state of stubbornness, but little communication will have actually occurred.

The way to “win” an argument is to aim for a goal other than being right. The other person will be prepared to defend against someone who is trying to prove themselves right. Trying to prove yourself right and the other person wrong is like making a frontal assault on an entrenched enemy position. You’ll need overwhelming force to win, and your victory will come at great cost, if you can even pull it off. Plus you’ll leave your relationship wounded in the end.

So instead of trying to be right, I’ve found that the best way to win an argument is to go for an entirely different goal. This has worked for me every time I’ve applied it, and I’ve used it dozens of times.

If you aren’t trying to win the argument, then what is your goal? I suggest you set the goal of attempting to raise the other person’s awareness while maintaining your own sense of inner peace. By this I mean that you focus on helping the other person become more aware of the full extent of their behavior and how it affects you and others, but without taking ownership of anything the other person says.

…and so forth; there’s more at [www.stevepavlina.com] which sets the wider context of the document.

Throughout the document I read an implicit teaching that any/all argument is actually a metaphor for some deeper ad-hominem conflict, or “problem”, or “issue” upon the part of the person who is raising it.

The preamble explains that it the document is written to be pertinent to family disputes – and this provides it some minor amount of slack in my eyes – but what I cringe (and downright pucker) about is that I occasionally see this same approach used by some in the business and technology world.

Perhaps some given instance of an argument might also have a personal dimension, but to teach people to invalidate the issue at debate by turning it into:

“You seem to be fairly upset about this. Why do you think that is?” or “So you’re saying you’d like to feel free to disregard my requests if you don’t agree with them. Is that correct?” or “Is this how you’d like to continue to feel about this situation?” or “Do you feel your behavior towards me is honorable and respectful?”

…is tragic, is shortsighted, teaches cowardice, lacks integrity, and demonstrates unfitness to lead.

Therefore, as you might expect, it’s a popular defence tactic amongst politicians.

I’ve seen much of this tactic in business, and although it has been explained to me time and time again that with some people you just need to swing them around to your argument gently” – when encountered it still sticks in my craw.

As an American Nobel Laureate put it:

Every day I would study and read, study and read. It was a very hectic time. But I had some luck. All the big shots except for Hans Bethe happened to be away at the time, and what Bethe needed was someone to talk to, to push his ideas against. Well, he comes in to this little squirt in an office and starts to argue, explaining his idea. I say, “No, no, you’re crazy. It’ll go like this.” And he says, “Just a moment,” and explains how he’s not crazy, I’m crazy. And we keep on going like this. You see, when I hear about physics, I just think about physics, and I don’t know who I’m talking to, so I say dopey things like “no, no, you’re wrong,” or “you’re crazy.” But it turned out that’s exactly what he needed. I got a notch up on account of that, and I ended up as a group leader under Bethe with four guys under me.

…it is possible for people to debate and discuss, to call each other “wrong”, and to change their minds when evidence and discussion suggests to do so, without it being a reflection of an ad-hominem attack.

To be called “wrong” is not a personal slight – it’s a challenge, and an exciting one at that, so long as you have the strength of character to admit it when you are demonstrably wrong.

So, to answer the author’s first question:

“How do you handle the situation where the other person continually sucks you into an argument that you never seem to be able to win?”

  1. Consider the possibility that maybe you are wrong, and weigh the evidence that supports that proposition.
  2. Consider the possibility that your opponent is uninformed (soluble), ignorant (fixable), set in their ways (harder), stupid (er), or just plain nuts.
  3. Continually keep your mind open to both of these possibilities.

As for the application to family disputes? Not in my family. It wouldn’t work.

OpenSolaris, Pluggable Crypt, and the SunMD5 Password Hash Algorithm

Several years ago now, Darren Moffat, Casper Dik and I started swapping e-mail about how pathetic it was to still be using the traditional 8-character-password unix crypt() routine in Solaris, and how we could architect something to be much better.

The result was the Solaris Pluggable Crypt Framework, as was announced:

  1. A project exists within Solaris engineering, to integrate a pluggable crypt() routine into Solaris, which will allow use of arbitrary password-hashing algorithms, of arbitrary lengths, etc, in Solaris.

  2. Interoperability with Linux/*BSD MD5- and Blowfish-based hash algorithms is a goal of the project

  3. If I remember right – and I may well be incorrect, as I am not responsible for this aspect of the project – the release is scheduled for Solaris9.

    I am consulting with the team/doing development work with them, on account of my (erm) extensive experience with crypt() implementations…

  4. PAM was considered as a solution for this, and it was decided to not be the appropriate vehicle for delivery of an alternative crypt() routine, because (in summary) PAM is essentially an API for user-interfaces (/bin/login, ftpd, etc) – as opposed to an API for interfacing to the directory-services within which the password entries reside; consider “getpwent()” and family.

Pluggable Crypt was rolled-out in Solaris 9 (Update 2, if my memory is correct?) and we were quietly pleased that our users suddenly reported being able to transparently use a mixture of Traditional, Linux-MD5 and Blowfish hash algorithms. GNU Autoconfig (aka: "./configure") spotted it immediately, next time Darren built Apache. All was cool.

Incidentally, we didn’t get any awards or anything, but that’s management for you. It was a nice example of co-operation inside the company because I was at that point actually working for Sun Professional Services, and not really an engineer.

The hook which permitted us to implement “Pluggable Crypt” was the presence of a dollar-sign (‘$’) as a field separator in the latter two kinds of hashes. We took that as a style cue, and designed the new crypt() shim so that lack of a ‘$’ prefix causes a fall-through to the “traditional” algorithm.

After several weeks of considerable argument (three extremely opinionated and notoriously frank security programmers designing a API, it must have been funny to watch from a distance behind smoked glass) we decided that for a given ciphertext:

$foo$bar$wibblebongthud

…that “foo” – the token being terminated by a dollar or comma – would be used to look up and load a shared library in crypt.conf(4), and that the latter would be at liberty to re-interpret the ciphertext as it willed.

We argued over the design using the following two ciphertexts as examples of desirable syntax:

$caesar$shift=13$frfnzr

$rot13$frfnzr

…which are essentially the same algorithm and might possibly be implemented by the same shared library, but which would have different output syntaxes. The mechanism we created could permit this.

Provided with this wonderful power I mused what I could do in order to highlight the new features it provided, and so we came up with the SunMD5 Hash Algorithm that would be written exclusively with the purpose of annoying people who write brute-force or dictionary-based password guessing engines.

In short: for annoying people like me.

After some beer consideration of the problem, I concluded that password-cracker writers:

  • really hate hash-algorithms which allow large, near-infinite, clash-free numbers of salts.

  • really hate hash-algorithms with large, variable, possibly near-infinite round-counts.

  • really hate hash-algorithms which make precomputation/table-lookup impractical.

…and I further reasoned that:

  • writing a wholly new hash algorithm would be a really really unutterably silly thing to do, but…

  • aha! pumping vast and variable quantities of information through an existing hash algorithm would be reasonably computationally expensive, and the process may be tweakable to make it demonstrate the above desired qualities.

So, after some more beer coffee considerable thought, I hit upon the following process:

  1. choose a PLAINTEXT, and a SALTSTRING

  2. push PLAINTEXTSALTSTRING through MD5, generating HASH0; let n=0

  3. condense HASHn into a single BIT, using MuffettCoinTossAlgorithm

  4. where “NNN” is a decimal ASCII representation of “n”; and where “HAMLET” is the complete 1517 bytes of “To Be Or Not To Be” soliloquy (Hamlet act 3 scene 2, copyright-free source) …

  5. if BIT=0, push HASHnNNN through MD5 generating HASH(n+1)

  6. if BIT=1, push HASHnHAMLETNNN through MD5 generating HASH(n+1)

  7. let n=n+1

  8. repeat steps 3 thru 7 for (4096+X) iterations, where X is an arbitrary positive integer 32-bit number specified in the input salt/ciphertext/metainformation.

  9. result:

    $md5$rounds=X$SALTSTRING$HASHfinal

    – using base64 encoding where needed to encode binary data.

That’s a quick rundown and I think it’s approximately correct. I’ve not been drinking coffee this week so I may be a little off in the fine details, so check the source if you want verification. In terms of the blame we all argued the overall design, I did the SunMD5 algorithm, Darren the glue and Casper and Darren both the larger shared library interfaces, docs, integration and so forth.

The only blackbox in the above is MuffettCoinTossAlgorithm which I truly cannot be arsed to explain (or, more pointedly, why should I grep my mailbox archives for the design docs when you can read the source and figure it out for yourself?) – but the essence was to create something which was somewhat a function of the roundcount (strictly, there are 128 different ways it can go, since it’s f(roundcount modulo hashbits)) and which self-referentially recombines bits of the previous round’s hash both as dynamic-lookup-table and as data-looked-up, eventually extracting two bits from the hash, which then get XOR’ed to create a truth value. It was designed with painful memories of trying to speed-optimise DES S-boxes, plus a few hints of “let’s try to align a few fetches unevenly bridging word boundaries, in case someone tries to inline it with longword fetches.”.

You could try speculative computation, but then you’re a masochist.

Hmmm.

<DIG TYPE=’amusing’> Aside: Reviewing the code nowadays, I’m sure it read a lot more clearly before Darren put it through cstyle. </DIG>

The benefits of the SunMD5 design:

  1. The saltstrings are of near-arbitrary length and can contain all sorts of stuff, including (for instance) the username as a substring, which could thereby guarantee the uniqueness of a salt within a given environment.

  2. The roundcount can be enormous; 1 round = (1517 * 50%) + 8 + 4 = 770 bytes pushed through MD5, so setting “rounds=904” (making 904 + 4096 builtin = 5000 rounds total) pushes 3.8Mb of data through MD5. If you want it to take longer, set “rounds=68000” and pump 50Mb through it instead.

As ever, much of the power of an algorithm is not merely how it works, but also in how you use it. The above should supply you with some idea of how it’s meant to be used. In terms of the actual implementation, there’s a feature which I don’t like and for which there is a RFE somewhere; it’s demonstrated by the following code:



#!/bin/perl
# sunmd5.pl – test the sunmd5 implementation on solaris9u2 or above
# roundcount: 904 (user specified) + 4096 (builtin) = 5000 rounds total
# syntax examples
$exsalt1 = ‘$md5$rounds=904$saltstring$dummy’;
# this one is strictly correct
$exsalt2 = ‘$md5$rounds=904$saltstring$’;
# this one ought to be the same
$exsalt3 = ‘$md5$rounds=904$saltstring’;
# as should this one
# test plaintexts
@words = qw( sesame abcdefgh abcdefghijklmnop );
foreach $word (@words) {
$ct1 = crypt($word, $exsalt1);
$ct2 = crypt($word, $ct1);
printf “with exsalt1: %-20s => %s\n”, $word, $ct1;
printf “sanity check: %-20s => %s\n”, $word, $ct2;
printf “with exsalt2: %-20s => %s\n”, “”, crypt($word, $exsalt2);
printf “with exsalt3: %-20s => %s\n”, “”, crypt($word, $exsalt3);
print “\n”;
}
exit 0;

Basically: in order to produce correct outputs, the current parser for SunMD5 algorithm requires a dummy (or real!) ciphertext at the end of the salt-input; this is not a problem in operational usage since /bin/passwd and the other user-admin tools are meant to do the right thing, however it’s not really a nice user experience for Joe Shmoe who’s hacking around in perl as above.

So: when the examples with exsalt2/exsalt3 show the same output as the preceding, then it means that my RFE’s gone through and the patch has been installed. Until then, be aware.

All this has been written in response to a bunch of questions from David Magda, who (over over the course of several e-mails) posed the following questions, the answers to which I shall use to wrap-up this posting:

  • What advantages does the SunMD5-based algorithm have over the BSD one?

    See the above; the algorithm is meant to demonstrate interesting features, innovative ideas in password hashing / what constitutes a ciphertext, and to highlight the Pluggable-Crypt framework which is now (of course) published as part of OpenSolaris.

    Also: it exposes more programmers to Shakespeare, which has got to be a good thing.

  • With the recent attacks on MD5 (and SHA-1), is there any thought to moving to the Blowfish-based hash as a default, or is MD5 still “good enough” for this purpose?

    I reckon that given our modus operandi it’s more than good enough, but for interest’s sake Darren and I have long been planning an uprated version and we’re considering SHA-512 as the underlying hash algorithm.

  • Why another hash?

    “Because People Always Want The Latest iPod” 😎

    Plus, well, why not? Why can’t we live in a world with a dozen different hash algorithms and support the lot of them? Pluggable Crypt is a really good idea:

    WarStory: I gather that there is at least one site where old Ultrix / OpenVMS / OSF-1 ciphertexts have been imported into a Solaris environment by installing a suitable Pluggable-Crypt module, then prefixing the ciphertexts with $bc$ (bigcrypt) or $c16$ (crypt16) and performing migration from these old, weak algorithms by immediately deprecating $bc/$c16 by using the controls in policy.conf(4).

    Insanely neat, huh?

    Further: it allows the spooks to use their own password hashes. They really like that sort of thing. Makes them feel safe.

  • Given that the Blowfish-based one is extendable by increasing the rounds, why not use it?

    Because I thought it insufficiently evil, and evidently the progeny of a cryppie, rather than a cracker-programmer, mindset. 😎

Solais manpages you need to read: passwd(1), crypt(3C), crypt.conf(4), crypt_genhash_impl(3C), crypt_gensalt(3C), crypt_gensalt_impl(3C), getpassphrase(3C), passwd(4), crypt_unix(5)

Manpage browser at [docs.sun.com]

UK National Loyalty Card

Robin Wilton – mate of mine, sound geezer – is writing extensively about matters of Identity Cards, a topic about which he knows a great deal from his past and current occupations inside Sun Microsystems.

He writes:

[blogs.sun.com]

I am trying to get a handle on what affects citizen uptake and usage of Identity Cards, bearing in mind that this country (UK) has only minimal collective memory of such a thing.

As far as I can see, the most likely factors (more or less in ascending order of optimism) are:

  1. Legal compulsion: (you will get nicked if caught not carrying it)
  2. Direct benefit: (convenience, risk avoidance, incentive)
  3. Citizen Culture: “The Greater Good”, or “We ve always had one”
  4. Fashion: OK OK, I did say optimistic, but just imagine: “ID Cards the new iPod” ;^)

Now me: I think that Governments and the Police are really missing a point.

They are missing one big trick that would instantly garner acceptance of an Identity Card.

One big example.

Supermarket Loyalty Cards.

I am not joking; hear me out.

I have several friends who are in the Police, and godluvem they’re absolutely wonderful, generous, trusting people, but it wasn’t until I became familiar with how they talked about work in their off-hours that I actually learned what is meant by the term institutional mind-set. They make jokes about The Ways And Means Act – as in: “we have ways and means to deal with people who deserve being nicked” – and thus gave rise to my perception that the Police sometimes (often?) see people as generally falling into one of three camps:

  1. friends, to be socialised with
  2. bent, to be nicked
  3. innocent, to be patted on the head but otherwise watched in case they turn out to be secretly bent

These friends of mine were rather appalled to hear me once ask: What’s the point of being good?

By saying this I was not trying to endorse criminality, but rather follow a line of thought that: once you get rid of the whole religious/morals/ethics thing and dispense with the notion of God – some great big finger, wagging at you for being naughty – then the next thing you question is the judiciary and/or any other arbitrary authority, especially one that talks about “ways and means”. (ahem)

So you start thinking: at least with the whole religion mythos, there is a stick (“burn in hell, nasty pointy things, brimstone”) and also there is a carrot (heaven, sherbert, self-starting virgins, etc…)

With society and government however, there is only the stick; other than your continued liberty – which frankly most people take as a given, or don’t seem to much care about given the way they are happy to fritter away aspects of it in the name of “Homeland Security” – you otherwise get nothing for paying your taxes on time, obeying the speedlimit, not shooting pheasants out-of-season or fishing without a license.

In short: Cui bono? Aside from making a personal moral choice to be largely law-abiding, what is the point in being so?

On that basis, with this gap in the market, a UK National Loyalty Card is a stonkingly fantastic idea!

Think of the possibilities: You could accrue Citizenship Points for snitching on benefit cheats and badly-parked vehicles, teaching immigrants how to talk proper like, y’know, or organising community-minded projects like wheel-clamping or neighbourhood-watch schemes. The sort of complex projects that would otherwise require a middle-class neighbourhood with a high percentage of social-climbers, to achieve.

These Citizenship Points could then be redeemed for positive benefits: being let-off the occasional speeding ticket, a minor discount on taxes, automatic granting of planning-permission for small household extensions – or, at the extreme end, honours, peerages, and a lunch at Buckingham Palace with the Home Secretary of the day.

Just imagine how much “good” would be done by people in pursuit of points that would actively let them do things they do already anyway, if mildly illegally. The mere snob-value would drive enormous effort.

In fact, the only people likely to be against it would be the Police, if you think about it. For starters there would be fewer people to arrest.

Fewer ways and means.

Crypticide I: Thirteen Years of Crack

Thirteen years ago, on 15th June 1991, I posted v2.7a of Crack to the newsgroup alt.sources [groups.google.com] – I messed-up the posting process a bit, since these were the days when people cared about netiquette, the Web was multicast and named USENET, and also this was perhaps the first time I was releasing software to a wide and critical audience.

It became a very popular piece of software indeed.

Crack began as a homebrew refinement of the “pwc” password-checking software that people could find included in Dan Farmer’s COPS package [groups.google.com] – but my copy of which was the COPS cracker’s ancestor, some much older code that was circulating amongst the UK’s Unix/CompSci community in the mid/late 1980s.

The concept of a program like Crack goes back many many years (see [groups.google.com] [groups.google.com] [groups.google.com] for some discussion, and see also earlier papers by Morris and Thompson) and the basic method of password cracking is easily described to any layman who can follow a recipe:

  1. for each word in a dictionary listing of words
  2. … see whether anyone is using that word (eg: “sesame”) as a password
  3. … see whether anyone is using obvious variants of that word as a password (eg: “sesame1”, “2sesame”, “ses3ame”, “sesame69”, “s3sam3”, “SESAME”, …)
  4. … and move on to the next word, and repeat.

In fact the concept is so utterly simple that it can be expressed in less than a single line of the Perl programming language:

World’s smallest password cracker?

echo SESAME | perl -nle ‘setpwent;crypt($_,$c)eq$c&&print”$u=$_”while($u,$c)=getpwent’

…but before delving into technological issues any further, a little history is appropriate.

In the autumn of 1990 I began messing-about with the “pwc” source; as a programmer I found the original memory-management / wordlist-handling code rather ugly (not to mention: barely comprehensible) but in rewriting that I found the resultant tool to be suddenly much more effective at guessing passwords.

I suspect that I inadvertently fixed some string-handling bug in the original code; in any case, I now had a tool that was efficient, useful, and interesting to play with, in my role as systems programmer at a Welsh university.

Versions 2.0 and upwards of Crack were total rewrites for clarity and extensibility, plus wrapper scripts and other oddments to perform housekeeping.

Version 2.7a was the first public release to USENET, and barely a few weeks later, after discussion and issuing public notice [groups.google.com] [groups.google.com] I posted v3.2a of Crack [groups.google.com] which contained a faster version of the Unix password hashing algorithm, one spawned from Bob Baldwin’s code which I’d further tuned/rewritten to get an extra 40..50% performance boost.

That was the day everything changed for me.

On mundane machines like Sun’s 3/60 Workstation, you could now check thirty-five passwords per second, as opposed to the three per second permitted by the slow “libc” implementation of crypt(). After a little math:

35 * 60 * 60 * 24 * 2 = 6,048,000

…that’s about 6 million password-checks that you could make, per weekend, per CPU. Multiply that by the twenty or so workstations in the student laboratory, and you could do some serious checking of password security:

6048000 * 20 == 120,960,000

Almost one hundred and twenty-one million password guesses in a weekend. That – in 1991 – was an astounding amount. If you had (say) 50 users in your password file, that was 2.4 million guesses apiece, each guess to see if someone had used dictionary word, or a StarTrek character name, or the name of a chemical compound, or a girl- (and boy-) friends’ name (etc) as their password.

That was a lot of guesses.

As an aside: on a modern PC the same can be achieved on a single CPU, taking between 5 and 20 minutes to complete.

There was some dissent about the software, however there was much much more support, [groups.google.com] both of which seemed odd given that both the technique and technology were so old. To my mind the truth is that up until the next version (4.0a) [groups.google.com] there was actually very little in Crack that had not been in one or other previous password-cracking program.

The 4.x series of Crack (3 Nov 1991 onwards) introduced first the programmable dictionary generator so that people could “get creative” with their guessing; it also introduced networking, so that you could automatically distribute the embarrassingly-parallel load of your password cracking amongst dozens, perhaps scores of machines.

In this era, this was really cool; remember that this predated any of distributed.net, the RC5 project, SETI@Home, Genome@Home, Folding@Home, peer-to-peer or the like; to be able to draw-together the resources of an entire university to address a single, linearly-scalable compute problem was quite enlightening for some computer scientists.

Bizzarely (to modern ears) I was essentially forbidden from referring to this innovation as “parallel computation” – a term which meant something quite different to purist British ears in that era; terms like distributed or grid computing were unknown to me at the time, or possibly did not exist outside of CompSci hothouses – or even at all?

Interest in Crack and password-cracking mushroomed; people wrote Bachelors’, Masters’ and even one Doctorate thesis about it. Sysadmins were lauded for running it. Students were reprimanded or expelled for running it. Imitations sprang up. People of every motive posted better, faster, geekier, more tuned versions of the crypt() routine for particular architectures. Some messed around with their benchmarks to suit their egos [groups.google.com] – and some have subsequently gone on to build excellent professional reputations on the back of such work.

Not all of them have yet bought me beer, but some have done. That, plus reputation and all that that brings, is the profit that I have reaped from this early exercise in Open Source Software distribution.

Eventually matters calmed down; a few years later the WWW/Web was invented, Perl5 was released, Dan Farmer and Wietse Venema released SATAN and all the Crack-style hyperbole and flamage was once-again repeated, as indeed Crack’s release expanded upon that which greeted the release of COPS.

Now that there are scores of potentially dual-use (ie: cracker/admin) tools available to the general public, the flamage seems to have died down except where truly media-friendly scary hax0r-nerds are involved.

So: thirteen years ago. Thirteen years ago, today. Aside from nostalgia, why bring all this up, now?

Because I want that password algorithm – the traditional, 8-character Unix password-hashing algorithm – dead.

Watch this space for updates.

[Project RSS] [www.crypticide.com]