I'm going back and forth with Kris of Cocktail.

He claims that mountain you can no longer user enter as your password. Yet it seems ok.

Cocktail also now ask for admin and pass for every launch.

Anyone else notice this is bit weird?

I don't know about Mountain Lion's login requirements, but that system utilities require an admin password is perfectly normal, and has been like that for quite a while. To be allowed to do their work in the guts of the OS they need that admin access. If you think about it, you really wouldn't want anything else.

I prefer that system utilities work similarly to System Preferences, which only asks for an admin password when you ask it to do something that requires admin access; Yasu works that way, and I've never understood why other utilities don't.

ENTER is still valid for a user admin pass no?

Unless you mean actually using the word Enter, technically pressing the Enter key is not a password. Hitting the enter key submits a null or blank password. However, in today's environment it is considered by many to be a very risky practice used by badly informed or outright foolhardy users. However, null passwords can still be used but I suspect Apple has deprecated its use because of the dramatically increased security risk, and the increasingly dangerous, even hostile, internet environment.

As I recall, Cocktail's password behavior is not new and like Onyx has required initial passwords for some time now. The only similar utility I have that does not start with asking for the admin password is TinkerTool System which only prompts for the admin password when a process is initiated that requires one. Personally I prefer the initial password request used in Cocktail and Onyx as the password only has to be entered once whereas in TinkerTool System it has to be entered or re-entered for each procedure that is initiated.

Clarifying Yasu, it presents a menu of check-boxes and asks for your password only once, and only in the event that you check at least one box to perform a task that requires one.

Joe, I got this tip years ago, to use the enter keystroke as the password, from one of those OS tip books. I've loved it ever since. I'm on a desktop only I use, here at the house, what's the problem?

Now before this last version of Cocktail, I would click the cocktail icon in the dock and cocktail would launch without asking for anything. So isn't this a new thing for cocktail? I just upgraded.

The problem is the password protects your computer from malicious software and/or web sites that would like to install some type of malware on your computer. If your computer is at your house AND you NEVER connect it to the internet and NEVER install any software that you do not receive on a CD from a known reliable source then you probably do not need a password. So, unless you are using an iPhone, iPad, or similar device, your presence on these forums indicates you are regularly connecting to the internet and thus vulnerable to intrusion.

However, once you have a connection to the world outside not having a password dramatically increases your risk from malware. Even if you have antivirus software and your virus signatures are up to date there is no reason to be sanguine. Much of todays malware is…

1. undetectable by antivirus programs
2. indistinguishable from "good" software you are downloading
3. the malware disables your a/v protection before it can be reported
4. able to trick you into installing it without your realizing what you are doing
5. all of the above

I am not a conspiracy theorist, I refuse to live in fear of "the bad guys" on the internet, and my security precautions are no where near as stringent as some on these forums, but I do try to be prudent. That includes protecting my computers, iDevices, and networks with reasonably strong passwords. I also try to use reasonably "strong" and unique passwords on all sites I visit that require them. I store my passwords in password protected database files on my iMac, iPhone, and iPad.

I am not alone in touting the need for better computer security. There has been a plethora of recent news articles bemoaning the relatively lax security precautions in government, business, and personal computing systems. Congress has announced they will be conducting hearings on the subject but by the time they figure out what they want to do, it will be ancient history to the bad guys. The DoD has declared internet security one of the greatest threats to our nation's security and they are not talking just about their own computers but how our personal machines can be used by the bad guys for their nefarious purposes.

Because BSD Unix, OS X, and Apple computers are relatively secure in comparison to Windows boxes many Apple users have become sanguine and feel invulnerable, but that can change overnight. Doing what we can to make our Macs a harder target — like using password protection — will hopefully make us a less tempting target for future exploits.

Joe, thanks.

Do you log in with a password on your home desktop every time you use the computer? I don't. I just have it there on at the ready all day long.

So I'm at home, the computer is on all day long. No antivirus.


Issue one is theft:
Trade offs.

I understand wanting a password for a lost laptop and even a the possible home burglar.

Issue 2 is what you are discussing. The internet:


Software I download is software I want, so I just click the enter.
Mostly everything I download is from good sources, that's why I'm installing it. And then even if I had a password, I would still use the password and then install it.

So what good is the password in this respect?

In short, did not fully understand your post about the internet issue.

the problem recently has been that you cannot have a blank admin password to use SUDO. Utilities like cocktail may use sudo. Apps that are actually applescripts or that use apple events may have the same restrictions.

When I'm working on a customer's computer and the admin password is blank, I frequently have to set it to something to run many of my (homemade) tools.

I typically leave it set unless told otherwise, as it provides more security. I'd bet the whole idea was that apple wanted to prevent trojans or apps that manage to find a dropper/driveby download entrance can't just run automatically as admin.

The idea that something from a "good" source is safe doesn't necessarily hold up.

One of the most popular tricks that malware writers use is that they will hack a large, well-known site and install the malware droppers on it. Web security is hard, and even huge multimillion-dollar companies don't necessarily hite programmers who understand security.

In the past several years, malware has been found on sites like the official Delta Airlines site, Newsweek's site, Time magazine's site, Adidas, and more, and used to spread malware. Also, a common technique that Eastern European organized crime will use is to set up fake companies and buy banner ads that redirect secretly to malware sites, often without even being clicked on.

So only sticking to known "good" sites actually is no guarantee of protection.

V. hmmm , he mentioned something about sudo, Fine, but why does cocktail had to ask for a password every launch, isn't that new. Don't remember that before.

Tacit, But even if I make a simple password, I'm still going to download the software.
---

as far as trust. I don't what to say. Cocktail for example, I don't get on a CD. People suggest software all the time for all types of things on this and other forums. So apart from the famous ones, that's what were talking about.

it asks at every launch so it doesn't have to store your admin password in a reversible form somewhere. it's actually a really good security feature.

Actually software on CDs is not immune from being infected with viruses. Over the years several very reputable companies have unwittingly shipped CDs/DVDs that were infected. There have also been very recent instances of new hard drives coming from the factory in China with malware pre-installed. No few of those drives were installed in new computers and shipped to the stores for sale to the public.

A number of software applications have been recommended on these forums, but that recommendation is generally based on someone's experience with their copy of the app which in no way should be understood as guaranteeing the copy you get will not be infected. Lately I have been choosing to limit my software purchases to the App Store, if at all possible, on the unproven theory that Apple has a vested interest in being particularly rigorous in keeping malware out of their distribution channels.

The point is that it is a dangerous world out there and it is prudent to take at least minimal precautions such as using strong passwords. Not having passwords is like leaving your car with a back seat full of purchases unlocked with the keys in the ignition while you go Christmas shopping for a few hours at Walmart. Someone could steal your purchases or your car even if it were locked and you had the keys in your pocket, but without those minimal precautions you are low hanging fruit ripe for the picking.

Joe, you got me spooked, but I'll hold onto this info!

Virtual1 mentioned the non-blank password requirement for sudo commands. This may sound far from your bed, but it isn't really. Among other things listed in this thread, leaving open your account password affects your ability to fix Home folder permissions. Many users sooner or later run into problems that require them to fix Home folder permissions (also known as ACLs or Access Control Lists), or live with the limitations the issue imposes, like the inability to change the name of files and folders, or to move or delete them. ACLs are not affected when you repair (System) permissions with Disk Utility etc. See for an example the Apple KB article Mac OS X v10.5: Renaming or... folder (note that this issue is not specific to Mac OS X 10.5).

Keys if you really want to get spooked read this New York Times article. Read the entire article and don't stop at the headline.

Thanks A and Joe, I read that article when it came out, as I get the NY times, but your link, makes it hit home a lot more.

So my personal passwords are on an excel file (there are about 200), and then I have an excel file with software passwords too.

They are on my main hardrive, just in a normal folder. I'll make a encrypted one, but it's a real sacrifice as I've gotten so used to the convenience of a quick keystroke to bring it up. And it seems I do have to bring it up quite often, especially for log ins to forums.

I should also probably make a password for the computer as noted, but it's a little scary in that: what if you forget your password? That one has got to be memorized no?

Finally, for my desktop, I do leave it on all day. I never log out between uses. Your opinon on that A and Joe?

I pop down in my chair maybe 6-8 time day and just work. No log in.

My computer runs 24x7 and I do not log out when I am away, but I do shut Safari down when I am not using it. On an often repeated recommendation from my bank (USAA) when I leave ANY financial site after I log off of the site I quit Safari, or whatever browser I am using even if the next thing I am going to do requires me to relaunch Safari.

Not to quarrel with your use of an Excel file to store passwords but the App Store catalogs nearly 130 dedicated apps for secure storage of password and other data. Thirty-six of them are customer rated at or above 4 stars. Many of them will even generate secure passwords for you.

Joe, that was my first question. So you recommend quitting Safari after you walk away from the computer? This is how most people get into your machine, the internet? Hard habit to make, but I can do it.

That article Joe does not speak so highly of password software.

But you are ok with leaving the machine on all day, as long as the internet is closed. I guess the only worry is if your computer got stolen while you were shopping at the market, they would have instant entry.

What about the camera on the computer! Never thought of that. Not a bad idea to put a black sticker over it?

I just made a password with 100% strength I could memorize. I guess I'll use for my apple id with my credit card tied to it. And maybe a few other critical things.

The article had there other interesting points:
Ignore security questions? I would never have thought of ignorning them.
Using different browswers - bit tedious.
Don't register online with real email address, bit overkill?

PS, I think maybe mountain Lion is shipped with Firewall turned off. I did not know. I can't get into Photoshop now, it says my password is on 2 other computers. I may have been hacked! Whey would they ship with Firewall off? crazy.

Of course I could be wrong...

It is shipped with the firewall turned off because that will result in Apple receiving fewer complaints and questions from people. The alternative is to deal with all the "I can't access…", "I can't receive…", I can't download…" queries. Is this safer for the end user? Irrelevant question since we can't control Apple. Take it or leave it.

I strongly second the above comments about getting software to store your passwords. These applications can be accessed with a user-determined keystroke, use fairly strong encryption to store your passwords and many allow secure access from iDevices (convenient and also serves as a backup to the original on your computer). Many (e.g., Data Guardian) also can handle importing from Excel, which will save you enormous amounts of time.

Wow, thanks Ira, man, so my computers were both off firewall for a couple of weeks without me knowing that, and my laptop and all my passwords and software serial numbers on the desktop for quick access which I was getting settled — with the internet on a lot. And now Adobe says my PS CS5 is on 2 computers and I cannnot use the software. I hope it's all a coincidence.
I cannot fathom how a password software would help me.

ONe thing about excel is the true user names and passwords are not listed. The user often something I memorized, and I just put "standard", and the pass often lead with some digits I've memorized with a dash and a couple of new characters. I don't think you can beat that. With those software you are supposed to put the actual uncoded user and password. what is the upside to that?

You're asking us to second your rationale for your lack of security, and that's just not about to happen (and I say that despite the fact that my own security does not live up to the standards that have been set out in this thread).

Bottom line is you've read the article and the responses to your posts, and if you're happy with what you've got, live with it; maybe you'll never pay a price, but that's your gamble...your own odds to set.

PS: The first thing on my to-do list when I either re-install or upgrade an OS or buy a new deuced Mac(hina), BEFORE I ever connect to the Internet, is check to make sure my firewall is turned on, because there are some things you NEVER take for granted.

Edit: And, by the way, if you're not running Little Snitch, you should be!

While we're on the topic, here are some recent & related ruminations:

- What you don’t know about passwords might hurt you*
- Mac Gems: Little Snitch snitches on misbehaving apps

I previously linked to articles discussing various aspects of online security. They remain relevant, and some of them can be found HERE.


*) You may of course choose to ignore these recommendations, perhaps because of some of the comments, but that doesn't exactly maintain or improve your security either.

thanks Artie, A , and Joe, I'm reading everything here, nothing is being ignored, will study all the links.

Just remember that even if you're shooting craps with Zocchihedrons, boxcars snake-eyes is gonna come up sooner or later.

I suppose memorizing all of your passwords is the most secure method—until you forget!

Some password software gives you the option to display or not display the actual password (it can be toggled off and on), but the whole point of using password software is that everything is readily accessible if the user knows the password required to decrypt the password database. One password gains access to all passwords.

While this might sound scary and high risk, this example shows how four simple words can provide more protection than some exotic multi-symbol single "word".

And as always, what we choose to do is often dictated by our personal comfort level with our choice.

I am not an expert on Adobe's strategy for protecting their digital rights but I know that it is arcane. I am betting the two installed copies of Photoshop are both on your computer. Possibly one copy on your regular hard drive and another on a clone drive (assuming you have one), or if you have installed a new hard drive and restored Photoshop from a backup Adobe is seeing the new drive as a new machine, or Adobe thinks the Photoshop installation on your HD is on a different machine because you have upgraded your OS X version. Or some variation on one of those scenarios. I suspect a call to Adobe tech support can clear up the problem.

Hackers are generally not interested in stealing your software, they are primarily focused on obtaining items of real value such as your name, social security number, date of birth, etc. With that information they have all they need to steal your identity, open credit cards and charge accounts, take out loans, mortgage your house, and leave you holding the bag. If they can get your bank account numbers along with the other information they can withdraw all your money from the bank, max out your credit cards, and in general leave you penniless. Don't be fooled into thinking the police can or will be able to help you — they can't and won't. The police agencies that are capable of tracking and prosecuting these felons can be counted on the fingers of one hand and all too often the thief that steals your data lives and works in a country that has no extradition to the U.S. or Canada. That person then sells your data to yet another person, or persons, who then use your data to steal your money, your property, your credit rating, and your good name.

Very well stated....short and to the point. I'll be quoting you as I keep pressing (nagging?) my daughters about the importance of using, and periodically changing, good passwords and being cautious on the internet.

More from Joe Kissel (from my previous post) on the password topic: How to remember passwords (and which ones you should).

thanks love joe kissell, corresponded with him once a while back about an ebook he wrote.
Ira, I still think my coded excel file is fine — I don't think the software is needed, but I'm not closed minded.

Joe, thanks again. I concur. I do have clones of PHotoshop, and maybe the old laptop is what they think is the 2nd. I can't deactivate that now, as I deleted the whole app off it!

I chatted with Adobe for 40 min with some guy from India probably. HE said he fixed the license, but still it did not work. He said he would send a case number in 5-10 min, after the chat, but never sent it. He said to call Adobe tech. I called and it was a 5 hour wait, so I'm still battling!

More Kissell security talk: When password security questions aren't secure.

thanks A, nice Kissel post.
He says you don't necessarily need upper/ lower/ symbols. He says if you just do a really long password with all lower case it could be great. So I thought, cool I'll test that.

So I googled for two sites.

This one says, Ijoggedtothestore is a great password, would take 8 million years for a computer to crack.
http://howsecureismypassword.net/

However,
this site does not say how long it would take a computer to crack (which is a good measure as that's how hackers crack passwords, right? ), but it says it's totally weak because it has all lowercase!
http://www.passwordmeter.com/

By way of comparison, here's here's what OS X's "Password Assistant" says, i.e. not very strong.

thanks Artie.
Where is password assistant? Don't see it in utilities.

So you think then that website which said it would take years... just delete that site, it's not accurate at all?

Navigate to /Apps/SysPrefs > Accounts, click on "Change Password," and click on the "key" icon adjacent to the "New Password" field to bring up Password Assistant.

I can't begin to do the math necessary to answer your second question, kevs, but I can see why a phrase such as you chose...intelligible English, all l. c. letters, and no gibberish, may be considered both strong and weak at the same time.

Personally, I'd pass on the Web site that says "strong."

Edit: Another comparison... Look what happens when you simply add a space between "I" and "jogged." (Like before, the math is beyond me.)

the is crazy.
this site, which I thought you would say is more accurate:
http://www.passwordmeter.com/

give a "weak" for ijoggedtothe store with the space!

Password assistant says its stronger than the one I just made that is much harder to remember and has upper and lower case and symbols.

But thanks for showing that assistant. If apple made it, it must be on the top of the tool list for this.

So should I stay with my 10 digit that is memorized and complex or just go with a short sententce (with a space) that is easy to remember and maybe 20 characters. I could come up with many sentences that are easy to remember.

also:
Funny I just opened cocktail, do it at beginning of each month. So now I have a long secure password instead of just enter key. But do I want that to be part of the keychain?

There's an XKCD about this, actually:

http://xkcd.com/936/

In essence, the all-lower-case password is in fact more secure than passwords of mixed cases, assuming the mixed-case password is shorter. Many people don't really understand password strength. It's assumed that mixed-case passwords are stronger than same-case passwords because mixed-case passwords add more variability.

But password strength can be measured in terms of 'information entropy,' the amount of randomness they contain. As a crude example, a password like 'aaaa' contains almost no entropy, whereas '3?/vdZ' contains high entropy. The greater the entropy, the harder it is to break a password, all other things being equal.

The "all other things being equal" part is important, of course. A high-entropy password that's very short is easy to crack; a low-entropy password that's 28 characters long is hard to crack. So cryptographers will talk about the number of bits of entropy a password has--that is, the total measure of possible randomness in the password. There's an equation you can use to determine the entropy in a password, which is in the Wikipedia article on the subject:

http://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_measure_of_password_strength

Password evaluation systems that just look for certain criteria (like "Does it have mixed case? Does it have numbers? Does it have punctuation?") will not necessarily give the same results as evaluation systems that calculate the entropy of the password.

Both your Wikipedia link and your explanation of how entropy enters into the password picture should help kevs understand things a bit better. (The XKCD link was posted earlier by Ira.)

You can get a bit of a "real-world" idea of how entropy works by playing around with OS X's Password Assistant and watching strength ratings change as you change length, characters used, etc, and, as opposed to kevs's linked Web sites, it's right on your own Mac.

You need to digest tacit's post to get a better understanding of password strength.

thanks Artie, Tacit.

Tacit, first, that article, xkcd, I did see that before, and I get nothing from it, so sloppy kid writing, what is it trying to say?

2nd- so should I ditch my 11 digit passwords, which has upper lower case and characters and it not easy to remember in any way, and just make a sentence, with spaces, like i went to the house and bought a car. (36 characters and easy to remember)


Lastly, should I check the keyword chain box on cocktail for my long important computer password? thanks!
It would seem that latter route is better to deal with in the long run no?

Essentially, the quick-and-dirty simplification is that you can figure out password strength by figuring out the possible number of combinations of the password; that's one measure of the password's "entropy" and therefore its strength.

Most places want you to have a password that is at least six characters long and prefer eight characters let's look at two cases: an eight-character password with a mix of upper and lowercase letters, numbers, and punctuation, and a password that is made up of four English words that are all lower case. Which is stronger?

There are 24 letters in the English alphabet. If we count upper and lower case as different, that's 48 possible letters. There are 10 digits and let's say 28 punctuation and special characters. Each character of our eight-character password can therefore be any one of 48+10+28 symbols, for 86 possible characters that can appear. Therefore, the total number of different passwords you cam make is 8 to the 86 power, or 4x10 to the 77th power combinations. A lot, to be sure.

Now let's consider the four-word password that's all lower case. The Oxford English Dictionary currently lists about 600,000 words. Most "abridged" dictionaries list about 200,000 words. If we choose four words from an abridged dictionary, the number of password combinations is 4 to the 200,000 power combinations, many, many, many times more possible combinations than the 8-character random password! Use 4 words selected randomly from the OED and it goes up to a number so large it's thousands of orders of magnitude greater than the number of atoms in the universe.

It's important to consider, though, that complete, meaningful English sentences are far less secure. Word combinations like "heavy today spirited bellicose" aren't meaningful sentences; when you limit the combinations to meaningful English phrases, like "big red cat toy," the number of possible combinations drops dramatically. You're far better off by choosing words at random than by making passwords that are meaningful sentences or phrases.

Tacit,
I can't figure out anything are you kidding me? I need those sites/ tools.

So which of those two website would you keep? and you like apples password assistant?

Dang, so you say don't use a random sentence like iwalkedmydogtothe park yesterday.

Even though Apples password assistant, and one of those two website says it a super strong password?

Lastly, should I check the keyword chain box on cocktail for my long important computer password?

xkcd, did not get that page at all.

1. I suspect that a large majority of users would, as opposed to searching dictionaries, simply draw on their own vocabularies to come up with their passwords, thereby severely limiting entropy (but making for more easily remembered and, of course, cracked passwords ).

2. Doesn't the "three strikes and you're out" rule followed by many, if not all, (e.g.) financial Web sites means that a hacker would have to crack a password in a non-secure location, i.e. your own machine?

Artie, did not understand #2.

Anyone— should I check the keyword chain box on cocktail for my long important computer password?

Do a YouTube search for "hack website" and you will find any number of tutorials on different techniques for hacking into a web site. Some of these tutorials are an hour or more in length so I didn't wade through all of them but from what I did see, "Three strikes" did not appear to be any obstacle at all.

Today's Diane Rehm Show on NPR discussed The Illusion Of Online Security, which you may find interesting as well as bewildering. Perhaps more importantly, you can find among the listener comments the link to Gibson Research's How big is your haystack? page. This deals with determining the time it takes a hacker to search for your password by trial and error etc., in which longer is better. That in turn tells you how best to construct passwords to suit your purposes. The approach used by Gibson complements what tacit mentioned above on the topic, and what the xkcd cartoon was all about. It may also help you understand why password strength meters/sites vary the way they do.

in 10.7 and 10.8 it won't let you create a new account with a blank password. but it will let you change it to blank later. blank as mentioned above will not work in terminal, but works with APIs and with applescripts "using administrator privileges" clause.

thanks Haystack link great! maybe better than those other two I found. I think that online article is reference more what happens when hackers find passwords or reset them as opposed to finding them from scratch.

Thanks. (I haven't checked YouTube yet...was hoping tacit would weigh in.)

On the other hand, a quick search turned up


which suggests that "three strikes and you're out" at least puts some sort of damper on a hacker's ability to crack a password.

Aside: I've been thinking for a while that this thread has taken a major turn from its initial direction and that a change of title, at the least, may be in order.

That only works if there is an "authentication authority" - a secure agent that is able to (1) verify the correct password has been provided, (2) provide the client with increased privileges to some resource provider as a result, and (3) is able to record and update information on the client's profile

If I dump your password file to a flash drive and take it home to my cluster, the security agent is completely out of the picture, specifically for (3). I can try as many password attempts I want to because the agent cannot count them and record my failures or delay password validation responses if I am obviously guessing.

That is why it's a problem when password lists are stolen, even when the passwords are hashed.

good point Artie, new title: Apple and password security or something like that.

1. Don't the "odds" on cracking a four word password decrease substantially if the words are attacked as just another alpha-numeric string?

2. Why is a meaningful phrase less secure than random words?

Thanks.

Thanks for the educated explanation of precisely what I was thinking, i.e. that nobody's going to crack my XYZ Bank password at XYZ's Website, rather it's got to be done in an unprotected environment.

(I'll still have to investigate joemike's referenced vids when I've got some time and inclination, though.)

The answer to your questions depends on the presence of prioritizing in dictionary attacks. If meaningful strings (read: actual words or sentences) are run first, followed (if at all) by the skipped strings that consist of a systematic series of permutations of the characters involved, hits with the latter will occur later (= after a larger number of trials). Of course, the issue of language plays a role too in selecting what's meaningful (= tried first) or not (tried later).

Then you have the issue of passwords you can remember. For example, if you choose an acronymized version of a sentence, you have a quasi-random string that likely gets tested 'later' in dictionary attacks, and is still memorable. Either way, the password variation you prefer is aimed at increasing the number of trials needed for a hit, and hence increases the security of your password. But ultimately, increasing computing power will reduce the time needed for a full analytic password attack of increasingly long strings, requiring more and longer passwords, and decreasing the possibility of memorable ones, however smartly composed. But as long as Virtual1's scenario of out-of-context (non-live) attacks cannot be used, you'll have more password leeway.

Thanks for a good explanation, but it invites some questions...

"hownowbrowncow" seems like it would be a simple target for a dictionary attack, but "how now brown cow" appears to throw a monkey wrench at the attack, with "how*now*brown*cow" compounding it and "how**now**brown**cow" further compounding it.

And "how**now**brown**cow**how**now**brown**cow" is an easily remembered string that seems like it would be a great password simply by virtue of its 42 character length.

The possibility of repeating strings to turn easily remembered ones into secure passwords has never been addressed, and I'm wondering whether it's as viable an approach as it appears to be?

In the end, a permutation run will eventually crack any password, and unless there's some math or attack theory that I've never run across or been run over by, any string, even a single character repeated enough times is may be a secure password.

And now you know why I didn't do very well with the statistics and probability courses I took.

A meaningful sentence is less secure than a random list of randomly-chosen words because the key space is smaller. There are fewer meaningful combinations of words than there are random combinations of words.

A hack attack does not have to be a brute force attack.

When most people think about hacking a password, they usually think of one of two things: either trying every possible combination of characters over and over again (a, then aa, then ab, then ac, and so on) or trying a dictionary attack (password, god, money, secret, letmein, sex, abc123, and so on). And both of those kinds of brute force attacks do sometimes get used.

But it's more common that a hacker will break into a Web site and steal the list of hashed passwords.

When passwords are stored on a server, they are stored as "hashes". Essentially, the Web site takes the password you entered, performs some mathematical operations on it, and then stores the result, which is called a "hash". (Note that I've simplified a little bit here, but what follows is basically correct.)

As an example (this is a hypothetical example only, and doesn't correspond to a real-world hashing function), when you create an account on a Web site, the Web site might:

1. Take the password you type in and add "andsosayweall" to the end of it. (Adding something to the end of a password is called "salting" the password, and helps protect against "rainbow table" hack attacks);

2. Take the first letter of the password, do a binary XOR of that and the second letter, take the result and do a binary AND of the third letter, take the result and do a binary NOT of the fourth letter, and save the result;

3. Repeat step 2 for the fifth, sixth, seventh, and eighth letter, and then repeat step 2 for the ninth, tenth, eleventh, and twelfth letter; and so on until the whole password has been processed;

4. Add up all the results from these operations; and

5. Store the result in the database with your user name.

The password itself is never stored in the database. Instead, only the hash is stored. When you log on to the Web site, the Web site takes the password you type in, adds "andsosayweall" to the end, hashes it, then compares the hash to the hash in the database. If they are the same, it lets you in. If they are not the same, it does not.

It is done this way so that if hackers break into the Web site and steal the database, they will have a list of usernames, but they WON'T have a list of passwords. They will only have a list of password HASHES. You can't take a hash and figure out the password from it.

But the fact that the passwords are hashed does give the hackers some leverage. What they can try to do is they can try to hash a lot of different words until they find a word that has a hash that matches one of the hashes in the database they stole. They are not trying to break into a single account; instead, they have a list of, say, 10,000,000 usernames and hashes, and they just keep doing different hashing techniques until they find a word whose hash matches something in the list. Then they have a password that matches one of the accounts in the list and they can break into that poor luckless schmoe's account. (Aha! We have a list of usernames and hashes. We see that one of the things in the list looks like

Tacit 377564783854687485

and when we do a hash of "LetMeIn" the result is 377564783854687485, so we know that Tacit is using LetMeIn as a password!)

Because the passwords are hashed, the security of the list of usernames and hashes rests a great deal on how complex and secure the hashing algorithm is. If the hashing algorithm is simple, it's easy to deduce what the password is. Also, some hashing algorithms might produce certain numbers if you feed them something like aaaaaaaaaaaaaaa as a password, which makes a password that's simple like that easy to spot in the list of hashes.

Some hackers will use "rainbow tables" to try to break a list of hashes. A rainbow table is kind of like a dictionary attack, sort of. It's an enormous list of common passwords that have been hashed using common hashing algorithms, so all the hacker has to do is compare the stolen database of usernames and hashed passwords with the hashes in his rainbow table and he can say "Aha! I just figured out 176,543,810 of the passwords in this list of five million accounts I stole!"

That's why Web sites will add some sequence of letters, like "sosayweall" or whatever, to the password that you type before it gets hashed. A rainbow table takes a huge amount of time even on a supercomputer to create. If you have a rainbow table of common passwords like "money" and "sex" and "love" and "letmein" and you steal a database where everything has been salted, the rainbow table is worthless because all the passwords on that Web site are actually "moneysosayweall" and "sexsosayweall" and "lovesosayweall" and "letmeinsosayweall" before they are hashed, so the hashes in the rainbow table won't match any of the hashes in the stolen database.

The various techniques used to create the hashes are pretty well known. Some techniques have security weaknesses that allow an attacker to look at a hash and be able to guess what combination of letters might have created that hash. Insecure hashes, passwords with lots of repeating characters (like "aaaaaaaaaa"), and hashes that are created without salt are often much easier to crack, just because of the mathematics of how the hashing works.

It is also possible that there might be hashing "collisions"--two different passwords that create the same hash. For example, because of the mathematics, a password like "IAmALittleGreenFrog" and "4vc?)bb%vs554xx@<,,nNb2z" might end up having exactly the same hash, just because the math that is used for the hashing produces the same result for both of those strings. That means either one of those passwords will work--the Web site thinks they are the same password!

Hashing algorithms that produce a lot collisions are weaker than hashing algorithms that are not. It is sometimes possible to study a hashing algorithm and be able to create a collision--a string that hashes the same way that the password you're trying to crack hashes--so as to engineer a break of the account by using a collision. This is how the Flame malware writers were able to send out their malware disguised as official Microsoft system updates; they created a collision of the hash that Microsoft used when Microsoft created their security certificate that they use to sign their real system updates.

Apologies for taking so long to respond to your excellent post ; it obviously took some time and effort and deserved better. (I'm amazed that nobody else has responded in the interim.)

Looking back on this thread and thinking back on similar ones, I'm struck by the fact that considerable time has been devoted to in-depth discussion of defenses, i.e. strength of passwords, while virtually none has been spent discussing threats, i.e. hackers, who, heretofore, have been no more than nebulous bogeymen...real, but nonetheless vague, threats.

So thanks for both explaining what hackers actually do and giving me some insight into what the strength of my passwords actually means in real-world terms...kinda, sorta, more or less, anyhow.

> It is sometimes possible to study a hashing algorithm and be able to create a collision--a string that hashes the same way that the password you're trying to crack hashes--so as to engineer a break of the account by using a collision. This is how the Flame malware writers were able to send out their malware disguised as official Microsoft system updates; they created a collision of the hash that Microsoft used when Microsoft created their security certificate that they use to sign their real system updates.

But how did the Flame writers know what the algorithm and Microsoft's hash were?

> "Aha! I just figured out 176,543,810 of the passwords in this list of five million accounts I stole!"

Remarkable! You're in the wrong business.

Thanks, again.

In the case of the Flame malware, Microsoft was using a code-signing security certificate that was well known.

The way a code-signing certificate works is that it creates a hash value from a computer program. Then it encrypts this hash using the private encryption key of a private key/public key encryption system. The public key and the method for creating the hash are distributed along with the program.

When you run the program, the computer uses the public key to decrypt the encrypted hash. Then it creates its own hash of the program. Then it compares the two, the hash it created with the hash that was included with the program. If they are not the same, that means the program has been tampered with, and the computer refuses to run it.

The hash is encrypted to prevent bad guys from modifying the program and then just attaching a new hash to it. You can't attach a new hash unless you know Microsoft's private encryption key. (In private key/public key encryption, you use one password to encrypt something. A different password is used to decrypt it. You can tell the whole world what the decryption password is; it can only be used to decrypt something, it can not be used to encrypt it.)

The Flame malware writers used some extremely clever and complex math to analyze Microsoft's hashing routine and find weaknesses in it. Using that analysis, they were able to figure out how to create hash collisions. So they could tamper with a program, then add stuff at the end to make a hash collision, so that the hash of the maliciously modified program was the same as the hash for the unmodified program. They could not create a new hash, but they could perform modifications and then engineer a hash collision so that the modified program had the same hash.

I've seen that technique before used on email. Someone had a way to take a certain kind of signed email and modify it, then they had found a way to add garbage to the end of the message in such a way that either the original signature still worked, or they could generate a valid signature (don't recall which)

Of course the recipient would see the garbage, whereas a computer ignores junk at the end of an app. Maybe this was some variation on that.

Yep, adding garbage to the end of an email is an attempt to create a hash collision so that the original signature still works.

Wow!!!

You may hate hackers, but you've got to give them some respect.

I've read at least one post, probably yours, that discussed the public/private key system, but I don't remember it being a real object lesson.

Your recent post puts the whole thing into perspective.

Thanks.

They are almost certainly the most highly paid software developers in the world often earning well into the 7 figure range a year. They earn far more than those who are attempting to block them. I give them the same "respect" I would give a madman in control of a very large thermonuclear weapon planted in the midst of Manhattan.

You're comparing apples and brussels sprouts.

I, too, would despise your madman, same as I despise hackers, but if he cobbled up the bomb in his basement I'd give him them same respect I give them hackers, despite his despicable intentions.

I just wanted to add one little bit to tacit's explanation of signing. It's necessary for the public key of the signature to already be in your system or user keychains as a trusted source. It is the 'root' (aka 'root certificate') from which signatures can be verified.

If you receive something like a java applet on a web page that is signed using a key that is not in any of your keychains, the verification will NOT occur transparently, and you should get a popup saying it's signed by an untrusted source, do you want to run it anyway?

The public key itself in the signature isn't used to generate the verification hash. The public key is specified in the signature by "name" so to speak, and that is looked up in your keychain, to insure you are using the public key cryptography data from your keychain, not just whatever happens to be in the signature. The signature has the crypto in it, it's just not used. Unless you tell it to run anyway and "always trust", at which point it's imported into your keychain for later automatic use.

Security settings in latter OS X can be set to more "strict", such that they don't allow running of software that isn't signed, or is signed by something not in your keychain. (there's no "run it anyway / always trust this signature" option given when you access it)

Thanks for the additional info.

I've got these two certificates in my keychain:

1. com.apple.systemdefault - "This root certificate is not trusted"

2. Dashboard Advisory - "This certificate was signed by an unknown authority" (It appears to be Apple Computer, Inc.)"

Any idea what they are, what they mean, from whence they came, or, more important, whether they put me at risk in any way?

Thanks.

I see several system certificates that aren't trusted. I don't know what they're used for specifically. It's possible they are used internally for signing configurations or something like that. Since the signing and verifying are occurring on the same computer, a chain of trust isn't useful. (the content isn't originating outside the system, so if it were compromised, being signed or not isn't helpful because the key signing ability is locally available)

The details on the certificates can be a little daunting, but look at their "key usage". The ssh keys you've accepted can "encrypt, verify, wrap". Those are public keys only. But my email key can "Verify, Wrap, Derive", the derive means it can DEcrypt.

I think certificates can only encode and verify, not derive. So the ones you were look at can only encrypt and verify signatures, they cannot sign.

If I had to wager, I'd say that the private key (that can decrypt and sign) is embedded in security apps within the kernel. So the kernel can sign things (such as if it makes a change to a signed component of itself) and other insecure system components can verify it using that certificate.

It could be insecure though. If something modified a kernel module, signed it with its own key, and replaced this untrusted certificate, the module would pass the check. but then every other module in the kernel would fail it, so it would have to re-sign everything under the hood. And if the kernel changed anything and re-signed, that would immediately fail verification too. So although it could be a security problem, it would be difficult to pull off.

Something like that. Take for example the com.apple.systemdefault certificate in System.keychain. That's created as a self-signed root certificate as part of system installation. Its purpose is to the authoritative certificate for the concept of "this computer". The system uses it to sign/encrypt information that has no use or validity on any other computer in the world.

For a case in point, consider an un-code-signed application that decides to store information in the keychain. By default, that application and no other is allowed to retrieve that information. Some days later, some application goes to the keychain and says "Remember me? I'm the one app gave you that data a few days ago. I'd like it back now, please." How is the keychain to know it's really the same app?

Well, it does that by code-signing the application on the fly the first time it sees it. That means it builds a manifest listing all the components of the application and a message digest for each (MD5 or SHA1). Then it builds a message digest for the manifest, encrypts that digest with a private key, and stores the result in the keychain as the "official" name of the application. Included in the manifest is the "public" part of the certificate used to sign it. (That is, the certificate minus the private key that was actually used to do the encryption.)

When the application wants access again, the keychain finds the manifest, verifies that all the components that are still present have the same digest, all the required components are present, and recomputes the digest of the manifest. It also decrypts the saved signature using the public key from the signing certificate, and verifies that those two digests match.

But which certificate is used to do this validation? Had the application been code-signed, the vendor would have bundled with the application their own certificate (minus its private key) and a precomputed and pre-signed manifest. For applications that haven't been code-signed, the system uses com.apple.systemdefault to build the ad-hoc code signature, and to validate it later.

If anything happens to com.apple.systemdefault, keychain will start bugging the user each time a non-code-signed app tries to use it. As the user individually OKs access for each ap, it'll be signed anew by the new com.apple.systemdefault.

I'm sure there are other uses for this certificate. The ability to authoritatively state "this was done on this machine and nowhere else" is too powerful to have only found one use. ("This machine" really means "this instance of an installation of OS X. The certificate is surely preserved in clones and across software updates, which are arguably the same computer, even if on different hardware running different software. But an erase-and-install produces a "different" computer, even on the same hardware.)

Thanks for that; I think I actually understand some of it.

com.apple.sytemdefault, a key, is ID'd as a "Self-signed root certificate" and can encrypt, verify, and wrap.

Dashboard Advisory is a certificate. (It seems to be Apple generated, so I wonder why it "was signed by an unknown authority?")

Thanks for the clarification.

> Take for example the com.apple.systemdefault certificate in System.keychain. That's created as a self-signed root certificate as part of system installation. Its purpose is to the authoritative certificate for the concept of "this computer". The system uses it to sign/encrypt information that has no use or validity on any other computer in the world.

But why is a "self-signed" key "not trusted?" (If it's of any significance, this is on a 10 day old clean installation.)

Thanks

Maybe there's no point. What are you going to sign it with? So you make a cert to sign it with. But now THAT is untrusted. So what will you sign THAT with? Any certificate that's made locally can't be trusted automatically because either the private key that signed it is available, or it's not signed.

Thanks.

That makes sense, but it doesn't make that "Untrusted" label any less disconcerting.

> either the private key that signed it is available, or it's not signed.

I assume you meant unavailable there?

A self-signed key is not trusted because anyone and any computer can create one. A trusted key is one that is signed by a trusted certificate authority; a certificate authority is supposed to have some positive means of identifying the person or business who created the key, so that (for example) if the key is used to sign malware, the authorities know who dunnit.

It's not always as reliable as it should be. On several occasions, Comodo, a well-known CA trusted by nearly every browser and computer, has been tricked into creating keys for Russian organized crime which have been used to sign malware. (I once saw a copy of the W32/Zlob malware signed by a key issued to "Mistland Ltd," which is the name of a legitimate real estate agency in London. It seems that Russian organized crime somehow tricked Comodo into believing that they were representitaves of Mistland Ltd. and needed a code-signing key.)

Thanks for kicking in; this discussion has been pretty fascinating.

It's (only) almost amazing that hackers can still hack despite all the security in place.

There's a lot of money in it. Some of the most highly paid programmers in the world are employed as hackers by Eastern European organized crime. When you have enough money at stake, it's amazing what you can do...

If you're talking about com.apple.systemdefault, on my machine (running 10.8.2), it doesn't say that certificate is not trusted. It says "This certificate has not been verified by a third party."

Which is true.

But that doesn't mean it's not trusted. It's trusted on your machine, because it's on your machine, in your keychain, and marked there as trusted. It will not be trusted on any other machine.

Had it been signed by another certificate (and not revoked) it would be accepted on any other machine that accepted the signing certificate. But that's not what it's for. It's for saying "I made this signature, so I trust it, but I don't expect anyone else to."


I don't know what the deal is with Dashboard Advisory. I know what it's for, but I don't know why Apple didn't either put it in System Roots or sign it with something that is (like Apple Root CA).


If you're asking about self-signed certificates in general, they're born untrusted (because anyone can make one), and become trusted by explicit action. One way for a root certificate to become trusted is to be included in the System Roots keychain, which Apple populates as part of system installation. The chain of trust starts with Apple investigating the issuer, and deciding that they're a legitimate Certificate Authority (CA); and then you trust Apple by running their installer.

The other way to become trusted is through explicit interaction. For example, you can open a certificate and change the trust setting to "Always Trust". Or the System Installer can create the self-signed certificate and explicitly mark it trusted. Either way, such trust is established only in that keychain.

A non-root certificate (that is, one that is not self-signed) is valid if its signature can be verified by the signing certificate, if that can be found and is itself valid.

Any certificate, self-signed or not, can expire and/or be revoked. An expired certificate can still be marked trusted, overriding the expiration.

Thanks for that; this thread has become quite a resource, albeit an arcane one.

> If you're talking about com.apple.systemdefault, on my machine (running 10.8.2), it doesn't say that certificate is not trusted. It says "This certificate has not been verified by a third party."

I guess Apple has changed its nomenclature...perhaps because of the very confusion with which we're dealing here?

Nope, I said what I meant. If the system has signed it, the key MUST be available locally, for the system to use.

Oh! Got it. Thanks.

It may be of interest to know that a lively discussion on the topic of passwords and their resistance to cracking developed in the MacInTouch Reader Report on Security-Passwords the last few days. Among the many interesting tidbits brought up there is a link about Password Recovery Speeds as a function of character set used for the password and the class of attack used by the cracker.

Thanks for the interesting links.

Apropos, I recently tried to change my Vanguard password and discovered that they had apparently truncated my old one; needless to say, I wasn't pleased.

truncation is unfortunately common. VNC for example. Assign as long of a vnc password as you like for remote desktop. First 8 chars (with anything added) will connect you.

I'm not as angry about discovering the truncation as by the fact that what had been an acceptably long password became an unacceptably long one without my having been notified; it was, in effect, unilaterally changed by Vanguard.

I have run across several financial sites where passwords of any length are accepted but only the first 8 characters are significant. In fact I recall many years ago one site was quite open in suggesting you use some phrase of length n but only the first m characters would be significant. That goes back to password rules the site established many years ago when 8 character passwords were the standard and has remained unchanged to avoid requiring many thousands of established customers to change their password.

What you describe here is password truncation, another topic discussed in the MacInTouch link I gave above. The problem with password truncation is that there are sites whose verification systems don't truncate passwords upon return like they did when the password was originally entered. That means that your original password may be denied without you knowing why, in this case because it's 'too long'. You'd have to guess it was truncated, and by how many characters.

After doing some checking and thinking, I realized that what probably happened was I wasn't paying full attention and entered a longer password than was permissible, but instead of flagging it, Vanguard accepted it but only registered the first n characters, and I never realized what had happened until I tried to change it at a later date.

That's a hell of a way to protect customers' security... Allow them to think they've established secure passwords when, in fact, they haven't.