An open community 
of Macintosh users,
for Macintosh users.

FineTunedMac Dashboard widget now available! Download Here

Previous Thread
Next Thread
Print Thread
Page 3 of 4 1 2 3 4
Re: Cocktail and Mountain
joemikeb #24403 12/11/12 09:45 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Thanks. (I haven't checked YouTube yet...was hoping tacit would weigh in.)

On the other hand, a quick search turned up

Originally Posted By: Wikipedia
The ability to crack passwords using computer programs is also a function of the number of possible passwords per second which can be checked. If a hash of the target password is available to the attacker, this number can be quite large. If not, the rate depends on whether the authentication software limits how often a password can be tried, either by time delays, CAPTCHAs, or forced lockouts after some number of failed attempts.

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.

Last edited by artie505; 12/11/12 09:48 AM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Cocktail and Mountain
artie505 #24407 12/11/12 09:32 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
Originally Posted By: artie505
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.


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.


I work for the Department of Redundancy Department
Re: Cocktail and Mountain
Virtual1 #24414 12/12/12 07:02 PM
Joined: Dec 2009
kevs Offline OP
OP Offline

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

Re: Cocktail and Mountain
tacit #24677 01/04/13 06:54 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Originally Posted By: tacit
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.

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.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Cocktail and Mountain
Virtual1 #24678 01/04/13 07:01 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
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 new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Cocktail and Mountain
artie505 #24683 01/04/13 03:53 PM
Joined: Aug 2009
Likes: 1
Moderator
Offline
Moderator

Joined: Aug 2009
Likes: 1
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.


alternaut moderator
Re: Cocktail and Mountain
alternaut #24688 01/05/13 08:11 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
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. grin

Last edited by artie505; 01/05/13 08:13 AM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Cocktail and Mountain
artie505 #24700 01/06/13 08:40 AM
Joined: Aug 2009
Likes: 1
Offline

Joined: Aug 2009
Likes: 1
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.


Photo gallery, all about me, and more: www.xeromag.com/franklin.html
Re: Cocktail and Mountain
tacit #25056 02/17/13 06:50 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
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. tongue

> 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. grin

Thanks, again. smile


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Cocktail and Mountain
artie505 #25073 02/18/13 07:34 PM
Joined: Aug 2009
Likes: 1
Offline

Joined: Aug 2009
Likes: 1
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.


Photo gallery, all about me, and more: www.xeromag.com/franklin.html
Re: Cocktail and Mountain
tacit #25075 02/18/13 09:58 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
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.


I work for the Department of Redundancy Department
Re: Cocktail and Mountain
Virtual1 #25076 02/18/13 10:35 PM
Joined: Aug 2009
Likes: 1
Offline

Joined: Aug 2009
Likes: 1
Yep, adding garbage to the end of an email is an attempt to create a hash collision so that the original signature still works.


Photo gallery, all about me, and more: www.xeromag.com/franklin.html
Re: Cocktail and Mountain
tacit #25117 02/22/13 11:21 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Originally Posted By: tacit
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.

Wow!!!

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

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. smile


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Cocktail and Mountain
artie505 #25120 02/22/13 04:37 PM
Joined: Aug 2009
Likes: 16
Moderator
Offline
Moderator

Joined: Aug 2009
Likes: 16
Originally Posted By: artie505
You may hate hackers, but you've got to give them some respect.

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.


If we knew what it was we were doing, it wouldn't be called research, would it?

— Albert Einstein
Re: Cocktail and Mountain
joemikeb #25121 02/22/13 07:51 PM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Originally Posted By: joemikeb
Originally Posted By: artie505
You may hate hackers, but you've got to give them some respect.

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.

Last edited by artie505; 02/22/13 08:46 PM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Cocktail and Mountain
kevs #25198 02/28/13 09:26 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
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)



I work for the Department of Redundancy Department
Re: Cocktail and Mountain
Virtual1 #25210 03/01/13 09:00 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
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.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Cocktail and Mountain
artie505 #25214 03/01/13 04:54 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
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.


I work for the Department of Redundancy Department
Re: Cocktail and Mountain
Virtual1 #25223 03/02/13 08:19 AM
Joined: Aug 2009
Offline

Joined: Aug 2009
Originally Posted By: Virtual1
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.


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.)

Re: Cocktail and Mountain
Virtual1 #25224 03/02/13 08:19 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
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?")


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Cocktail and Mountain
ganbustein #25225 03/02/13 08:28 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
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


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Cocktail and Mountain
artie505 #25227 03/02/13 01:23 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
Originally Posted By: artie505
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.


I work for the Department of Redundancy Department
Re: Cocktail and Mountain
Virtual1 #25233 03/02/13 05:24 PM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
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?


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Cocktail and Mountain
artie505 #25237 03/03/13 03:51 AM
Joined: Aug 2009
Likes: 1
Offline

Joined: Aug 2009
Likes: 1
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.)


Photo gallery, all about me, and more: www.xeromag.com/franklin.html
Re: Cocktail and Mountain
tacit #25239 03/03/13 04:00 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
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.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Page 3 of 4 1 2 3 4

Moderated by  alternaut, dianne, dkmarsh 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.4
(Release build 20200307)
Responsive Width:

PHP: 7.4.33 Page Time: 0.040s Queries: 65 (0.030s) Memory: 0.7323 MB (Peak: 0.9331 MB) Data Comp: Zlib Server Time: 2024-03-28 13:51:51 UTC
Valid HTML 5 and Valid CSS