With passwords you are absolutely correct. Direct root login is stupid, wrong and insecure and people leaving it should be shot.
With public key authentication for remote access + plain passwords on the machine itself you are not correct. There is no significant difference between giving direct ~/.ssh/authorized_keys based root to all the people entitled to root and giving them access with per user ~./ssh/authorized_keys and su/sudo. The simple password is inherently less secure authentication method compared to PKI and just bolting a password on the back does not do a thing. If you could tightly couple passwords with ssh PKI that will be a different matter. Same if you use one-time passwords after the login. This unfortunately requires tightly coupling all ssh authentication methods with the system ones as well as coupling ssh authentication with system authorisation.
As far as linux is concerned this requires Theo to stop his knee jerk reactions to PAM and integrate ssh and PAM properly.
By the way I agree with him that PAM sucks, but as far as having cross-platform and cross-distribution security framework we got nothing better. And no, I do not want to hear about keynote or COPS. Nobody in his sane mind wants to.
Not enough time to reach new equilibrium in a large aquatic ecosystem by all means. It took 30+ years for the Elodea plague to settle and European riverways to reach new equilibrium in the 19th century. In the places where a boat could not move like the river Cam you cannot see a single plant now.
Similarly, the algae blooms in the black sea with the Yellow Sea algae strains took nearly 20 years to settle (and are in fact still settling, though there is obvious improvement compared to the 1980-es).
That was my first reaction as well. If you are using ssh, passwords are "the wrong idea" (TM). A password is guessable while a private key is not. That is the way it is designed.
Not that it would have helped in this case though. The attacker compromised the developer machine first and from there on compromised the server. Once you are in full control of a user machine it is game over as far as any resources it accesses are concerned.
While at it, I can also understand an admin on a large linux shell machine which still allows passwords.
Due to Theo and Co's knee jerk (hello Theo) attitude to non-OpenBSD OSes there is no way to make ssh public key authentication plug cleanly in the OS authentication chain. The reason is that ssh continues to be developed from the perspective "PAM sucks, we here do not do that". That is a purely political OpenBSD position which belongs to the realm of OpenBSD and should have nothing to do with OpenSSH. If OpenSSH is to really support linux without "OpenBSD is better TM)" being involved it will have to support PAM properly, natively, all the way and for all authentication methods including public keys. This is the way of the land.
As this is not the case yet, if you want to limit access to public key only you have to turn off PAM for ssh. Alternatively, if you manage a big machine (or network) and you need PAM you end up turning on passwords and praying.
You have to take into account the size of the ecosystem as well. The smaller it is, the lower the "elasticity". Small, closed environments like lakes, islands, separated habitats with uniquely evolved life forms are quite prone to extinction events. There are plenty of examples like the New Zeland prehistoric giant eagle, Moa, the Dodo on Mauritius, so on so fourth. Once again, these are all relatively small ecosystems where the initial expansion can cause full extinction.
A large ecosystem the size of the Arctic + North Atlantic has sufficient "elasticity" to absorb the initial impact and reach a new equilibrium. Even a much smaller ecosystems like the Black Sea, the Nile, etc have absorbed events like this so there is a fair chance that the Arctic will.
It will be the same old story as the Black Sea and the Rapana sea snail in the 1970-es. Or the Elodea water weed and the european riverways in the late 19th century. These were thought to be the doom of all sea and water life respectively. It did not happen.
Initially introduced species thrive and go through a growth explosion. After some time their growth drops and they stabilise at some level or even die out to a near extinction. There are multiple reasons for this. First of all nearly all introductions are done with a limited gene pool. If fresh blood is not introduced, problems from inbreeding will quickly erode the invaders advantage. For example the Rapana when introduced in the early 1970s in the Black Sea seamed invinsible. By mid 1990 it nearly disappeared.
Even if the invader "vitality" is not lowered by inbreeding, the ecosystem still balances itself. Diseases adapt to new targets. Predators adapt to new victims. Life goes on until a new equilibrium is reached. End of the day invaders usually wipe out only species with which they are in a direct competition and which occupy the same ecological niche. Off the top of my head I cannot think of anything which occupies the same niche in the Arctic. Further south they will have to fight it with the common lobster. This will definitely suffer.
Dunno, I have seen two such "doom" events in the Black Sea with the introduction of Rapana and Yellow Sea algae and they both came to pass. So will this if we do not poke it at the same time.
It has yet to shoot down anything Hezbollah and Hamas are trhowing at Israel. The Catushas and artillery shells keep landing in Northern Israel and the rockets keep landing in the South.
When I see it working there, I will believe it being deployable somewhere else. As it is said: eat ya own dogfood.
You must carry your identity card at all times and show to all policemen when requested.
What goes around comes around. And in the words of Propellerheads as sung with Shirley Bassey:
The newspapers shout a new style is growing,
but it don't know if it's coming or going,
there is fashion, there is fad
some is good, some is bad
and the joke is rather sad,
that its all just a little bit of history repeating
.. just little bits of history repeating
.. and I've seen it before
.. and I'll see it again
.. yes I've seen it before
.. just little bits of history repeating
This is a repeat of what was going on in the UK, US and USSRin the late 40-es and early 50-es when they had the idea that they fight a nuclear war and win it. There were casual tests of mass broadcast systems, nuclear fallout shelters being built, contingency procedures put in place, etc.
This illusion soon faded as it became clear that there will be no winners and no losers if a nuclear conflict really breaks out. So the silly exercises stopped. First in the US and UK. USSR stopped a bit later around Hrushev's time.
I guess I remember wrong. I swear that I remember quite a few diagrams showing its structure floating around in the days before I degenerated into a sysadmin/network person. Either my memory is playing tricks or that was based on other methods.
The fine is as per old fine rules which caps it at 10% of annual turnover per year of misconduct which will be unpleasant for Microsoft, but can be sustained for a very long time. Even the disobedience fine is only 50% of the period of breaking the rules after the ruling which is painfull, but not lethal.
Unfortunately the commission cannot apply the new rules which set a cap for the fine at 30% of backdated turnover and 100% of turnover past the violation. Now that level of fine would simply put any company out of business so even serial offenders like MSFT will have to sit up and notice.
Re:I bet these will have the same problem as CD-RW
on
Bacterial DVD Holds 50TB
·
· Score: 2, Informative
Rhodopsin is a very interesting protein.
It was a favourite model of protein scientists in the 80-es because it is one of the very few proteins that will easily form crystals. It is also extremely stable (for a protein) in its non-excited form. So if any photosensitive protein is ever used for storage it is possibly the best candidate.
I work for one of the largest PKIs in existence, and let me tell you--users don't "get" certificates.. Cool. While I do not work on your scale I actually write web systems which use PKI/two factor authentication and some of the CA behind them. Amidst many other things. And as far as users "getting" certificates I agree with you. Every time I do a system that is based on PKI idiotic luser behaviour is the first and foremost problem to take in consideration.
You give them these instructions and they're just gonna fsck it up. Users will always do that. They are users after all. Users will repeatedly write their PINs in notepad and put it on the machine in a well titled note for everyone to find, users will chose easily guessable passphrases. Users will... There is nothing you can do about that and if we compare the relatively weak protection offered by certificates with the effectively no protection offered by password schemes I would rather take the certificate protection (even in software) and run.
The only answer is hardware tokens. Agree. And you know what, here the fun will really begin when MSFT rolls out Vista if they do not fuck it up. If they use the TPM which they require for it any machine will effectively be a hardware token in itself. Linux already has some support, it will be interesting to watch as it filters down to the userland and distributions.
The standards are confusing, the implementations mutually incompatible, Windows does one thing and Mac does something else and Linux something that looks like what the Mac does but not really... I am with you:-) You forgot Java which does a different thing in every release and any crypto code needs to be rewritten when moving to the new latest and greatest and end of the day you end up calling external OS-specific proxies or using JNI if you want it to work.
Human-computer interfaces in the security realm in general and PKI in particular suck large bricks through glass pipettes, sideways.. I am taking this in my descriptive dictionary. I LIKE IT. Are you a fellow ex-chemist by any chance?
While I agree with you as far as "bulletproof" gov grade and corp grade PKI is concerned I would like to come back to the original subject of the article. It is Phishing and MIM for Web based banking interfaces. That can be defeated by simple client side certificates stored in software stores with weak protection. Even if John Doe keeps fucking the up royally it is still better than any of the virtual keyboard, selective pin entry or two factor auth scheme on the market. It definitely solves the attack described in the article as well as most phishing attacks out there at the moment.
While I agree with you that PKI implementations have plenty of rough edges all over the place, they are mature enough and supported enough in all OSes in question for this relatively simple use.
Under Windows the certificate is imported into your user profile and only you can have access to the private key if you supply correct windows credentials followed (optionally) by correct credentials to the certificate store. So presenting the certificate and successfully handshaking using the private key for it requires the machine and the certificate store to authenticate you correctly. So as a matter of fact you are identificated, authenticated and must have correct credentials. Just the point of authentication has moved to your machine. It is also reasonably tamper resistant. Even for the default software certificate store is encrypted and you cannot do a lot by lifting it off the machine via a trojan. In addition to that newer hardware may have hardware certificate stores. Modern DRM is certificate based so DRM capable machines can also securely store certificates (though Windows does not use it this way yet). Similarly, you can also plug external tokens which store in a tamperproof manner the private key in this mechanism. In all cases just having the passphrase is usually not enough to use the certificate, you have to have full control of the machine operating under correct credentials and may even need a crypto module plugged into it at that moment
Under Linux and other OSes the process is similar. You have to have correct credentials at OS level to access the certificate store (the global certificate stores are never used for web authentication). From there on the user has to unlock the certificate store in use (konq or mozilla) with correct credentials. Same process as Windows just not so entrenched into the OS guts and more at an application level.
From there on, once you have supplied correct credentials, the certificate private key is unlocked what the server authenticates is a machine. It knows that on machine X the user has supplied the correct passphrase to the private key for certificate Y. At this moment it needs to ask for username and do a two factor authentication matching the certificate to the username.
Overall - it is not just the public part of the certificate which plays in the process. Private key is essential as well and handshake will not complete if the luser does not have the right private key. The server authenticates you by being the person in access to the private key which by default is protected by passphrase (f.e. Windows will not even allow you to export it or import it without one).
If you have taken the certificate out of the store, attached a passphrase on a sticker to it and disseminated this across the net there is little one can do. Though first of all this is a tall order technically for John Doe, second this is not much different from sending you PIN to the entire AOL.
In fact five years is an absolute maximum. More likely two years or so and the inevitable depression and disillusion set in in everyone but people who are clinically insane. Once this has happened the productivity goes down the drain.
In addition to that hiring mechanisms like this set a social immaturity requirement for most new recruits, because most socially mature people do not "burn in the job", read the "small print" and ask questions. The percentage of available workforce who are socially immature varies greatly based on industry and region. The highest percentage is in the computing industry in the US and Canada. Western Europe is considerably more cynical and settled and the cynicism of Eastern Europe cannot be matched by anyone. If you apply a hiring policy like this you might as well put a sign on the door "Russians and dogs not allowed".
Further to that as far as the content of the article is concerned the prevalence of social immaturity differs across industries. Based on my own experience biotech is more cynical then computers and chemistry is even more cynical then biotech. So I do not quite see Jobs running that hiring policy in a chemical company for example. There will be no starry eyed graduates ready for a mental rape and disposal.
Personally, I would much rather work with mature people who work because they are responsible and who can cynically evaluate what are they doing. I also avoid companies who run the "we have no lives but our job" as a matter of policy. The reason is that they are operated by three kind of people.
A small number is run by CEOs which live by the same rules and "eat their own dogfood". No thanks, I would rather have someone doing sound business decisions with a fresh head instead of using emotions while tired from not sleeping for the last 72 hours and hiper from 2 liters of mountain dew. There are not many of these. They do not last.
The majority of CEOs with this hiring style are actually cold blooded opportunists that deliberately hire socially immature people because they can exploit them, use them and throw them away as disposables in 2 years time. They also do it in their interest and the interest of their shareholders without actually enjoying it.
There is also a third category which is the worst. These are the sociopaths which enjoy the mental rape through disillusionment which they force onto starry eyed university graduates and socially immature geeks. These are the worst. Essentially they have the same mindset and as a pedophile and get kicks from similar things. The only difference being that they have chosen a way to get them which is even encouraged by todays society. All I can say is - yuck. Lowlife.
Actually, if your provider doesn't even assign static IPs, you can't really use client certificates at all.
Bollocks.
I am speaking this as not just someone who uses one such system, but someone who has implemented 3 such systems and is in the process of writing a fourth one in my day job at the moment. I actually do this for a living (besides other things).
You are mistaking the specific convention introduced by Netscape with SSLv2 for web server certificates as an absolute and valid rule for all certificates. Only in web server certificates the CN has to be the Fully Qualified Domain Name.
Certificates used for authentication do not need to obey that rule. In fact, your Subject and CN can be any set of random data that makes sense only to your application and nothing else.
This is a very interesting item as far as globalisation is concerned because a number of countries where gambling is a major industry have filed a WTO case against the US for restricting free trade. More specifically it is related to stopping credit card payments to entities in these countries by Visa and MasterCard. Any congress intervention before the WTO proceedings are complete is putting the US on a deliberate collision course with the WTO.
Also, it is a classic case of double standard. Free trade which lines the pockets of an American corporation is OK. Free trade which cannot line the pockets of an American corporation and goes to other nations is not OK. And god forbid if it is against the beliefs of the taleban elders.
No, it's not an easy fix, it's a huge hassle. If the client-certificate is going to be on the user's computer, then the user can only bank from one computer. Export the certificate from the computer. Put the procedure in the help file of the web interface. If you have imported it without export rights first time, rerequest the certificate. Voila. If Bulgarian or Russian banks can do it dunno why a UK or US bank cannot.
Many people have multiple computers (desktop, laptop, spouse's PC, work PC, etc), will you issue client-certificates for all of these?. Why not? Provided that you require a match of user ID versus a set of allowed certificates in the server in the second stage that is not a problem. This will also allow you to get around Mozilla sillies which keeps certificate store indexed by subject.
And if the client-certificate is in the browser, then it can be read by rootkits & spyware. That is better then not protecting the handshake at all as it is now. In addition to that the security of the luser is now in the hands of the luser. I as a luser can buy an Alladin eToken off the web for 40 quid and load the certificate on it. From there on the spyware can go suck rotten eggz because the private key is on the fob and it does not have access to it.
you're going to use a token (smartcard or key fob), then you have interoperability problems with different browsers/operating systems for a full ssl client certificate. When I see a bank that gives a flying fuck about this I would believe in this as a reason. Further to this, nearly all fobs on the market cleanly interface either into Windows crypto API or in the Linux smartcard interface (dunno about Mac, but I bet that works as well). This is a non-reason.
The handheld tokens where you have to type a challenge & get a response don't implement a full ssl client certificate, and are subject to MITM attacks, as was described in the article. Correct. They are shite, but that is the shite most selfproclaimed security engineers in the banking industry insist on. Seen that many times. In fact all the time I was trying to explain the idea of client certificates to the cretin mentioned in my original post he kept blablablahing about RSAID tokens.
No particular reason for client certificates to fail to work once loaded in a non-MS client. I got the east-EU bank mentioned in my original post working correctly with konq and mozilla.
Now, smart cards are a different matter. Some of them are not supported under *nix and MacOS. If the card is supported you should still be in the game.
Similarly, requesting certificates may be a problem. Mozilla has some troubles with handling the certificate-request/certificate import sequence. So does konqueror. It also cannot load a certificate with the same Subject as an existing certificates into the cert store. This makes requesting certificates via an interface which in turn requires a certificate to authenticate a real pain.
In either case it can be made to work. May be a bit painfull and I understand banks which refuse to provide support for anything but IE for this purpose (f.e. because of the aforementioned mozilla cert request sillies). As long as they do not outright deny you the possibility to use something else by using IE only features in the UI I am OK with that. I can sit down once a year on a windows machine to renew the certificate while swearing at Mozilla people for indexing their store based on Subject, not subject+serialNo.
Overall it can be made to work and it solves 99% of all phishing outright. IMO it is criminal for the banks not to use that. No rocket science involved.
Nearly all US and UK Internet banking systems are susceptible to this.
There is an easy fix for this as well - client side certificates. I have an account with a bank in an ex-eastern European country and they use it. Many scandinavian banks use that as well (with the certificate on a token or a smartcard).
In order to authenticate the SSL handshake has to use both client side and server side certificates. After that the actual user id has to match the certificate one. A man in the middle cannot break through that because it will not have the private key from the user machine. From there on even if it can fake the bank interface to the user it cannot fake the user towards the bank. Game, set and match.
The only reason for US and UK banks not to use it is outright incompetence. I remember trying to explain the concept of client side SSL certificates to one of the cretins who have implemented a well known UK bank Internet banking security subsystem. He could not grasp the concept. By the way - he now works in the "risk" (that is the way they like calling this now) department of another well known UK bank.
1. I somehow doubt that there is enough cows even in Vermont to supply the manure needed for all the state residential power consumption. 2. There is one major problem with Biogas - it has a very high sulphur content. It will be interesting how did they get around this. 'cuse if they did not the environmental cost of this will be enormous.
I have had to help with a wheelbarrow when chucking one or two into a skip and it was pretty damn hard work. They were from the days when nearly all computing equipment was built to last through WW3.
I can think of very few people around me who have seen one actually in use.
Anyway, what goes around, comes around. Full circle.
So does Sodium Pentothal though sometimes there are decryption errors. If there is more time there is a guaranteed decryption scheme known as "heroin once a day for a week, followed no more heroin until you tell the key".
Slashdot Mirror
With passwords you are absolutely correct. Direct root login is stupid, wrong and insecure and people leaving it should be shot.
With public key authentication for remote access + plain passwords on the machine itself you are not correct. There is no significant difference between giving direct ~/.ssh/authorized_keys based root to all the people entitled to root and giving them access with per user ~./ssh/authorized_keys and su/sudo. The simple password is inherently less secure authentication method compared to PKI and just bolting a password on the back does not do a thing. If you could tightly couple passwords with ssh PKI that will be a different matter. Same if you use one-time passwords after the login. This unfortunately requires tightly coupling all ssh authentication methods with the system ones as well as coupling ssh authentication with system authorisation.
As far as linux is concerned this requires Theo to stop his knee jerk reactions to PAM and integrate ssh and PAM properly.
By the way I agree with him that PAM sucks, but as far as having cross-platform and cross-distribution security framework we got nothing better. And no, I do not want to hear about keynote or COPS. Nobody in his sane mind wants to.
2000, 6 years so far.
Not enough time to reach new equilibrium in a large aquatic ecosystem by all means. It took 30+ years for the Elodea plague to settle and European riverways to reach new equilibrium in the 19th century. In the places where a boat could not move like the river Cam you cannot see a single plant now.
Similarly, the algae blooms in the black sea with the Yellow Sea algae strains took nearly 20 years to settle (and are in fact still settling, though there is obvious improvement compared to the 1980-es).
Give it some time.
Ahem.
That was my first reaction as well. If you are using ssh, passwords are "the wrong idea" (TM). A password is guessable while a private key is not. That is the way it is designed.
Not that it would have helped in this case though. The attacker compromised the developer machine first and from there on compromised the server. Once you are in full control of a user machine it is game over as far as any resources it accesses are concerned.
While at it, I can also understand an admin on a large linux shell machine which still allows passwords.
Due to Theo and Co's knee jerk (hello Theo) attitude to non-OpenBSD OSes there is no way to make ssh public key authentication plug cleanly in the OS authentication chain. The reason is that ssh continues to be developed from the perspective "PAM sucks, we here do not do that". That is a purely political OpenBSD position which belongs to the realm of OpenBSD and should have nothing to do with OpenSSH. If OpenSSH is to really support linux without "OpenBSD is better TM)" being involved it will have to support PAM properly, natively, all the way and for all authentication methods including public keys. This is the way of the land.
As this is not the case yet, if you want to limit access to public key only you have to turn off PAM for ssh. Alternatively, if you manage a big machine (or network) and you need PAM you end up turning on passwords and praying.
I did not express myself clear enough.
You have to take into account the size of the ecosystem as well. The smaller it is, the lower the "elasticity". Small, closed environments like lakes, islands, separated habitats with uniquely evolved life forms are quite prone to extinction events. There are plenty of examples like the New Zeland prehistoric giant eagle, Moa, the Dodo on Mauritius, so on so fourth. Once again, these are all relatively small ecosystems where the initial expansion can cause full extinction.
A large ecosystem the size of the Arctic + North Atlantic has sufficient "elasticity" to absorb the initial impact and reach a new equilibrium. Even a much smaller ecosystems like the Black Sea, the Nile, etc have absorbed events like this so there is a fair chance that the Arctic will.
It will be the same old story as the Black Sea and the Rapana sea snail in the 1970-es. Or the Elodea water weed and the european riverways in the late 19th century. These were thought to be the doom of all sea and water life respectively. It did not happen.
Initially introduced species thrive and go through a growth explosion. After some time their growth drops and they stabilise at some level or even die out to a near extinction. There are multiple reasons for this. First of all nearly all introductions are done with a limited gene pool. If fresh blood is not introduced, problems from inbreeding will quickly erode the invaders advantage. For example the Rapana when introduced in the early 1970s in the Black Sea seamed invinsible. By mid 1990 it nearly disappeared.
Even if the invader "vitality" is not lowered by inbreeding, the ecosystem still balances itself. Diseases adapt to new targets. Predators adapt to new victims. Life goes on until a new equilibrium is reached. End of the day invaders usually wipe out only species with which they are in a direct competition and which occupy the same ecological niche. Off the top of my head I cannot think of anything which occupies the same niche in the Arctic. Further south they will have to fight it with the common lobster. This will definitely suffer.
Dunno, I have seen two such "doom" events in the Black Sea with the introduction of Rapana and Yellow Sea algae and they both came to pass. So will this if we do not poke it at the same time.
Hate to be a devil advocate.
It has yet to shoot down anything Hezbollah and Hamas are trhowing at Israel. The Catushas and artillery shells keep landing in Northern Israel and the rockets keep landing in the South.
When I see it working there, I will believe it being deployable somewhere else. As it is said: eat ya own dogfood.
Yeah, a penis shaped sound wave slapping on the forehead everyone whose tax dollars have went for it.
Can be many things.
This is a machine to which nearly all debian developers have some form of access.
What goes around comes around. And in the words of Propellerheads as sung with Shirley Bassey:
The newspapers shout a new style is growing,
but it don't know if it's coming or going,
there is fashion, there is fad
some is good, some is bad
and the joke is rather sad,
that its all just a little bit of history repeating
.. just little bits of history repeating
.. and I've seen it before
.. and I'll see it again
.. yes I've seen it before
.. just little bits of history repeating
Here you are mistaken.
Go and ask your grandpa.
This is a repeat of what was going on in the UK, US and USSRin the late 40-es and early 50-es when they had the idea that they fight a nuclear war and win it. There were casual tests of mass broadcast systems, nuclear fallout shelters being built, contingency procedures put in place, etc.
This illusion soon faded as it became clear that there will be no winners and no losers if a nuclear conflict really breaks out. So the silly exercises stopped. First in the US and UK. USSR stopped a bit later around Hrushev's time.
Thanks for the correction.
I guess I remember wrong. I swear that I remember quite a few diagrams showing its structure floating around in the days before I degenerated into a sysadmin/network person. Either my memory is playing tricks or that was based on other methods.
The fine is as per old fine rules which caps it at 10% of annual turnover per year of misconduct which will be unpleasant for Microsoft, but can be sustained for a very long time. Even the disobedience fine is only 50% of the period of breaking the rules after the ruling which is painfull, but not lethal.
i ncrease/
Unfortunately the commission cannot apply the new rules which set a cap for the fine at 30% of backdated turnover and 100% of turnover past the violation. Now that level of fine would simply put any company out of business so even serial offenders like MSFT will have to sit up and notice.
For more info see here: http://www.theregister.co.uk/2006/06/28/ec_fines_
Rhodopsin is a very interesting protein.
It was a favourite model of protein scientists in the 80-es because it is one of the very few proteins that will easily form crystals. It is also extremely stable (for a protein) in its non-excited form. So if any photosensitive protein is ever used for storage it is possibly the best candidate.
While I agree with you as far as "bulletproof" gov grade and corp grade PKI is concerned I would like to come back to the original subject of the article. It is Phishing and MIM for Web based banking interfaces. That can be defeated by simple client side certificates stored in software stores with weak protection. Even if John Doe keeps fucking the up royally it is still better than any of the virtual keyboard, selective pin entry or two factor auth scheme on the market. It definitely solves the attack described in the article as well as most phishing attacks out there at the moment.
While I agree with you that PKI implementations have plenty of rough edges all over the place, they are mature enough and supported enough in all OSes in question for this relatively simple use.
You are not quite correct.
Under Windows the certificate is imported into your user profile and only you can have access to the private key if you supply correct windows credentials followed (optionally) by correct credentials to the certificate store. So presenting the certificate and successfully handshaking using the private key for it requires the machine and the certificate store to authenticate you correctly. So as a matter of fact you are identificated, authenticated and must have correct credentials. Just the point of authentication has moved to your machine. It is also reasonably tamper resistant. Even for the default software certificate store is encrypted and you cannot do a lot by lifting it off the machine via a trojan. In addition to that newer hardware may have hardware certificate stores. Modern DRM is certificate based so DRM capable machines can also securely store certificates (though Windows does not use it this way yet). Similarly, you can also plug external tokens which store in a tamperproof manner the private key in this mechanism. In all cases just having the passphrase is usually not enough to use the certificate, you have to have full control of the machine operating under correct credentials and may even need a crypto module plugged into it at that moment
Under Linux and other OSes the process is similar. You have to have correct credentials at OS level to access the certificate store (the global certificate stores are never used for web authentication). From there on the user has to unlock the certificate store in use (konq or mozilla) with correct credentials. Same process as Windows just not so entrenched into the OS guts and more at an application level.
From there on, once you have supplied correct credentials, the certificate private key is unlocked what the server authenticates is a machine. It knows that on machine X the user has supplied the correct passphrase to the private key for certificate Y. At this moment it needs to ask for username and do a two factor authentication matching the certificate to the username.
Overall - it is not just the public part of the certificate which plays in the process. Private key is essential as well and handshake will not complete if the luser does not have the right private key. The server authenticates you by being the person in access to the private key which by default is protected by passphrase (f.e. Windows will not even allow you to export it or import it without one).
If you have taken the certificate out of the store, attached a passphrase on a sticker to it and disseminated this across the net there is little one can do. Though first of all this is a tall order technically for John Doe, second this is not much different from sending you PIN to the entire AOL.
I will second that.
In fact five years is an absolute maximum. More likely two years or so and the inevitable depression and disillusion set in in everyone but people who are clinically insane. Once this has happened the productivity goes down the drain.
In addition to that hiring mechanisms like this set a social immaturity requirement for most new recruits, because most socially mature people do not "burn in the job", read the "small print" and ask questions. The percentage of available workforce who are socially immature varies greatly based on industry and region. The highest percentage is in the computing industry in the US and Canada. Western Europe is considerably more cynical and settled and the cynicism of Eastern Europe cannot be matched by anyone. If you apply a hiring policy like this you might as well put a sign on the door "Russians and dogs not allowed".
Further to that as far as the content of the article is concerned the prevalence of social immaturity differs across industries. Based on my own experience biotech is more cynical then computers and chemistry is even more cynical then biotech. So I do not quite see Jobs running that hiring policy in a chemical company for example. There will be no starry eyed graduates ready for a mental rape and disposal.
Personally, I would much rather work with mature people who work because they are responsible and who can cynically evaluate what are they doing. I also avoid companies who run the "we have no lives but our job" as a matter of policy. The reason is that they are operated by three kind of people.
Actually, if your provider doesn't even assign static IPs, you can't really use client certificates at all.
Bollocks.
I am speaking this as not just someone who uses one such system, but someone who has implemented 3 such systems and is in the process of writing a fourth one in my day job at the moment. I actually do this for a living (besides other things).
You are mistaking the specific convention introduced by Netscape with SSLv2 for web server certificates as an absolute and valid rule for all certificates. Only in web server certificates the CN has to be the Fully Qualified Domain Name.
Certificates used for authentication do not need to obey that rule. In fact, your Subject and CN can be any set of random data that makes sense only to your application and nothing else.
Idiots but for another reason.
This is a very interesting item as far as globalisation is concerned because a number of countries where gambling is a major industry have filed a WTO case against the US for restricting free trade. More specifically it is related to stopping credit card payments to entities in these countries by Visa and MasterCard. Any congress intervention before the WTO proceedings are complete is putting the US on a deliberate collision course with the WTO.
Also, it is a classic case of double standard. Free trade which lines the pockets of an American corporation is OK. Free trade which cannot line the pockets of an American corporation and goes to other nations is not OK. And god forbid if it is against the beliefs of the taleban elders.
No, it's not an easy fix, it's a huge hassle. If the client-certificate is going to be on the user's computer, then the user can only bank from one computer. Export the certificate from the computer. Put the procedure in the help file of the web interface. If you have imported it without export rights first time, rerequest the certificate. Voila. If Bulgarian or Russian banks can do it dunno why a UK or US bank cannot.
Many people have multiple computers (desktop, laptop, spouse's PC, work PC, etc), will you issue client-certificates for all of these?. Why not? Provided that you require a match of user ID versus a set of allowed certificates in the server in the second stage that is not a problem. This will also allow you to get around Mozilla sillies which keeps certificate store indexed by subject.
And if the client-certificate is in the browser, then it can be read by rootkits & spyware. That is better then not protecting the handshake at all as it is now. In addition to that the security of the luser is now in the hands of the luser. I as a luser can buy an Alladin eToken off the web for 40 quid and load the certificate on it. From there on the spyware can go suck rotten eggz because the private key is on the fob and it does not have access to it.
you're going to use a token (smartcard or key fob), then you have interoperability problems with different browsers/operating systems for a full ssl client certificate. When I see a bank that gives a flying fuck about this I would believe in this as a reason. Further to this, nearly all fobs on the market cleanly interface either into Windows crypto API or in the Linux smartcard interface (dunno about Mac, but I bet that works as well). This is a non-reason.
The handheld tokens where you have to type a challenge & get a response don't implement a full ssl client certificate, and are subject to MITM attacks, as was described in the article. Correct. They are shite, but that is the shite most selfproclaimed security engineers in the banking industry insist on. Seen that many times. In fact all the time I was trying to explain the idea of client certificates to the cretin mentioned in my original post he kept blablablahing about RSAID tokens.
No particular reason for client certificates to fail to work once loaded in a non-MS client. I got the east-EU bank mentioned in my original post working correctly with konq and mozilla.
Now, smart cards are a different matter. Some of them are not supported under *nix and MacOS. If the card is supported you should still be in the game.
Similarly, requesting certificates may be a problem. Mozilla has some troubles with handling the certificate-request/certificate import sequence. So does konqueror. It also cannot load a certificate with the same Subject as an existing certificates into the cert store. This makes requesting certificates via an interface which in turn requires a certificate to authenticate a real pain.
In either case it can be made to work. May be a bit painfull and I understand banks which refuse to provide support for anything but IE for this purpose (f.e. because of the aforementioned mozilla cert request sillies). As long as they do not outright deny you the possibility to use something else by using IE only features in the UI I am OK with that. I can sit down once a year on a windows machine to renew the certificate while swearing at Mozilla people for indexing their store based on Subject, not subject+serialNo.
Overall it can be made to work and it solves 99% of all phishing outright. IMO it is criminal for the banks not to use that. No rocket science involved.
Nearly all US and UK Internet banking systems are susceptible to this.
There is an easy fix for this as well - client side certificates. I have an account with a bank in an ex-eastern European country and they use it. Many scandinavian banks use that as well (with the certificate on a token or a smartcard).
In order to authenticate the SSL handshake has to use both client side and server side certificates. After that the actual user id has to match the certificate one. A man in the middle cannot break through that because it will not have the private key from the user machine. From there on even if it can fake the bank interface to the user it cannot fake the user towards the bank. Game, set and match.
The only reason for US and UK banks not to use it is outright incompetence. I remember trying to explain the concept of client side SSL certificates to one of the cretins who have implemented a well known UK bank Internet banking security subsystem. He could not grasp the concept. By the way - he now works in the "risk" (that is the way they like calling this now) department of another well known UK bank.
Two points:
1. I somehow doubt that there is enough cows even in Vermont to supply the manure needed for all the state residential power consumption.
2. There is one major problem with Biogas - it has a very high sulphur content. It will be interesting how did they get around this. 'cuse if they did not the environmental cost of this will be enormous.
Indeed.
I have seen the damn things only switched off.
I have had to help with a wheelbarrow when chucking one or two into a skip and it was pretty damn hard work. They were from the days when nearly all computing equipment was built to last through WW3.
I can think of very few people around me who have seen one actually in use.
Anyway, what goes around, comes around. Full circle.
That depends.
Many variables involved.
Quantity and quality of paint thinner sniffed this morning.
Quantity and quality of absint drank with coffee for breakfast
Quantity and quality of the dirt on the knife used to cut your year off causing a infection of the remaining stump
Quantity and quality...
Dunno, while I like Van Gough and I would not go for his methods of achieving artistic inspiration.
So does Sodium Pentothal though sometimes there are decryption errors. If there is more time there is a guaranteed decryption scheme known as "heroin once a day for a week, followed no more heroin until you tell the key".