FTA " Another sort of related problem commonly found in infrastructure security assessments is confusing features with vulnerabilities. Thus, a public road that travels close to the facility is often considered a Vulnerability. It is not, however; it is only an attribute. Only when coupled with an attack scenario (truck bomb, the road makes visual and electronic surveillance easier for espionage, assets can be thrown over the fence by insiders to the bad guy's parked truck, etc.) does a feature become a Vulnerability".
I'm not quite sure about the point the author is trying to make here: what's the purpose of differentiating between features/attributes and vulnerabilities? Is it only a vulnerability when it can be exploited? This is actually undermining the definitions the author uses for explaining the difference between threat and vulnerability: if a vulnerability can be "exploited by multiple adversaries having a range of motivations and interest in a lot of different assets", requiring attack scenarios to be specified before allowing an "attribute" to be called a vulnerability feels a bit unnecessary, and could even focus the attention too much onto one kind of attack. Incidentally, neither attribute nor attack scenario is defined anywhere in the paper, which makes the distinction being drawn here weird.
In my view, a vulnerability is a property of the system that allows an attack; there is a natural overlap between a vulnerability and an attack, but they do exist independently: it is sometimes interesting to think of vulnerabilities that have no known or feasible attack (e.g. crypto ciphers that are seen as weak do not necessarily have feasible attack scenarios). Requiring an attack scenario in order to classify a feature (or attribute) as a vulnerability seems unnecessary: why would you have described the attribute as a vulnerability if you didn't have an attack in mind already?
I think the problem with your statements in general is that he is portraying himself as an expert in one field and using said expertise in that field to, incorrectly, gain acceptance of his ideas in another field.
Of course he isn't -- he's presenting the results of research he's conducted on the topic of the psychology of IT security. I believe the target audience is not behavioural psychologists, but in fact security experts who don't realise the intricacies of the problem.
If you can show me evidence of where he's trying to "gain acceptance of his ideas in another field", then I may reconsider my position, but bearing in mind this presentation was to the RSA security conference, I strongly doubt there were many evolutionary biologists in attendance.
With that in mind, maybe my previous statements aren't all that irrelevant, but feel free to ignore them if you can't refute them.
I don't usually respond to negative posts, but this is something I feel quite strongly about:
1. You don't have to have a qualification in something to know enough to make an enlightened statement about a particular subject. If we were to restrict talking about the weather only to meteorologists, small talk would vanish overnight. In a more serious vein, interdisciplinary research would be even more difficult than it is now. Imagine having to have a qualification in both psychology and security to be able to publish research into this?
2. A qualification is simply a piece of paper that has been accredited by some educational body, presumably recognising a standard of education in a particular field. Just because you don't have the piece of paper doesn't mean you don't have the knowledge. How do you know that Bruce Schneier doesn't, in fact, know as much (or possibly more) about evolutionary biology or behavioural psychology than yourself? Does the fact that I haven't studied engineering preclude me from having insightful discussions with an engineer? Do my opinions matter less because I don't have the degree? Does the fact that I have a PhD in computer security (and you presumably don't) mean that any opinion I state on the subject is somehow more valid because I hold the qualification and you don't?
3. Bruce Schneier is eminently qualified to make statements about security (which is afterall a central aspect of his thesis). He has been conducting extensive research into psychological aspects of IT security (you can see a draft essay on the topic at http://www.schneier.com/essay-155.pdf). This research has included long discussions with psychologists and serious reviews of the literature. I would content that there are very few people on this planet that are truly as knowledgeable in both security and the psychology of security as Bruce Schneier is now. I would be equally interested in the views of a psychologist who undertook research into security -- I know only of a handful that have done so, and none have the particular angle that Schneier has adopted.
4. That is not to say that everything the Schneier is saying on the topic is faultless, or that I agree with everything he says, but I'll debate the ideas, not the man. I personally find it objectionable to anthropomorphise an evolutionary process, or talk about the intent of evolution. But what do I know, I don't have a degree in evolutionary biology...
Well there is a good reason why it's implemented as encrypt-decrypt-encrypt, but it's not for cryptographic strength. Instead this has its roots in the hardware backwards compatibility. That is to say that if you create an encrypt-decrypt-encrypt box and feed it the same key for all the crypto operations, you get plain DES encryption. (i.e. encrypt m with x = c, decrypt c with x = m, encrypt m with x = c). If you want proper 3 DES you just feed it different keys.
So instead of having to create a box that does plain DES and triple DES, you can get plain DES using the same algorithm as the triple DES -- cheaper for the hardware manufacturers.
I don't tend to be particularly picky, but talking about SSL as though it is an encryption algorithm is a tad inaccurate.
SSL is a protocol which can make use of a wide variety of different encryption algorithms in different manners. There's an asymmetric encryption element, mainly for authentication & session key exchange, and a symmetric encrpytion element for the secrecy of ongoing communications. Talk about "breaking SSL" is somewhat misleading -- I think talking about breaking RSA, Diffie-Hellman, DES or AES is much more precise, and meaningful.
Lets face it, if a quantum computer somehow arrives that can factor numbers bigger than 15 (current limit I believe), asymmetric encryption algorithms will be much more shaky, but that doesn't necessarily mean the end of symmetric encryption.
> Response to terrorism (from the IRA) was one of drivers of the UKs current propensity towards spying on its citizens
While I'm sure the IRA played a part in getting cameras in the UK, I strongly believe the biggest factor was the Jamie Bulger case where those two teenagers were caught on camera leading that little boy away from his mother. After that, anyone who raised a voice to oppose cameras was obviously opposing child protection...
Whilst from a cryptographic point of view this is rather interesting, I have a couple of serious doubts as to how well this kind of system might work in practice:
1. What happens if candidates claim the system is flawed? You can't conduct a recount in a crypto system such as this (and get a different answer) so in effect if someone manages to contest the election, it's now void.
2. The audit is based on a statistical sampling of the ballots (IIRC checking the link between the candidate list and the voting receipt is correct) -- in no way is the actual counting audited. This means that the outcome of an election is based on someone pushing a button and a *machine* spewing out a total. You simply cannot conduct a manual recount (you go and try to decrypt these numbers by hand!). In a perfect world the counting algorithm is ideal and doesn't make mistakes and is provable, in the real world the algorithm doing the counting might not be the same as the one in the perfect world... And the best you can do is get an expert to review the counting software, hardly an open and accountable process where anyone can volunteer...
Whilst I don't doubt that XSS can be used for other nefarious purposes, for XSS to work you have to "trick" someone into clicking a link with an embedded exploit in the URL.
I would say that this predisposes it very strongly towards the phishing crowd.
Out of interest, would you happen to know of any other types of attack that XSS might enable?
It's not quite like your example, although the principle is similar. The site isn't forwarded, it is the actual Paypal site that displays some rogue information, but it's because Paypal allows some script to be submitted as part of the URL and then (without checking it) executes it in one of their pages.
In this case I believe the script contains a notice that your account is locked and you need to visit some other (phishing) website to enable it again.
To answer your question, in short the attack doesn't work if you visit http://paypal.com/ manually.
What an attacker can do is craft a URL that *is* to paypal.com but contains the injected material (i.e. script) inside the URL. In short the paypal.com servers suffer from a vulnerability which allows the execution of this material (passed as an argument in the URL) -- and thus executes the script on the victim's browser. Because of this, the SSL connection is correct, but it appears that paypal is telling you that you need to go to another website to change your credentials.
You still have to get someone to click on the crafted URL for this to work though (hence why phishers are doing this, they're sending emails, or whatever.) so it's not going to work for people who don't click on the URL in phishing emails.
What I'm wondering is why someone would click on a link in a scam and then worry that the SSL certificate is genuine! Someone who knows enough to check the certificate is probably clever enough to ignore phishing scams...
I would like to point out an additional category: Cognometrics - something you recognise.
Whilst it could be argued that recognition is part of knowledge (i.e. something you know), there are fundamental differences between recall (uncued) and recognition (cued). The latter is invariably easier - simple example: do you think it's easier to answer a multiple choice question, or a question with no choices?
The importance of this point should not be underestimated since one of the biggest problems with authentication mechansims is their ease-of-use, and their dependability. Cognometrics are easier to use in general, although there have been relatively few trials on their practical application in the real world.
Incidentally if you want to know more I would recommend the book "Security and Usability" edited by Lorrie Cranor and Simson Garfinkel. Chapter 7 describes cognometrics and has much greater depth about the issues and strengths (one of the authors is Ross Anderson).
Firstly I should correct you in that he never stole an iPod - he stole a iPod DJ System and a iPod Speaker System. It may well be that these products are freely available on shelves. You are, however, correct in your assumption the he used cheaper yet valid barcodes. This link prints the police statement for the arrest.
Essentially the first time he commited the crime he bought a DJ System by using the barcode from a CD player (which he had scouted out previously). The second time he tried (and was caught) he replaced the barcode for an Altec Lansing iPod speaker system with a barcode for earphones. He got caught because he was recognised by the security firm following the first incident.
Actually you couldn't even "brute force" a single key because they're all one-time pads. Quantum "crypto" provides a means for two parties to securely agree on one time pads.
The only way brute forcing works is for an algorithm based encryption system with a given key. You try all the possible inputs of that key until the algorithm decrypts the text to something meaningful. With a one-time pad, the key is the same length as the encrypted text and each bit of the key is XORed to each bit of the cleartext. Since each bit of the key is completely random, assuming you correctly guess the first bit of the key there is no way for you to confirm your guess.
Essentially trying to brute force a OTP is completely pointless because you cannot know if something you decrypted as saying "the secret is X" might in reality be "meet me at noon" or "the secret is Y".
Actually I disagree with you. Not on the fact that WEP wasn't "broken" before, but on the fact that you say WEP is worse than useless.
Security is not an absolute, it is relative. Yes WEP is broken, worse than previously thought.
WEP, however bad it is (and however many better solutions exist) still stops most people
from using your bandwidth. Retail studies have shown that most staff theft is opportunistic - while most people are basically honest, if they see money lying around, most of them will pick it up. Same goes for unprotected bandwidth. Many people would not have a problem if it's completely open, but put even the semblance of a lock and they won't try to break in - that's because they have to actively be dishonest in order to steal your bandwidth/money, as opposed to ignorant.
So while it wasn't a perfect solution TM, it was actually better than nothing.
I'm not arguing that better solutions aren't available, but I am saying that WEP isn't as completely useless as you make it out to be.
What would you prefer no security or bad security? That's actually a trickier question than it sounds!
At least if I have policies in place, I can not get in the sh*t again.
Actually if you haven't read it yet, I would highly recommend you read the FIPSPUB112 since it is a federal policy guideline (and no it doesn't advocate using "password" or a 4 digit pin as your secret...)
The point is that you need to have the buy in from the top - which is what this policy describes. It sounds as though you were made a scapegoat (and I do sympathise) by someone who didn't know or do their job properly.
At least by having complex passwords that expire and must change, (Notice I did not say random charachters I preffer to have pass phrases, and instead of spaces, I reccomend special characters for example insecure-passwords&suck1) clean desk policy, security policies, and security trainning, for all my l-users my arse is now protected. Now someone has to try and bruteforce a password which would take an extremely long time, find a security exploit, or (IMHO the easiest way)social engineer the user.
While I do understand why you have this attitude, I reiterate that this is not actually improving your security - it's improving your cya (cover your a**).
I agree that social engineering is the easiest way to get the password, and ironically the 'draconian' approach to password management you advocate makes it easier to exploit this by fostering a culture in which people expect problems with their passwords. So in a sense you are making what most serious attackers would choose as the most effective 'hack' even more likely to succeed - ironic no?
I think I should also make myself a bit clearer, I'm not saying we need simple passwords that any cracker can break (which is obviously insecure), but I am saying that, for example, forcing people to change their passwords too regularly can cause problems (and it does depend on your users!). Most IT admin staff can happily cope with changing their passwords every month (and even then I expect many just increment the end of their password... anyway..), most non IT literate people can't cope. I'm not sure why, but passwords are scary things - on par with usernames I might add - which make the magic box allow them to do their work. They don't understand, or care, about why it's necessary for it to be hard to guess - only that it's a pain in the a**.
Educating the users (as opposed to only training them) is the only way of defeating this and one of the hardest problems to solve in computer security (IMHO). Educating bosses and management comes a close second...
That is why my organisation has implemeted password policies require at least 8 characters, at least 1 uppercase letter, 1 number, and one special character, or it will not let you change it, and will lock out your account. We then run security audits to ferret out the l-users like you that make them to simple. If we find a password that is to simple, or easy to crack, we force you to change it. If you do not, then your account will be locked out.
When I read this, I seriously started thinking this was great sarcasm.
Unfortunately I've since changed my mind.
There has been a lot of research in the area of password usability here is a short summary:
Fact 1: human memory is fallible
Fact 2: people cannot forget on demand
Fact 3: non meaningful things (i.e. random) are amongst the hardest things to remember
Fact 4: items in human memory interfere with each other making 100% recall very hard
Fact 5: unaided (no prompts) recall is much harder than providing prompts (which becomes a recognition exercise - passfaces is an interesting technology for example)
Fact 6: ambushing a user to change their passwords stops them from doing their work (which they get paid for) and encourages them to bypass the system as quickly as possible - i.e. write the password down
CONGRATULATIONS you are following rules which were laid out in the original FIPS guidelines (1985) for password management... Maybe you ought to revisit their document, they have updated it and it makes a LOT more sense now (check out FIPSPUB112)... I just wanted to let you know that pretty much everything you describe decreases the security of your organisation.
Actually I always thought the name came from the concept of power grids. i.e. plug in your application to the computing grid, get it to run your computations, and get the results without having to worry about how the computing power got to your home... Kind of similar to a power grid no? plug toaster, insert bread, get toast - no need to worry about coal/oil/nuclear fuel burning, transfomers or megawatts...
I have had some experience with grids and the overwhelming difficulties I've come across have been in the areas of security.
First and foremost, grids are designed to run in a distributed environment which makes security design and administration that much more complex.
Second, grids are currently in their infancy and there is little prior art to the types of attacks and problems that will affect them. Despite this, they are very juicy targets with the kind of storage and bandwidth that would make even a hard-bitten cracker weep for joy. (i apologise for the imagery)
Third, in my book security has to be a top-down approach - i.e. the guys on top lead the way and then everyone else follows. Grids have no tops or bottoms which makes this a bit tough to apply. In short there is no security hierarchy in a default grid environment. Responsibility HAS to be established explicitly. A simple example is who is responsible for the data held on one of the nodes? Is it the person who wrote the application, the person who owns the application, the person who owns the hardware?
Grids are fascinating in their security requirements (and those who think these are solved by web services have another thing coming! People are a huge aspect of the security of a system, and distributed system like grids have a very complex task of ensuring that people behave the way they should).
In my experience, I've come across what social scientists call "diffusion of responsibility" with regards to security. Basically it's the notion that if you are on your own and you come across a person having a heart attack you will do something, if you're in a crowd, people will just stand there frozen in the expectation that someone else will do something.
In security this has led to me witnessing a "it's not *my* problem" attitude or a "someone else is taking care of this".
Responsibility and authority are massively important in order for a system be secure.
Applying the point of the original post to the comment "security is everybody's responsibility" means that everyone who has a security responsibility should have a matching authority. i.e. if it comes down to someone deciding whether to comply with a security procedure or bypassing it to get the job done more quickly, then if that person is responsible for security, they should have the leeway to delay the job to take care of the security.
Likewise everyone who has a security authority (i.e. an ability to determine whether a security measure is applied or not - which is very frequent in the case of systems relying on their users changing their passwords, making manual backups, encrypting their emails etc.) should have a matching responsibility.
This ultimately means that security measures involving people should be very carefully judged, because if you give someone authority over your system you have to depend on them to behave in the right way, which means that they have to be: 1. able to do so (not too demanding, simple, doesn't conflict with other pressures, etc.) 2. willing to do so (motivation, responsibility, culturally acceptable - avoiding security can be a sign of seniority!!! how many managers actually comply with policy?!)
Thanks for your point about the panopticon - I must confess that I don't subscribe to that particular attitude about law enforcement. I also want to point out that I'm opposed to a government introducing biometric ids. I don't care if they introduce non biometric ids, because I don't see that as particularly harmful.
I would still like, however, to dispute your claim that biometrics will be 100% effective. My argument is based on the fact that unless they change their way of capturing your biometrics (as in store real copies of your dna, as opposed to structured snapshots) there will ALWAYS be uncertainty in any match. This is because biometric information is far too rich for a computer to process and therefore has to operate on a formal and restricted model of biometrics that is hoped/tested to be reasonably accurate. This restriction of the data set, together with imperfections of reading the biometric data (both at the initial enrollment, and at the subsequent checks) means that it WILL NOT be 100% effective.
How effective it can be is completely open to debate, and I'm saying that even if they achieve the 99.999% accuracy, this is *still* not enough for the purposes you describe. (This is one of the reasons why biometrics, as a means of identifying terrorists, is a specious argument).
In addition to this, biometric information in individuals can change. Fingerprints can be worn through labour or a nail file, you may injure your eye, or have laser treatment on your retina, and so on.
What will happen in the future is that these technologies will get more accurate, but I think it is highly debatable that in following their current principles they will get sufficiently accurate as to provide either benefits (as in identifying crooks - you never know;-) ) or avoid inconvenience over a population of several million.
Finally my point was that in order for the authorities to absolutely determine your identity *in the absence of other identification* (such as you giving your name, your id card, them following you, etc.) the computational requirements and the limitations of biometrics as they are (and as I've argued will be) simply make this a costly, inaccurate and rather ineffective means of identifying you based solely on some reading of your biometric information. At the end of the day it's far simpler for them to follow you home...
Interesting FACT... You do realise that they've got close to 10% error (false positive/false negative) rate going on - and that's knowing who they're trying to match against.
You are assuming that biometrics are 100% effective. If you are trying to identify someone without an identity to match against, this stops everything dead. Making a simplified calculation (which is probably an incorrect inference but it'll serve our purposes) if you take the 10% error rate, you'll have 10% of the whole database of positive matches (on top of a 10% chance that you won't even be in the results!!!). In a database of 60 million, that's 6 million. Not exactly pinpoint accuracy is it! (Even if biometrics become 99.999% accurate you'll still get 60000 matches... not very good is it!!!)
The carrying of the card is VITAL if they want to even try to enforce this.
Slashdot Mirror
I'm not quite sure about the point the author is trying to make here: what's the purpose of differentiating between features/attributes and vulnerabilities? Is it only a vulnerability when it can be exploited? This is actually undermining the definitions the author uses for explaining the difference between threat and vulnerability: if a vulnerability can be "exploited by multiple adversaries having a range of motivations and interest in a lot of different assets", requiring attack scenarios to be specified before allowing an "attribute" to be called a vulnerability feels a bit unnecessary, and could even focus the attention too much onto one kind of attack. Incidentally, neither attribute nor attack scenario is defined anywhere in the paper, which makes the distinction being drawn here weird.
In my view, a vulnerability is a property of the system that allows an attack; there is a natural overlap between a vulnerability and an attack, but they do exist independently: it is sometimes interesting to think of vulnerabilities that have no known or feasible attack (e.g. crypto ciphers that are seen as weak do not necessarily have feasible attack scenarios). Requiring an attack scenario in order to classify a feature (or attribute) as a vulnerability seems unnecessary: why would you have described the attribute as a vulnerability if you didn't have an attack in mind already?
Yes, it has happened before: http://news.bbc.co.uk/1/hi/world/asia-pacific/4396831.stm
If you are capable of reading what I wrote, you'll see a number of argued points, none of which you have even remotely attempted to answer.
I've wasted enough time on you.
Of course he isn't -- he's presenting the results of research he's conducted on the topic of the psychology of IT security. I believe the target audience is not behavioural psychologists, but in fact security experts who don't realise the intricacies of the problem.
If you can show me evidence of where he's trying to "gain acceptance of his ideas in another field", then I may reconsider my position, but bearing in mind this presentation was to the RSA security conference, I strongly doubt there were many evolutionary biologists in attendance.
With that in mind, maybe my previous statements aren't all that irrelevant, but feel free to ignore them if you can't refute them.
1. You don't have to have a qualification in something to know enough to make an enlightened statement about a particular subject. If we were to restrict talking about the weather only to meteorologists, small talk would vanish overnight. In a more serious vein, interdisciplinary research would be even more difficult than it is now. Imagine having to have a qualification in both psychology and security to be able to publish research into this?
2. A qualification is simply a piece of paper that has been accredited by some educational body, presumably recognising a standard of education in a particular field. Just because you don't have the piece of paper doesn't mean you don't have the knowledge. How do you know that Bruce Schneier doesn't, in fact, know as much (or possibly more) about evolutionary biology or behavioural psychology than yourself? Does the fact that I haven't studied engineering preclude me from having insightful discussions with an engineer? Do my opinions matter less because I don't have the degree? Does the fact that I have a PhD in computer security (and you presumably don't) mean that any opinion I state on the subject is somehow more valid because I hold the qualification and you don't?
3. Bruce Schneier is eminently qualified to make statements about security (which is afterall a central aspect of his thesis). He has been conducting extensive research into psychological aspects of IT security (you can see a draft essay on the topic at http://www.schneier.com/essay-155.pdf). This research has included long discussions with psychologists and serious reviews of the literature. I would content that there are very few people on this planet that are truly as knowledgeable in both security and the psychology of security as Bruce Schneier is now. I would be equally interested in the views of a psychologist who undertook research into security -- I know only of a handful that have done so, and none have the particular angle that Schneier has adopted.
4. That is not to say that everything the Schneier is saying on the topic is faultless, or that I agree with everything he says, but I'll debate the ideas, not the man. I personally find it objectionable to anthropomorphise an evolutionary process, or talk about the intent of evolution. But what do I know, I don't have a degree in evolutionary biology...
Well there is a good reason why it's implemented as encrypt-decrypt-encrypt, but it's not for cryptographic strength. Instead this has its roots in the hardware backwards compatibility.
That is to say that if you create an encrypt-decrypt-encrypt box and feed it the same key for all the crypto operations, you get plain DES encryption.
(i.e. encrypt m with x = c, decrypt c with x = m, encrypt m with x = c). If you want proper 3 DES you just feed it different keys.
So instead of having to create a box that does plain DES and triple DES, you can get plain DES using the same algorithm as the triple DES -- cheaper for the hardware manufacturers.
I don't tend to be particularly picky, but talking about SSL as though it is an encryption algorithm is a tad inaccurate.
SSL is a protocol which can make use of a wide variety of different encryption algorithms in different manners. There's an asymmetric encryption element, mainly for authentication & session key exchange, and a symmetric encrpytion element for the secrecy of ongoing communications. Talk about "breaking SSL" is somewhat misleading -- I think talking about breaking RSA, Diffie-Hellman, DES or AES is much more precise, and meaningful.
Lets face it, if a quantum computer somehow arrives that can factor numbers bigger than 15 (current limit I believe), asymmetric encryption algorithms will be much more shaky, but that doesn't necessarily mean the end of symmetric encryption.
> Response to terrorism (from the IRA) was one of drivers of the UKs current propensity towards spying on its citizens
While I'm sure the IRA played a part in getting cameras in the UK, I strongly believe the biggest factor was the Jamie Bulger case where those two teenagers were caught on camera leading that little boy away from his mother. After that, anyone who raised a voice to oppose cameras was obviously opposing child protection...
Whilst from a cryptographic point of view this is rather interesting, I have a couple of serious doubts as to how well this kind of system might work in practice:
1. What happens if candidates claim the system is flawed? You can't conduct a recount in a crypto system such as this (and get a different answer) so in effect if someone manages to contest the election, it's now void.
2. The audit is based on a statistical sampling of the ballots (IIRC checking the link between the candidate list and the voting receipt is correct) -- in no way is the actual counting audited. This means that the outcome of an election is based on someone pushing a button and a *machine* spewing out a total.
You simply cannot conduct a manual recount (you go and try to decrypt these numbers by hand!). In a perfect world the counting algorithm is ideal and doesn't make mistakes and is provable, in the real world the algorithm doing the counting might not be the same as the one in the perfect world... And the best you can do is get an expert to review the counting software, hardly an open and accountable process where anyone can volunteer...
I would say that this predisposes it very strongly towards the phishing crowd.
Out of interest, would you happen to know of any other types of attack that XSS might enable?
It's not quite like your example, although the principle is similar. The site isn't forwarded, it is the actual Paypal site that displays some rogue information, but it's because Paypal allows some script to be submitted as part of the URL and then (without checking it) executes it in one of their pages.
In this case I believe the script contains a notice that your account is locked and you need to visit some other (phishing) website to enable it again.
To answer your question, in short the attack doesn't work if you visit http://paypal.com/ manually.
What an attacker can do is craft a URL that *is* to paypal.com but contains the injected material (i.e. script) inside the URL. In short the paypal.com servers suffer from a vulnerability which allows the execution of this material (passed as an argument in the URL) -- and thus executes the script on the victim's browser. Because of this, the SSL connection is correct, but it appears that paypal is telling you that you need to go to another website to change your credentials.
You still have to get someone to click on the crafted URL for this to work though (hence why phishers are doing this, they're sending emails, or whatever.) so it's not going to work for people who don't click on the URL in phishing emails.
What I'm wondering is why someone would click on a link in a scam and then worry that the SSL certificate is genuine! Someone who knows enough to check the certificate is probably clever enough to ignore phishing scams...
Whilst it could be argued that recognition is part of knowledge (i.e. something you know), there are fundamental differences between recall (uncued) and recognition (cued). The latter is invariably easier - simple example: do you think it's easier to answer a multiple choice question, or a question with no choices?
The importance of this point should not be underestimated since one of the biggest problems with authentication mechansims is their ease-of-use, and their dependability. Cognometrics are easier to use in general, although there have been relatively few trials on their practical application in the real world.
Incidentally if you want to know more I would recommend the book "Security and Usability" edited by Lorrie Cranor and Simson Garfinkel. Chapter 7 describes cognometrics and has much greater depth about the issues and strengths (one of the authors is Ross Anderson).
Firstly I should correct you in that he never stole an iPod - he stole a iPod DJ System and a iPod Speaker System. It may well be that these products are freely available on shelves. You are, however, correct in your assumption the he used cheaper yet valid barcodes. This link prints the police statement for the arrest.
Essentially the first time he commited the crime he bought a DJ System by using the barcode from a CD player (which he had scouted out previously). The second time he tried (and was caught) he replaced the barcode for an Altec Lansing iPod speaker system with a barcode for earphones. He got caught because he was recognised by the security firm following the first incident.
Hehehe I'd forgotten that one..
Check out the follow on (not as good IMHO) here
Actually you couldn't even "brute force" a single key because they're all one-time pads. Quantum "crypto" provides a means for two parties to securely agree on one time pads.
The only way brute forcing works is for an algorithm based encryption system with a given key. You try all the possible inputs of that key until the algorithm decrypts the text to something meaningful. With a one-time pad, the key is the same length as the encrypted text and each bit of the key is XORed to each bit of the cleartext. Since each bit of the key is completely random, assuming you correctly guess the first bit of the key there is no way for you to confirm your guess.
Essentially trying to brute force a OTP is completely pointless because you cannot know if something you decrypted as saying "the secret is X" might in reality be "meet me at noon" or "the secret is Y".
The BBC also has an article that recounts the controversy here.
Security is not an absolute, it is relative. Yes WEP is broken, worse than previously thought.
WEP, however bad it is (and however many better solutions exist) still stops most people from using your bandwidth. Retail studies have shown that most staff theft is opportunistic - while most people are basically honest, if they see money lying around, most of them will pick it up. Same goes for unprotected bandwidth. Many people would not have a problem if it's completely open, but put even the semblance of a lock and they won't try to break in - that's because they have to actively be dishonest in order to steal your bandwidth/money, as opposed to ignorant.
So while it wasn't a perfect solution TM, it was actually better than nothing.
I'm not arguing that better solutions aren't available, but I am saying that WEP isn't as completely useless as you make it out to be.
What would you prefer no security or bad security? That's actually a trickier question than it sounds!
Actually if you haven't read it yet, I would highly recommend you read the FIPSPUB112 since it is a federal policy guideline (and no it doesn't advocate using "password" or a 4 digit pin as your secret...)
The point is that you need to have the buy in from the top - which is what this policy describes. It sounds as though you were made a scapegoat (and I do sympathise) by someone who didn't know or do their job properly.
At least by having complex passwords that expire and must change, (Notice I did not say random charachters I preffer to have pass phrases, and instead of spaces, I reccomend special characters for example insecure-passwords&suck1) clean desk policy, security policies, and security trainning, for all my l-users my arse is now protected. Now someone has to try and bruteforce a password which would take an extremely long time, find a security exploit, or (IMHO the easiest way)social engineer the user.
While I do understand why you have this attitude, I reiterate that this is not actually improving your security - it's improving your cya (cover your a**).
I agree that social engineering is the easiest way to get the password, and ironically the 'draconian' approach to password management you advocate makes it easier to exploit this by fostering a culture in which people expect problems with their passwords. So in a sense you are making what most serious attackers would choose as the most effective 'hack' even more likely to succeed - ironic no?
I think I should also make myself a bit clearer, I'm not saying we need simple passwords that any cracker can break (which is obviously insecure), but I am saying that, for example, forcing people to change their passwords too regularly can cause problems (and it does depend on your users!). Most IT admin staff can happily cope with changing their passwords every month (and even then I expect many just increment the end of their password... anyway..), most non IT literate people can't cope. I'm not sure why, but passwords are scary things - on par with usernames I might add - which make the magic box allow them to do their work. They don't understand, or care, about why it's necessary for it to be hard to guess - only that it's a pain in the a**.
Educating the users (as opposed to only training them) is the only way of defeating this and one of the hardest problems to solve in computer security (IMHO). Educating bosses and management comes a close second...
When I read this, I seriously started thinking this was great sarcasm.
Unfortunately I've since changed my mind.
There has been a lot of research in the area of password usability here is a short summary:
Fact 1: human memory is fallible
Fact 2: people cannot forget on demand
Fact 3: non meaningful things (i.e. random) are amongst the hardest things to remember
Fact 4: items in human memory interfere with each other making 100% recall very hard
Fact 5: unaided (no prompts) recall is much harder than providing prompts (which becomes a recognition exercise - passfaces is an interesting technology for example)
Fact 6: ambushing a user to change their passwords stops them from doing their work (which they get paid for) and encourages them to bypass the system as quickly as possible - i.e. write the password down
CONGRATULATIONS you are following rules which were laid out in the original FIPS guidelines (1985) for password management... Maybe you ought to revisit their document, they have updated it and it makes a LOT more sense now (check out FIPSPUB112)... I just wanted to let you know that pretty much everything you describe decreases the security of your organisation.
Actually I always thought the name came from the concept of power grids. i.e. plug in your application to the computing grid, get it to run your computations, and get the results without having to worry about how the computing power got to your home...
Kind of similar to a power grid no? plug toaster, insert bread, get toast - no need to worry about coal/oil/nuclear fuel burning, transfomers or megawatts...
I have had some experience with grids and the overwhelming difficulties I've come across have been in the areas of security.
First and foremost, grids are designed to run in a distributed environment which makes security design and administration that much more complex.
Second, grids are currently in their infancy and there is little prior art to the types of attacks and problems that will affect them. Despite this, they are very juicy targets with the kind of storage and bandwidth that would make even a hard-bitten cracker weep for joy. (i apologise for the imagery)
Third, in my book security has to be a top-down approach - i.e. the guys on top lead the way and then everyone else follows. Grids have no tops or bottoms which makes this a bit tough to apply. In short there is no security hierarchy in a default grid environment. Responsibility HAS to be established explicitly. A simple example is who is responsible for the data held on one of the nodes? Is it the person who wrote the application, the person who owns the application, the person who owns the hardware?
Grids are fascinating in their security requirements (and those who think these are solved by web services have another thing coming! People are a huge aspect of the security of a system, and distributed system like grids have a very complex task of ensuring that people behave the way they should).
Very astute comment!
:
In my experience, I've come across what social scientists call "diffusion of responsibility" with regards to security. Basically it's the notion that if you are on your own and you come across a person having a heart attack you will do something, if you're in a crowd, people will just stand there frozen in the expectation that someone else will do something.
In security this has led to me witnessing a "it's not *my* problem" attitude or a "someone else is taking care of this".
Responsibility and authority are massively important in order for a system be secure.
Applying the point of the original post to the comment "security is everybody's responsibility" means that everyone who has a security responsibility should have a matching authority. i.e. if it comes down to someone deciding whether to comply with a security procedure or bypassing it to get the job done more quickly, then if that person is responsible for security, they should have the leeway to delay the job to take care of the security.
Likewise everyone who has a security authority (i.e. an ability to determine whether a security measure is applied or not - which is very frequent in the case of systems relying on their users changing their passwords, making manual backups, encrypting their emails etc.) should have a matching responsibility.
This ultimately means that security measures involving people should be very carefully judged, because if you give someone authority over your system you have to depend on them to behave in the right way, which means that they have to be
1. able to do so (not too demanding, simple, doesn't conflict with other pressures, etc.)
2. willing to do so (motivation, responsibility, culturally acceptable - avoiding security can be a sign of seniority!!! how many managers actually comply with policy?!)
Thanks for your point about the panopticon - I must confess that I don't subscribe to that particular attitude about law enforcement.
;-) ) or avoid inconvenience over a population of several million.
I also want to point out that I'm opposed to a government introducing biometric ids. I don't care if they introduce non biometric ids, because I don't see that as particularly harmful.
I would still like, however, to dispute your claim that biometrics will be 100% effective.
My argument is based on the fact that unless they change their way of capturing your biometrics (as in store real copies of your dna, as opposed to structured snapshots) there will ALWAYS be uncertainty in any match. This is because biometric information is far too rich for a computer to process and therefore has to operate on a formal and restricted model of biometrics that is hoped/tested to be reasonably accurate. This restriction of the data set, together with imperfections of reading the biometric data (both at the initial enrollment, and at the subsequent checks) means that it WILL NOT be 100% effective.
How effective it can be is completely open to debate, and I'm saying that even if they achieve the 99.999% accuracy, this is *still* not enough for the purposes you describe. (This is one of the reasons why biometrics, as a means of identifying terrorists, is a specious argument).
In addition to this, biometric information in individuals can change. Fingerprints can be worn through labour or a nail file, you may injure your eye, or have laser treatment on your retina, and so on.
What will happen in the future is that these technologies will get more accurate, but I think it is highly debatable that in following their current principles they will get sufficiently accurate as to provide either benefits (as in identifying crooks - you never know
Finally my point was that in order for the authorities to absolutely determine your identity *in the absence of other identification* (such as you giving your name, your id card, them following you, etc.) the computational requirements and the limitations of biometrics as they are (and as I've argued will be) simply make this a costly, inaccurate and rather ineffective means of identifying you based solely on some reading of your biometric information. At the end of the day it's far simpler for them to follow you home...
Interesting FACT... You do realise that they've got close to 10% error (false positive/false negative) rate going on - and that's knowing who they're trying to match against.
You are assuming that biometrics are 100% effective. If you are trying to identify someone without an identity to match against, this stops everything dead. Making a simplified calculation (which is probably an incorrect inference but it'll serve our purposes) if you take the 10% error rate, you'll have 10% of the whole database of positive matches (on top of a 10% chance that you won't even be in the results!!!). In a database of 60 million, that's 6 million. Not exactly pinpoint accuracy is it! (Even if biometrics become 99.999% accurate you'll still get 60000 matches... not very good is it!!!)
The carrying of the card is VITAL if they want to even try to enforce this.