One of my worst ever projects was implementing PGP email encryption. Considering I have only worked in large financial services companies, that is saying something. I have reflected on the lessons learnt from this project before, but I felt that PGP was fundamentally flawed. When Apple iOS 5 was unveiled, there was a small feature that no one talked about. It was hidden among the sparkling jewels of notifications, free messaging and just works synchronization. That feature was S/MIME email encryption support. Now S/MIME is not new, however Apple is uniquely positioned with their ecosystem and user-centric design to solve the fundamental problems and bring secure email to the masses.

I have detailed the problems that email encryption solves, and those it does not solve before. To re-iterate and update:

• Attacker eavesdropping or modifying an email in transit. both on public networks such the Internet and unprotected wireless networks as well as private internal networks. Recently I have experienced things that have hammered home the reality of this threat: Heartfelt presentations at security conferences such as Uncon about the difficulties faced by those in oppressive regimes such as Iran, where the government reading your email could result in death or worse for you and your family. Even “liberal” governments such as the US blatantly ignoring the law to perform mass domestic wire tapping in the name of freedom. The right to privacy is a human right. Most critical communication these days is electronic. There is a clear problem to be solved in keeping this communication only to it’s intended participants.

• Attacker reading or modifying emails in storage. The recent attacks on high profile targets such as Sony and low profile like MTGox, who were brought low by simple exploitation of unpatched systems and SQL injection vulnerabilities, have revealed an un-intended consequence. The email addresses and passwords published were often enough to allow attackers access to a users email account as the passwords were re-used. I don’t know about you but these days a lot of my most important information is stored in my gmail account. The awesome search capability, high storage capacity and accessibility everywhere means that it is a natural candidate for scanned documents and notes as well as the traditional highly personal and private communications. There is a problem to be solved of adding a layered defence; an additional wall in your castle if the front gate is breached.

• Attacker is able to send emails impersonating you. It is amazing how much email is trusted today as being actually from the stated sender. In reality normal email provides very little non-repudiation. This means, it is trivial to send an email that appears to come from someone else. This is a major reason why phishing and spear phishing in particular are still so successful. Now spam blockers, especially good ones like Postini have become very good at examining email headers, verified sender domains, MX records etc to reject fraudulent emails (which is effective unless of course you are an RSA employee and dig it out of your quarantine). You can also have more localised proof of concept of this. If your work accepts manager e-mail approvals for things like pay rises and software access, and it also has open SMTP relays you can have some fun by Googling SMTP telnet commands. There is a problem to solve in how to reliably verify the sender of the email and ensure the contents have not been tampered with.

Problems not solved by email encryption and signing:

• Sending the wrong contents to the right person (s)
• Sending the right contents to the wrong person (s)
• Sending the wrong contents to the wrong person (s)

These are important to keep in mind because you need to choose the right tool for the job. Email encryption is not a panacea for all email mis-use cases.

So having established that there is a need for email encryption and signing, what are the fundemental problems with a market leading technology like PGP (now owned by Symantec)?

Fundemental problems in summary:

• Key exchange. Bob Greenpeace wants to send an email to Alice Activist for the first time. He is worried about Evil Government and Greedy OilCorp reading it and killing them both. Bob needs Alice’s public key to be able to encrypt the document. If Bob and Alice both worked at the same company and had PGP universal configured correctly, or worked in organisations that both had PGP universal servers exposed externally, or had the foresight to publish their public keys to the public PGP global key server, all would be well. However this is rarely the case. Also email is a conversation. Alice not only wants to reply but also add in Karl Boatdriver in planning the operation. Now suddenly all three need his public keys and he theirs. Bob, Alice and Karl are all experts in their field but not technical and have no idea how to export and send their public keys and install these keys before sending secure email. They have an operation to plan for Thursday!

• Working transparently and reliably everywhere. Bob is also running Outlook on his Windows phone 7 (chuckles), Alice Pegasus on Ubuntu and Karl Gmail via Safari on his iPad. Email encryption, decryption, signing, signature verification, key exchange all need to just work on all of these and more. It also cannot be like PGP desktop which uses a dirty hack to hook into a rich email client. This gives it extremely good reliability and performance. Intermittent issues like emails going missing and blank emails never occur. Calls to PGP support for any enterprise installation are few and far between. All users in companies love PGP and barely notice it is there. In many organisations email is the highest tier application. It has to have three nines uptime. If Alice and Karl are about to be captured by Greedy Oilcorp and they need to get an email to Bob they cannot afford to get a message blocked by PGP error.

Less fundamental but still annoying:

• Adding storage encryption – there is no simple way with PGP to encrypt a clear text email in storage. You can send it to yourself again or export it to a file system and encrypt it there but that is it. This is a problem in where the email is not sensitive enough to encrypt in transit (or just where you just forgot) but where after the fact, you do care if script kiddies with your email password get that email and publish it on Pastebin.

How Apple could solve these fundamental problems with iOS 5

Key exchange – If you read marknca‘s excellent iOS security guide, you will see that Apple has effectively built a Public Key Infrastructure (PKI). Cryptographically signing things like apps and checking this signature before allowing them to run is key to their security model. This could be extended to users to provide email encryption and specifically transparent key exchange in the following manner:

• Each user with an Apple ID would have a public/private key pair automatically generated
• The public keys would be stored on the Apple servers and available via API and on the web to anyone
• The private keys would be encrypted to the the users Apple account passphrase and be synchronised via iCloud to all iOS and Mac endpoints
• To send a secure email the user would just click a secure button on their email tool
• When sending an email via an iOS device, a Mac or via Mobile me web it would query the Apple servers for the recipients private key and encrypt and sign (optional) the email
• On receipt as long as the device had been unlocked the email would be decrypted. For web access as long as the certificate was stored in the browser the email would be decrypted (could be an addon to Safari)
• To encrypt an email in storage you would just drag it to a folder called private email. You could write rules for what emails were automatically stored there.

This system would make key exchange, email encryption, decryption and signing totally transparent. Because S/MIME uses certificates it is easy to get the works everywhere property. However Apple would first enable this only for .me addresses and iOS devices and Mac’s to enable them to sell more of these and to beef up their enterprise cred. Smart hackers and addon writers would soon make it work everywhere though. There you go, secure email for the masses.

This week in Las Vegas is Christmas for security. In listening to four BSidesLV talks today, I’ve come to conclude that the community suffers from a real lack of discussion about interacting with management, mandatory access controls need to be enhanced to focus on applications, the SSL system is irreparably broken and DNSSEC really should replace it, and some potential laws related to hacking may be harbingers of a 100 year security dark age.

That’s a loaded paragraph, so here’s the breakdown: Adam Ely’s talk “Exploiting Management for Fun and Profit – or – Management is not Stupid, You Are” made a fantastic point about budgeting for security. Getting better security isn’t about convincing executives that they need better security. Better security is about understanding what the corporate goals are and fitting the application to that model. Consider an executive’s primary goal of a hospital: increase the survival rate of emergency room patients. How can your goals for security further that goal?

Val Smith’s “Are There Still Wolves Among Us” expressed research showing a very skilled black hat community that has a quiet history of program modification at vendors, years-old 0-day exploits and wholesale compromise of security researchers. The summary point is that “cyber warfare” and “government-level” threats may come from non-government hackers, and they’re the quiet ones. LulzSec, Anonymous and the like are providing covering noise for the ones who don’t get caught. It is further a possibility that attacks that appear to be from foreign countries may be intentional proxying by talented hackers

“A Study of What Breaks SSL” by Ivan Ristic conveyed that the majority of servers are misconfigured somehow. Acceptance of data and sometimes the presentation of login forms in unencrypted pages, broken certificate chains, and servers still offering up SSLv2 in abundance. I’ve personally come to believe that the purpose of SSL — provide assurance that an encryption key belongs to the registered domain of the certificate — has been supplanted by the implementation of DNSSEC. As DNSSEC provides for a similar signature chain and distribution of keys, it ought to be used as the in-channel distribution method. Further to that, the bolt-on nature of SSL permits numerous attacks and misconfiguration possibilities that can prevent even negotiating SSL with a client. Those thoughts may be worthy of their own paper

Finally, Schuyler Towne’s “Vulnerability Research Circa 1851” was a great look at the security culture of physical locks. It showed the evolution of lock security as it moved toward a system where knowing the mechanical construction of a lock didn’t prevent it from being secure. More importantly, it showed a 100 year drought of lock security filled with closed and legally enforced locksmith guilds, laws against lockpicking and the stalling of progress in adopted residential security locks — namely that most American household locks are using 100 year old technology. It emphasized the potential disaster that adoption of laws such as Germany’s 202© “anti-hacking tools” law could present the security industry with. Just as the golden age of lock development was spurred on with constant public challenges over lock security and then followed up with a century-long dark age here laws and culture prevented research that would advance security .

The first day of BSides has drawn to a close, the 2nd day is opening. The lines for badges at DEFCON are some kind of absurd, and the week is just warming up. DEFCON organizers (“Goons”) are expecting 12,000 attendees. Why they have only pressed 9200 attendee badges is a notable question given the badge shortages of previous years, though. Security companies are actively and openly conference recruiting attendees from BSides, and I expect more of the same at DEFCON.

Today we investigate the problem of disposing of hardware storage devices (say, hard disks) which may contain sensitive data. The question which prompted this discussion “Is it enough to only wipe a flash drive once” is about Flash disks (SSD) and received some very good answers; here, we will try to look at the wider picture.

Confidentiality Issues and How to Avoid Them

Storage devices grow old; at some point we want to get rid of them, either because they broke down and need to be replaced, or because they became too small with regards to what we want to do with them. A storage device does not shrink over time, but our needs increase. Quite some time ago, I was sharing some disk space with about one hundred co-students, and the disk offered a hefty 120 megabytes. At that time, a colorful GIF picture was considered to be the top of technology. Today, we take for granted that we can store 2-hour long HD videos on a cellphone. The increase in disk space shows no sign of slowing down, so we have a steady stream of old disks (or USB sticks or SD cards or even ZIP/Jaz cartridges for the old timers — I will not delve into floppy disks) to dispose of. The problem is that all these pieces of hardware have been used quite liberally to store data, possibly confidential data. For the home user, think about the browser cookies, the saved passwords, the cryptographic private keys… In a business context, just about any data element could be of value for competitors.

This is a matter of confidentiality. There are two generic ways to deal with it: encryption, and destruction.

Disk Encryption

Disk encryption is about transforming data in a way which is reversible only with the knowledge of a given secret short-sized element called a key. We are talking about symmetric encryption here; the key is a simple sequence of, say, 128 bits chosen at random. The confidentiality issue is not totally obliterated, only severely reduced: supposedly, it is easier to deal with the secrecy of a sequence of 128 bits than that of 100 GB worth of data. Encryption can be done either by the disk itself, by the operating system, or by the application.

Application-based encryption is limited to what the application can control. For instance, it may have to fight a bit with the OS about virtual memory (that’s pure memory from the point of view of the application, but the OS is prone to write it to the disk anyway). Also, most applications do not have any encryption feature, and modifying all of them is out of the question (not even counting the closed-source ones, that’s just too much work).

OS disk encryption is more thorough, since it can be applied on the complete disk for all files from all applications. It has a few drawbacks, though:

• The computer must still be able to boot up; in particular, to read from the disk the code which is used to decrypt data. So there must be at least an unencrypted area on the disk. This can cause some system administration headaches.
• Performance may suffer, for an internal hard disk. An x86 Core2 CPU at 2.4 GHz can encrypt about 160 MB/s with AES (that’s what my PC does with the well-known OpenSSL crypto library): not only do some SSD go faster than that, I also have other things to do with my CPU (my OS is multitasking).
• For external media (USB sticks, Flash cards…), there can be interoperability issues. There is no well-established standard on disk encryption. You could transport some appropriate software on the media itself but most places will not let you install applications as easily.

Encryption on the hardware itself is easier, but you do not really know if the drive does it properly. Also, the drive must keep the key in some way, and you want it to “forget” that key when the media is decommissioned. As Jesper’s answer describes, good encrypted disks keep the key in NVRAM (i.e. RAM with a battery) and can be instructed to forget the key, but this can prove difficult if the disk is broken: if it does not respond to commands anymore, you cannot really be sure that the NVRAM got blanked.

So while encryption is the theoretically appropriate way to go, it is not complete (you still have to manage the confidentiality of the key) and, in practice, it is not easy. Most of all, it works only if it is applied from day one: encryption can do nothing about data which was written before encryption was envisioned at all. So let’s see what can be done to destroy data.

Data Wiping

Wiping out data is a popular method; but popular does not necessarily mean efficient. The traditional wiping patterns rely on the idea that each data bit will be written exactly over the bit which was at the same logical emplacement on the disk: this was mostly true in 1996, but technology has evolved. Today’s hard disks do not have “track railings” to guide the read/write heads; instead, they use the data itself as guide. The net result is that the new data may be physically off the previous one by a small bit; the old data is still readable “on the edge”.

Also, modern hard disks do not have visibly bad sectors. Bad sectors still exist, but the disk transparently substitutes good sectors instead of bad sectors. This happens dynamically: when a disk writes some data on a sector and detects that the write operation did not go well, then it will allocate a new good sector from its spare area and do the write again there. From the point of view of the operating system, this is invisible; the only consequence is that the write took a few more milliseconds than could have been expected. However, the data has been written to the bad sector (admittedly, one or two bits of it may be wrong, but this leaves more than 4000 genuine bits) and since the sector is now marked as “bad”, it is forever inaccessible from the host computer. No amount of wiping can do anything about that.

On Flash, the same issue arises, multiplied a thousand times. Flash memory works by “blocks” (a few dozen kilobytes) in which two operations can be done:

• changing a bit from value 1 to value 0;
• erasing a whole block: all the bit blocks are set to 1.

A given block will endure only that many “erase” operations, so Flash devices use wear leveling techniques, in which write operations are scattered all about the place. The “Flash Translation Layer” is a standard wear leveling algorithm, designed to operate smoothly with a FAT filesystem. The wear leveling means that if you try to overwrite a file, the wiping pattern will be most of the time written elsewhere. Moreover, some blocks can be declared as “bad” and remapped to spare blocks, in a way similar to what magnetic hard disks do (only more often). So some data blocks just linger, forever unreachable from any software wiping.

The basic conclusion is that wiping does not work against a determined attacker. Simply overwriting the whole partition with zeros is enough to deter an attacker who will simply plug the disk in a computer: logically, a single write is enough to “remove” the data, and by working on the partition instead of files, you avoid any filesystem shenanigans. But if your enemies are so cheap that they will limit themselves to the logical layer, then you are lucky indeed.

@nealmcb’s question, How can I reliably erase all information on a hard drive? sparked some excellent discussion including NIST’s guidelines for Media Sanitisation.

Media Destruction

Without encryption (does not work for data which is already there) and data wiping (does not work reliably, or at all), the remaining solution is physical destruction. It is not that easy, though; a good sledgehammer swing, for instance, though satisfying, is not very effective towards data destruction. After all, this is a hard disk. To destroy its contents, you have to remove the cover (there are often many screws, some of which hidden, and glue, and rivets in some models) and then extract the platters, which are quite rigid disks. A simple office shredder will choke on those (although they would easily munch through older floppy disks). The magnetic layer is not thick, so mechanical abrasion may do the trick: use a sander or a grinder. Otherwise, dipping the platters in concentrated sulfuric acid should work.

For Flash devices, things are simpler: that’s mostly silicon with small bits of copper or aluminium, and a plastic cover. Just burn it.

Bottom-line: media destruction requires resources. In a business environment, this could be a system administrator task, but it will involve extra manpower, safety issues (seriously, a geeky system administrator with access to an acid cauldron or a furnace, isn’t it a bit scary ?) and possibly environmental considerations.

Conclusion

Data security must be thought throughout the complete life cycle of storage devices. Whether you go crypto or physical, you must put some thought and resources into it. Most people will simply store old disks and hope for the problem to get away on its own accord.

Last week, we looked at the hardening tag. Today we are going back on a specific question : Does an established SSL connection mean a line is really secure?

Why did we pick up this question? Because almost everyone has heard of SSL, but many are not sure how it works and what it is used for.

Well, the first thing we need to talk about is history of the protocol.

Secure Sockets Layer

The Secure Sockets Layer (SSL) is a cryptographic protocol – now renamed to  Transport Layer Security (or TLS). This protocol is designed to create eavesdropping-proof and tampering-proof communication over the Internet and other untrusted networks.

Originally developed by Netscape, the protocol came out in 1995 with its 2.0 version (1.0 was never publicly released). But SSL 2.0 came with some serious security flaws, which included a Man in the Middle vulnerability, which could allow an attacker to sit in the middle of an encrypted communication, unknown to either end, and decrypt the traffic. A new version was released in 1996 as SSL 3.0. The next step of the standard is SSL 3.1 also named TLS 1.0. Only a few improvements were made for this version, but enough to make TLS 1.0 and SSL 3.0 incompatible. The current version of TLS is the 1.2 release from 2008.

Applications

So what is it used for? Well many people use it on a regular basis. In fact, TLS is used on many websites to provide the HTTPS connections. But it can also encapsulate other protocols, like FTP, SMTP, NNTP or XMPP. You can even use it to secure an entire VPN as with OpenVPN.

So is it secure?

The question can’t be answered as is. It depends…

First thing to rule out is that you are not using SSL < 3.0 versions. Since they all showed flaws they should not be used now.

Secondly we must ensure the implementation is correct. This question discusses the SSL TLS Renegotiation Vulnerability which is present in some browser versions.

Next we must make sure the connection is using encryption. What? Yes: TLS supports a mode of NULL encryption.

From curiosity I’ve looked in the about:config page of Firefox 5.x. Be relieved, all ssl2 settings and null encryption mode are disabled.

And finally you need to check that the connection has been established with regard to the protocol. You may be curious on what you could have done not to respect the protocol, let me explain:

Handshaking

The connection is established in multiple steps called a handshake.

• The client connects, and if it requires a secure connection it sends a list of supported ciphers.
• The server picks a cipher from the list (Usually the first in the client list which is compatible with the server list, not necesarrily the strongest), then it notifies the client.
• The server also sends back its identification, packed into a digital certificate. This certification contains the asymmetric public key of the server and it is signed by a Certificate authority.
• The client MAY contact this Certificate Authority to confirm the validity of the server’s public key. This is very important, but the cost of online verification makes it impractical. So usually, the browser embeds Certificate Authority public key to perform an online check of the server’s certificate.
• To generate the session keys, the client encrypts a random number using the server’s public key. Asymmetric cryptography makes deciphering the number without the private key infeasible.
• Now the client and the server have a shared secret they can use to derive the keys for the actual connection.

Protocol failure

One of the key point in this scenario is the verification of the Certificate. Did you ever connect to a site and see your browser pop up a message about the certificate? Did you read the message? Usually those kind of security warning are here to tell you that the server certificate has expired, or that it is not signed by a trusted authority.

Theses warnings are critical! You may be subject to a man in the middle attack. By clicking : go to this site anyway, you are giving your browser the express command to trust the certificate you were presented. But, unless you had verified it from the Certificate Authority yourself and decided it should be trusted, you could have accepted a forged certificate by a compromised authority. Your connection is then no longer secure.

Conclusion

Does this means that respecting the protocol ensures your security? Well yes.

Provided you made all the verifications, and as AviD said in the today’s featured question:

While there are some mostly theoretical attacks on the cryptography of SSL[TLS], from my PoV its still plenty strong enough for almost all purposes, and will be for a long time.

But I should ponder that yes the connection is secure. And even if we will not turn into paranoiacs of security, one should always ask oneself what the server will be doing with the data provided. It is a good thing to send data on a secured connection, but this has no meaning if the other endpoint forwards them on unsecured lines.

To dig more:

• http://security.stackexchange.com/questions/5126/whats-the-difference-between-ssl-tls-and-https
• http://security.stackexchange.com/questions/5474/forward-secrecy-with-https-and-aes
• http://security.stackexchange.com/questions/5699/locking-down-web-based-admin-areas-with-personal-ssl-certificates

Despite the security industry getting ever more professional, with well trained teams, security incidents seem to be increasing. Just look at the news recently:

• Sony – 23 incidents so far?
• UK NHS Laptop – over 8 million patient records
• Citibank – 200,000 customer records lost
• WordPress platform vulnerabilities (see Steve Lord’s presentations on this)
• Stuxnet – targeted at a specific use

From the 2011 Verizon DBIR

• 761 breaches of which 87% were in Hospitality, Retail and Financial Services
• 436 of these were in companies with 11-100 employees – so this is not just a problem for the big targets any more
• 92% of attacks (leading to 99% of records compromised) were external

Some new threat groups:

Anonymous and LulzSec – often punitive, sometimes for the Lulz

• HBGary
• ACS Law
• Spanish Police
• FBI, CIA
• Porn sites
• Took requests

So what do the security professionals do?

• After an audit fix vulnerabilities
• After an attack, fix the issues
• Use encryption and strong authentication
• Patch regularly
• Validate input, encode output
• Assess your 3rd parties
• Use a Secure Development Lifecycle
• Build security into everything you do

No problem, right?  If only it were that easy…

Your CEO wants the business to make money, so wants to minimise bottom line spend but will spend appropriately on risks to the business.

So why doesn’t the CEO see these security issues as business risks?

• Maybe they aren’t significant when compared to other business risks
• Or perhaps the CEO just doesn’t understand the latest security threat

Both of these are your problems. The security community is often called the ‘echo chamber’ for a good reason – we say good things and have good ideas about how to fix security issues, but we pretty much only communicate with other enlightened security professionals. We need to tell others in a way they can understand – but in general we talk technical 1337 speak full of jargon and no one can make head or tail of it.

It is up to you, the security professional to learn how to talk the language of business risk

There are materials out there that will help you:

• IIA GAIT – Guide to the Assessment of IT Risk
• FAIR – Factor Analysis of Information Risk
• ISACA CobIT – Control Objectives in IT
• ISACA – CRISC and CGEIT certifications
• IISP – approved Information Risk Management courses

Begin to understand what is important to a business executive and how they talk about it, and you are already well on the way to being able to articulate security in the same way. If you are a manager of security professionals, make it easy for them to gain exposure to heads of business, C-suite, executive, directors etc. and it is likely to benefit you in the long run.

These are good questions to prepare you for conversations you may have along the way

• What metrics should a CIO rely on to gauge risk
• How would you work with the security paranoiac on your team
• Can you provide loss values on security breaches
• How do you compare risks from website, physical perimeter, staff, etc.
• What are good threats to kick off conversations with others about what worries them

Question of the Week #2

Unlike last week, where we looked at a specific question @nealmcb recommended the entire hardening tag! This is a well highlighted aspect of Information Security since it is what got many of us into the field. We knew that the factory switch config or default Windows installation wasn’t quite good enough so we tried to figure out exactly what to change in order to make things better.

From the basic Operating System hardening techniques that many of us are familiar with, we as a community have started applying the principles to more and more devices. As of writing this entry we have 19 open questions in that area ranging from What does defense in depth entail for a web app? to Best practices for securing an iPhone.

In my opinion, we’re clearly Getting It ™, as an industry, when we have moved on from Hardening Linux Server and are having real honest discussions about securing iPhones and Best practices for securing an android device.

In addition to the mobile device questions listed above, I think my favorites so far have been:

• Apache Server Hardening (Eric W)
• IIS and SQLServer Hardening (Voulnet)
• What methods are available for securing SSH? (Olivier Lalonde)
• What does defense in depth entail for a web app? (VirtuosiMedia)

While some questions have received a large amount of traffic, such as Apache Server Hardening at 9 answers and over 1000 views, others have managed to slip through with relatively little traffic, like How do I apply a security baseline to 2008 R2? slipping in at 1 answer and >200 views.

Is there a platform you use that you are not sure how to secure? Do you have experience with hardening a particular configuration? Join the party by browsing through the questions in the hardening tag and adding your own fancy tips and tricks. Better yet, ask ask ask! Show us up, or work us hard.

Question of the Week #1

How does changing your password every 90 days increase security? As selected by @HendrikBrummermann this has been one of our more popular posts, with discussion on the reasons for password expiration:

• To mitigate the problems that would occur if an attacker acquired the password hashes of your system
• It prevents people who use the same password for everything from getting your system compromised if their password is figured out somewhere else
• Compliance reduces the risk of penalties of non-compliance (thanks @AviD)
• By resetting password every X days we are telling the user – Hey, this is important and it should not be taken lightly

and Against password expiration:

• Your password, and the attacker’s guess at your password, are independent. The probability that the attacker’s next guess is correct is the same even if you change your password first.
• Nothing encourages passwords on post-its quite like frequent expiration, especially if there are also high complexity requirements
• It annoys users
• They end up having to work out a new password – which research shows is often is derived from the previous one in a way that is very easy to crack nearly half the time
• You can expect additional support costs to cover users who have forgotten

How to balance the pluses and minuses depends on your organisation’s risk profile and other requirements.

An alternative to password expirations is requiring stronger passwords, and we have questions and research on that also.

The associated question – Why do sites implement locking after 3 failed attempts – details another aspect of the defence against brute forcing, and discusses why 3 may or may not be a suitable number.

These questions, answers and commentary are well worth a read if you are trying to set a password expiry policy in your own organisation, or want some background as to the risks.

After 242 days in Beta, we now have over 3000 users and an active community of security professionals, hobbyists and specialists providing input, answers, moderation, blog posts and their own time to make the site a global success.

Congratulations to all the members – your effort has paid off, and today we joined 27 other official sites in the Stack Exchange network, and graduate as a fully fledged member. We’re excited to see the new visual design by @Jin (with comments and ideas from many of our core contributors) that permeates all aspects of the new site and blog. Various people see various things in it – the noble and powerful lion (Aslan?) on the great shield of security, wings for swiftness and protection, the various flanking maneuvers and battles raging in the background. As per the other StackExchange sites, you will even be able to get t-shirts and other logoware soon.

What does graduation mean?

A design, official inclusion into StackExchange – statistics, API tools etc. A greater presence online.

Reputation and Privileges

Private and public beta sites operate under reduced reputation requirements. This allows young sites to grow rapidly. However, when the site graduates from beta, the privilege levels return to their normal levels.

This means 19 of you have lost ‘Edit Posts’ privileges until you get over 2000, and 51 have lost ‘Vote to Close’ until you reach 3000. Don’t worry – you can always flag issues and a mod will take care of it. Once you reach the normal thresholds your privileges will automatically return.

But what is the IT Security Stack Exchange for?

From the FAQ:

IT Security – Stack Exchange is for Information Security professionals to discuss protecting assets from threats and vulnerabilities. Topics include, but are not limited to:

• web app hardening
• network security
• phishing
• risk management
• policies
• penetration testing
• security tools
• using cryptography*

Celebrate success

Let your colleagues know about the site and the blog – we already get around 1000 visits a day, but the more people who come, the wider the pool of expertise we can bring in.

We also have a twitter hashtag – #stacksecurity – so feel free to communicate to the twitterverse to let people know that answers to a lot of security questions are here.

*Also, we have just heard that a closely related site, the Cryptography Stack Exchange, has just reached 100% commit so will be entering private Beta now. While Security Stack Exchange will continue to have as one of our disciplines the understanding and management of risk in crypto implementations, here we steer clear of the mathematical issues and concentrate on security and risk.

White Hat Events is a collection of individuals from the UK’s Information Security Industry who get together to raise money for charity. The events each year include the White Hat Ball, Marathon, Golf, Cocktail Party and Rally.

The 2011 Carry-On themed White Hat Rally was fiercely fought over the weekend of 1 – 3 July, with teams from security consultancies, vendors, suppliers, and independent contractors all over the UK taking part, and raising money for and the NSPCC’s Childline, with a total raised by Sunday topping £25,000. Across the sunniest 3 days this summer we travelled from Brighton to Blackpool, following clues, competing in challenges, suffering japes, sabotage and mechanical issues, and enjoying the hospitality of towns along the way, as well as getting to know a like-minded bunch of security professionals all trying to make a difference. I joined the Northern UK Security Group (NUKSG) team in Leeds on Thursday, and we drove the Yellow Peril (an ancient Dodge Caravan bought for £350, bright yellow with an interior entirely covered in red velour) down to Brighton, where we met the other teams for a pleasant social…quite late on, due to starter motor issues, traffic, and the Yellow Peril’s lack of a top speed (among other issues)

Day one – we met up at Brighton beach, a motley collection of classic cars, sports cars, agricultural and emergency vehicles and bangers. The day involved a lovely journey across the South Downs, following clues and ending up in Cheltenham. Each team had GPS tracking apps to allow the organisers and families to see how we were doing.

At our first checkpoint stop the Pirates O’ Pentest opened up the back of their ambulance to display a fully featured and functional cocktail bar – which went down very well at each stop for the next 3 days – raising extra money for charity.

Lunch was hosted at Brooklands Museum, the birthplace of British motorsport and aviation, and included a speech by Diana Moran (the Green Goddess), who also led us in some mild aerobics, despite being in her 70’s. I was delighted to sit on the famous banking I had heard about since my early childhood, poke around the classic cars and aircraft and play on the F1 simulator.

Due to a minor organisational hiccup, The StoryTeller restaurant in Cheltenham were not made aware of the party of 67 until a couple of hours before we arrived, but they coped amazingly well – getting us all seated and providing a lovely dinner. The Scavenger Hunt in Cheltenham attracted a few entrants, but we didn’t find out the results until Sunday night.

Day two – saw us winding through the countryside up to the oldest brewery in the UK, the Three Tuns in Shropshire, for lunch, a tour of the brewery and tasting of some new brews.

We also met the lovely Clare Marie – the hostess of Dr Sketchy’s London art events. The afternoon drive then led us up to Buxton and the Palace Hotel for our evening stop. Once again we were provided with an excellent dinner, this time at the Railway, and a Carry On quiz.

Day three – a relatively short run, with some straightforward clues that got us to Blackpool, and the Big Blue hotel – which is where we were finally joined by 2 of our number we hadn’t seen for the entire event…because they cycled the entire way!! Fancy dresses were out in force, and everyone had a great time on the rollercoasters and rides before dinner (can’t believe I stayed on the Big One for 3 laps – it’s 235 feet high, one of Europ’s highest roller coasters and I’m terrified of heights!) and prizegiving at the White Tower.

Team NUKSG did not win best dressed car, best fancy dress, or prize for quiz or scavenger hunt, however we did raise the most money so we were the overall winners and took home the star prize – a bottle of the Three Tun’s Cleric’s Cure each!

We are obviously keen to keep raising money so please visit our sponsorship page. The official picture page is here at Picasa – with folders of photos from each car, as well as the Marshalls.

Many thanks again to my sponsors:

Security Stackexchange – Robert and the team provided us with sponsorship and we grabbed a couple of Stackexchange logos to stick on the car, one on each side. This went down well with the technical security folks we were competing with.

Virgin Money – Virgin’s banking department, and the providers of Virgin Money Giving – the only not-for-profit charity payments site.

Metaltech – my Rock band, preparing for new album launch party in August (@metltek and #burnyourplanet on Twitter)

According to Rory Alsop’s post the most popular topic at our IT Security site is passwords.  So in this post I’ll provide a tour of some relevant questions and answers, and a look at how it sparked further investigation of the sorry state of password protection in some current systems.

There is an amazing amount of confusion, disinformation and bad practice out there with respect to password management.  This is all the more frustrating because the basics were worked out back in the dark ages (1978 to be precise) for Unix by Bob Morris and Ken Thompson (Password Security: A Case History, Morris & Thompson, 1978). They not only covered the importance of hashing passwords with salts and a slow algorithm, but they described what is now called a “pepper” (a second salt stored apart from the password database).

So if you peruse the dozens of ‘passwords’ questions you’ll find frequent reference to the basics.  We’ve also tried to summarize some of the key points in the ‘passwords’ tag info.  By the way, that’s one of the cool things about StackExchange sites in general – how they provide for a little “wiki” for each tag, to allow us to put key information just a mouse hover or one click away from readers.

Of course even among good practitioners, there are debates about the finer points, and that is another thing you’ll find here.  See e.g. the spirited conversation about highly iterated password hashes for web apps vs the risk of DDoS attacks at Do any security experts recommend bcrypt for password storage?.

In the end, you’ll often find that the right approach depends on what kind of “security” you’re looking for.  As our Frequently Asked Questions points out, this depends on context – what assets you’re trying to protect from what sorts of threats, how your different vulnerabilities compare, and how that all fits into your business plan.

I’ll end with a look at one question which demonstrates the kind of expertise we have already attracted to the site: MySQL OLD_PASSWORD cryptanalysis?.  I asked this after stumbling across some other questions about how MySQL used to deal with passwords.  To my amazement, within hours, noted cryptographer Thomas Pornin had not only cracked the old algorithm, but he included some code to demonstrate just how totally broken the OLD_PASSWORD scheme was.  Subsequently we also found a paper from 2006 with more details.  Evidently the folks at Oracle who work on MySQL hadn’t gotten the memo then, and still have a lot of work to do to improve their current scheme, as described at Looking for example of well-known app using unsalted hashes.

So stay ahead of the crowd: when you have a question about security, see if we have a good answer.  If not, ask away.  And if you see questions that need more work, please contribute to providing good answers!