Confused by crypto? Here's what that password hashing stuff means in English Cryptography is dead hard. But being conversant in the key aspects of cryptography – to the extent that you could even explain some of it to colleagues and management – puts you one step ahead of most. Here are five things that'll make you sound like you know what you're talking about. 1. Digital certificates The most common …
New = secure
Middle age = not secure, but hard to crack
Old age = don't rely on it
Author touched on this towards the end of section 3.
Failures are most often due to subtle flaws, not speed up of brute forcing.
All cryptos seem to fail eventually, and not once has it taken 10^77 years.
Good of El Reg to have bluffer's guides, but no mention of salts with hashing? A fundamental requirement, otherwise if you've got a table with lots of hashed passwords, just look for matching pairs and you can be pretty sure they are weak passwords, crackable with a dictionary of common passwords. Solution is to store the hash and a random salt in the table.
This article seems to be a good one for crypto and hashing with salts:
I did something like this manually in the late 90s when I'd only just started in IT. My boss had written a program which would add the admin accounts for all of his IT staff to different domains, I was given the job of driving around running it on the servers using floppy disk (ah bless good old 3.5inch).
At home I decided to open it up in a hex editor out of interest and noticed the usernames in plain text and hex next to them, I only knew my own password so could figure out which set of hex was mind thanks to thankfully having my word end in "wood", those double "o"s were indispensible.
After sitting with pen and paper deciphering my own password and figuring out how the hex related to the letters and numbers in it I went back and took note of everyone else's password.
I never used the knowledge, it was just a bit of a challenge at the time.
Maybe for the sake of completeness, you may add certs can optionnally also be used to authenticate client users.
I know, almost nobody has ever used it, the only web site I've seen use it was the french online tax declaration web site, 10 years ago. But they removed it 3-4 years ago, probably because no-one was able to install a client cert on their browser :-)
"...since SHA-3 was officially released as a standard in 2015 you should choose that if it's available in your implementation... it's only been around for a short while and hence people have had far less opportunity to break it than the its 2001-launched predecessor."
Wouldn't it be wise to wait a while, give more people the opportunity to try to break SHA-3? I'd say we're less sure of how secure something is, if less attempts have been made to break it.
It's an excellent question - and one that we debated at length with the instructor (a time-served, PhD-holding security guru turned security instructor) on my CISSP course last year, actually. You're absolutely right to point out that it says something when an algorithm has been around for years without being (knowingly) broken. On balance, though, we decided that the goal of making SHA-3 significantly stronger than SHA-2, combined with the intense competition and scrutiny involved in the selection process for the algorithm of SHA-3 (it literally was a competition - check out https://en.wikipedia.org/wiki/SHA-3) probably made it the one to choose.
In practice I'd be happy with either SHA-2 or SHA-3. And for reasons others have alluded to in comments here, you wouldn't touch the previous versions with a bargepole.
For some perspective, the cost of generating a collision for md5 is less than a dollar. Generating an sha-1 collision is in the order of 75,000 dollars.
For most threat models, collisions on sha-1 are not a real world issue just yet; but it takes a while for it to work its way through the system. If you keep using sha-1 certificates, then by the time those new certificates expire then the collisions will probably be heading towards half that price. The point was to sunset it before it got to the point of actually being insecure.
Generating an sha-1 collision is in the order of 75,000 dollars.
Probably more, since no one has published a true SHA-1 collision. The $75K figure is a wild-ass guess, extrapolating from a free-start collision. While that free-start collision is an important result, it is by no means a true image collision.
The fact is, at this time, SHA-1 remains more than adequate under many reasonable threat models. People are deprecating it mostly because it's easy to do so (since the SHA-2 family is widely supported, and SHA-3 is getting there), so we might as well get started.
"Don't ever try to write your own! You will fail, completely, dramatically, and embarrassingly."
That rule applies to far more people and organizations than is widely believed. Orders of magnitude more. Further up the crypto hierarchy than can fit into naive minds.
E.g. Right now, somebody is working the long weekend to crack open a certain 'uncrackable' iPhone.
It's hopeless.
Better read Asimov's 'The Dead Past', because that's exactly where we're headed.
Yup, I'll second that. It's a mantra that you can apply to pretty well any field of computing, actually - these days there's not often an instance where you have to write something from scratch in its entirety. In fact I can only remember one instance* in recent memory where I've had to do so - most of the time there's something out there that you can use to solve part or even all of a problem.
(* If you're wondering: it was a code library to enable a Mac to interface directly to an Inter-Tel phone system's CTI stream).
Unluckily, even if it was meant to work that way, is not how it works actually - because CAs are commercial entities and certificates are a business. Thus plain certificates can be often be bought without much vetting from CAs - unless they are the more expensive Extended Validation ones.
Some CAs are known to be too little careful about what they issue, up to the point some (i.e. Google) is putting them in the "you should not really trust them, or trust them at your risk" lists.
Moreover now in the push to encrypt communications for fear of three (or four) letter agencies intercepting them, there are now non-profit entities issuing them, again without much vetting.
Given the increasing importance certificates have, IMHO that should become a regulated market as other are (i.e. banks) with full accounting and liability if something goes wrong (not that bank are held much liable, though...). After all, nobody ever said certificates should be very cheap.
Given the increasing importance certificates have, IMHO that should become a regulated market as other are (i.e. banks) with full accounting and liability if something goes wrong (not that bank are held much liable, though...). After all, nobody ever said certificates should be very cheap.
I'm sure the NSA and GCHQ applaud your sentiment. Do we all really need certificates to become as screwed up as health care or taxes?
Would you like everybody being able to setup a bank - without any check, or make/sell pharmaceutical? I'm not saying those markets are often bad as well because people with a lot of money can easily lobby and deceive a lot - but without regulation people would be exposed to even more bad guys exploiting them. Would you like passports and driving licenses being issued like certificates are? Very little checks, just pay?
Face it, if you can't trust who is behind a certificate, certificates are useless. Actually for NSA & C. the situations is far better now, and for crooks as well. Far easier to MITM whoever you like - making encryption just a fake one. You have very little chances of being sure a certificate is issued to a verified entity. If the big names are somehow protected, the medium/small ones are not.
Then you can believe government and any rule are always bad - you should just try to live in a true anarchic society - usually they don't end well and degenerate in the worst way.
Worse yet... effectively to get a certificate from a CA you have to convince them to take money from you. In the case of EV, you need to convince them that you are a company before they will take your money. That doesn't always mean you need to *be* a company, just that you have to convince them you are. Easiest way to convince them of course is to actually be a company, which (taking a quick look at off-the-shelf pre-registered company suppliers) will set you back all of £60....
The CA model is broken, as demonstrated by a fair few incidents reported in El Reg and other techie media.
In the absence of a WoT made simple enough for Joe Public, a move to a distributed trust authority is overdue. M-Pin gives us the framework for that.
Yeah, it's an interesting point. I remember applying for my first digital cert back in the 1990s - it was an absolute ball-ache as we had to send all manner of documentation to the CA - articles of incorporation, the lot; I was half-expecting to have to send a vial of blood. It's a whole lot easier these days. One would hope that the browser/OS makers would remove trust for CAs that get themselves a reputation for being over-easy ... whether that actually happens is another thing entirely, of course.
"nobody ever said certificates should be very cheap" -
but they are a lot more useful if they are cheap AND trustworthy. If they are cheap, then everyone can afford one, so everyone expects them to be used, and all transactions become more secure. If they are expensive, then the expense excuse is routinely accepted, and even organisations that buy the expensive certs don't get the full benefit because their customers can be fooled by the excuse.
I think this article has lost the fundamental point about certificates, which is that the certificate declares that *the holder of a specific private key* has the asserted identity.
The way this article reads, you'd think that certificates are something private - something that you have to keep secure and not give away, like a passport.
This is simply not true. You can publish your certificate to anyone who wants to see it. Indeed, when you make a TLS connection, your certificate is returned directly to the person connecting, no questions asked.
The certificate is a document which binds together:
1. an identity (e.g. www.facebook.com)
2. a public key
3. a validity period
4. a signature (created by a CA using their private key)
The website has to go through a dance to convince you that they possess the *private* key which corresponds to the public key in the certificate. Then you have to validate the signature, using your local copy of the public key of the CA. And you check the current time is within the validity period.
Once you've done all this, you know that the CA asserts that the server you are talking to has the given identity.
This article leaves all mention of public/private keys until point 6, and as far as I can see, makes no mention of the intrinsic use of public/private keys with certificates. If you don't understand this, then you don't understand the risks with certificates (e.g. if your server is compromised and the private key is lost).
If you want a non-technical analogy, then the certificate is like a glass slipper. The identity is Cinderalla, the private key is her foot, and the Certificate Authority is the Fairy Godmother (who made the glass slipper to fit Cinderella's foot and no other).
The other point about certificates is that they normally make no assertion about the principal apart from "this key belongs to the owner of domain example.com". With the advent of free CAs like startssl and letsencrypt, all you need to do is to prove you can add a DNS record or receive an E-mail at the domain contact address, and you get a certificate.
In particular, a certificate provides *no* assertion that:
* This site is a particular type of institution, say a bank registered in the UK
* This site is "trustworthy" or "safe to do business with" (for some definition of those terms)
However, if you're lucky, an "EV" certificate will give you a verified company name of whoever you are talking to.
A certificate islike an ID card or passport, you can show it to anyone you like and it says the issuing authority trusts the person detailed within, but you missed one thing, the user provides the certificate along with a signature, it's hostname encrypted with the corresponding Private Key which the user decrypts using the Public Key on the certificate and checks against the hostname on the cert hence verification.
I.E. cert says "I (CA) certify that if you decrypt a signature using a set algorithym, using this public key and it has this identity (issued to), during this period (Validtity), the identity is trusted by me (CA.)"
Nice one, Dave. Short, sweet, to the point and factually correct.
An object lesson in how to communicate complex ideas with simple methodologies so that they are understandable for a user.
And while I agree that salt techniques are important, I disagree with a commentor that they were "missing" from this document. That subject belongs on a follow-up article.
I'm bookmarking this so I can share it with interns and new hires.
Have beer.
An unsalted hash is merely obfuscated and not encrypted
A salted hash isn't encrypted either.
this is why salts are essential and not optional
There are many applications of cryptographic hashes where salting is not required, such as typical MAC and HMAC applications.
But I suppose this is the sort of comment to expect on an article that claims ECC is an asymmetric encryption algorithm.
Unfortunately, where I work they snoop everything. Our wonderful IT guys have installed a fake certificate into all the IE browsers (the official browser), and they launch a "man in the middle" attack on any https traffic. (That's why they don't have time to FIX the many problems our systems have, because they're too busy playing Secret Agent Man. Well, one has to prioritize.)
I use Firefox and was warned immediately when they started this snooping. Firefox warned me that every SSL conversation was not to be trusted. That was clearly because Firefox did not have the bogus certificate installed. I know this is true because I tried installing the bogus cert into Firefox, and the warnings stopped instantly.
On the other hand, after reading this article, I installed Chrome, and I did NOT install any certificates into it. I navigated to Google.com, and Chrome was completely happy with the web site. I checked, and it's showing the bogus self-issued certificate as completely trusted. I wonder what is going on with that? Firefox detected the snooping, and Google completely ignored it.
Maybe I'm missing something, but it seems that Chrome's "Pinning" needs work.
AC for obvious reasons.
Not sure what version of Chrome you use but for me (Chrome 49+) Google "breaks" at one customer site because they MitM via a "transparent" proxy. These SSL deal breakers are arguably valid in a school for the kids only but legally suspect in a business IMNSHO.
I once pointed out to someone in a NHS hospital that their WiFi had a MitM proxy and that hence they would be advised not to use it for online banking. Strangely enough a proper(ish) warning appears now when you connect.
I use an OpenVPN through the proxy back to base. Their logs must look hilarious and the content checkers must have fun looking at gibberish. A funky L7 filter could block my VPN but it will hard fail safely unless the server cert checks out properly. I'll just use my mobile instead via tethering.
More or less every organisation will do something similar, not because they want to read your billets doux to your significant other, but so they can check that attachments in encrypted emails are free from (obvious) malware. Most security devices come with such a global certificate, which the sysadmins can install on all machines under their control.
Steve Gibson has some nice freeware to check for that, if anyone is worried their employer is doing the same - Fingerprints
Why not offer more 'learning' articles? Three stories El Reg ran this week on Ransomware / USB-Malware didn't have enough 'insider' or technical content imho (see below). Users asked me challenging questions I couldn’t answer, as nothing I'd read on the Reg was in-depth enough, just the equivalent of the BBC 'dont scare readers' etc...
====================================================
forums.theregister.co.uk/forum
/1/2016/03/22/encryption_ransomware_going_out_fashion/
Question: Can you slave the drive / use a USB enclosure to get at the files?
====================================================
forums.theregister.co.uk
/forum/1/2016/03/23/usb_only_trojan/
Read the Reg article and the linked one, but not clear about something:
Q1. Connecting the USB causes install driver code to run off the device itself (firmware)? I thought driver install code only ran from drivers installed on the windows side? (assume 'Autorun' disabled)
Q2. Does the Trojan use a Hidden partition to store itself or the offline captured files? (Reported free space gets masked etc)
====================================================
forums.theregister.co.uk/forum
/1/2016/03/22/pc_world_knowhow_shortcomings/
Starved of information: 3 things never learned from Randomware tech articles...
Q1: Any of the Ransomware variants show up in Task Manager... If not, are they using $Hidden processes or obfuscated as windows subsystems (i.e. svchost etc)?
Q2: Does running a profiler like SysInternals-ProcMon, help? If you set Winrar to backup your entire hard drive etc, it has a noticeable effect with greater hard drive activity and a slowdown in performance (even running in the background). So is ransomware running at low priority yielding to the OS and other tasks to help keep it hidden?
Q3. Saving M$-Office files without file-extensions... Does this offer a shred of protection? (Lets say you're giving out advice to friends / family who you know always ignore errors and only update AV / anti-malware at Christmas, if ever)?
====================================================
Thanks for the positive feedback. If you're old enough to remember Network Week (launched 1995, ran for a few years), you may remember a column entitled "RTFM". This came about by accident: on press day the ed came to me to see if I could throw a thousand words together to fill an unexpected gap. So I did a basic intro to something (IP networking, I think it was) - really noddy but it got us out of a hole. Then we got loads of email from people saying: "Hey, that taught me enough to understand some stuff that people were saying, and helped me be a little bit conversant". So we did loads more over the weeks, and they went down well.
I'll have a chat with some of the editorial gang at the Reg and see what they think.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
