There are two main sources of value that come out of a pentest; the experience of the test, and the report.
The experience should help you answer the following questions: Were my controls effective at detecting and/or thwarting the attacks?
How well did my staff respond to the test?
At what point will I notice malicious activity?
Are my current logging and review procedures effective at recording all necessary information and identifying the attacks?
Is my staff capable of responding to intrusion attempts?
Is my incident response plan effective?
Where should I invest more in training?
Are my IDS and Firewall operating as designed?
Do I fully understand my network and internet presence?
Where should I focus my future IT audit efforts, was anything identified as a result of the testing that needs to be included in future audit coverage?
And the report should help you answer the following:
What testing was performed?
What were the results of those tests?
What do those results mean?
How do those results impact your business?
What do the problems that have been pointed out mean?
What is the potential impact of items that have been identified?
Has any of the conjectured impact been verified?
What level of compromise of data or control of resources was obtained?
What is the amount of effort, knowledge, and access needed to perpetrate the things your test say are possible?
What do you need to do to fix the problem or how can you control the problem in a way that fits into your business?
The more of these questions that the pentest can answer for you, the more valuable, and the more expensive, that test will be.
This is not completely true. It should *also* be their job to help you understand those results, and to help you realize how those results apply to your business, and to help you prioritize those results. Any pentest worth jack will *not* be output of an automated tool, it will be a handwritten report explaining the discovered problems in plain english with whatever support is necessary to validate whatever claims are made. Ideally it will also include guidance on what to do about the problems. Please start to expect more out of your security vendors folks.
As a security professional it's frustrating to see companies choose my competitors becuase they are cheaper without realizing how worthless they are. Guess what, if you skimp on a pentest, all you are gonna get is a nessus scan with a cover page. If you actually get a company that knows what they are doing, then you are paying not only for the scans and the activities, but for the knowledge and effort to wead out the false positives and to *verify* the results.
Guess what folks, a nessus scan is *not* a penetration test. It's a vulnerability scan. A penetration test is executed by consultants, not automated by generic tools. Sure, they will use those tools, but they will also use their own understanding of information systems, they will also gain an understanding of the overall picture and they will also be usefull experiences and reports! If you really paid top dollar for what you described, you got screwed, shop for a different pentesting vendor.
It doesn't really matter, according to California Civil Code 1798.29:
Any agency that owns or licenses computerized data that includes personal information shall disclose any breach of the security of the system following discovery or notification of the breach in the security of the data to any resident of California whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person.
Basically, if they can't prove that the data *wasn't* compromised, then they are going to have to treat the situation as if it were and let everyone who may be impacted know about the incident.
One thing to consider though, if you use a passphrase with more then 14 characters in it, you automagically prevent the LM hash (the weaker one that is case independent) from being created, making things at least a bit better;)
I have a client that tried using fingerprint readers at their ATMs. They were still using PINs as well. The fingerprint reader was just there so their customers wouldn't need their card. They have had a lot of problems with it mainly becuase biometric identification (vs just biometric authentication) is a ton harder to do. In the end they ended up switching back to normal card+pin methods. (As far as I know, none of their customers got their fingers chopped off;).
The entire premise of your post talks about how easy it is to get a physical object from someone. Up front, you are ignoring the fact that you have gone from something anyone anywhere in the world may attempt to do, to something only those in your vicinity can even attempt. That's a pretty huge leap to just ignore. Yes, users will give you their tokens, they will give you your password, the two are pretty much equivalent, in that one situation, where you are already an established person that knows them, where you already have a level of trust with them.
So let's take a look at your assertions:
It's really not that hard steal keys, whereas passwords can't really be stolen. Locale aside, it is easy to get someone's password. Ask anyone who performs penetration tests that include social engineering, and you will get the same answer, it's one of the easiest ways to gain access and sensitive information. Maybe you are thinking of how hard it is for someone to get your password, in which case you are correct, but you aren't a typical "user"
Both passwords and keys can be given. Well, yes, but it's generally tougher to convince someone to drop ship their keys to someone they don't know, etc.
You need machinery to copy keys, but it isn't hard, nor is that machinery rare. Passwords are copied automatically by being given. I agree with you here, but I think there are some flaws in your key analogy. A key, let's even say a good key, will have 5 pins or so in it. Each of those pins is likely to have a set number of possible positions, let's say 10. That means you have 10^5 possible keys, which is a nice high number, but pails in comparison to the complexity of pretty much any typical token that you could come up with that is used in todays environments. Not only that, but keys are inherently flawed in how easily they are picked. Any token authentication that is *that* broken is not going to survive, or make it as an enterprise solution. Picking a lock (without even knowing anything about the key) is easy, surprisingly so. Building and faking an RSA token, especially knowing nothing about it, is hard, very hard. That's why people use them. Any ways, your point above is essentially saying that the token is menially harder to copy, where as the password is copied very simply, just by giving it out.
You might write a password down, but that's almost an example of "giving" to anyone who would take it. It amounts to leaving copies of your keys for anyone to copy on a whim. Again, I think you are considering yourself here, and how unlikely it is that you would write your password down, but the unfortunate truth is that users in a corporate environment write their passwords down all the time. Companies get things like two factor authentication to mitigate risks such as careless or uninformed employees, among other things.
Passwords can be cracked, and key locks can be picked. Again, the analogy is a weak one. Yes, keys can be picked. And if there were a token authentication method that could be bypassed simply shaking the token reader (if that were the type it was) you can rest assured that it wouldn't get implemented anywhere.
Passwords can be guessed based on knowledge of the user, and a locksmith could try to make the key based on his knowledge of knowledge of the lock. Again, this is true, but the analogy is flawed. Even if the analogy were true, you've limited your possible attackers from the set containing all people, to just the set containing lock smiths, which is an improvement.
Part of the reasons there aren't standards is that it's really complicated to come up with a good system. (Right! Which is why passwords are cheaper.) It's because the simple versions of these technologies are easy to get around that such expensive and complex technologies are required. And that's at least a large part of the reason why the "something you have" and "something you a
Well, I'd say that's *a* reason why they've been used for so long. I would say that *another* reason why they're used is the reason that I said.
Given the weight of the two, and what really drives such decisions (cost) I would say that is pretty much *the* reason.
"Hey boss, we can implement an rsa token and be more secure. Oh, the downside? Uhm, it's a lot more expensive, and it won't quite integrate with all of our applications, and it may actually break some of the other ones. Ok, I'll stop bugging you"
However, in another way of looking at it, a password always needs to be given, and can't really be taken.
Again I'll have to disagree with you here. Sure, a *strong* password can't be taken, but a weak, stupid one can easily be guessed, and if other controls aren't in place, the password can be brute forced. Let's face it, the people in your company that use passwords like "La9k3S(2ks@!!o" are *not* the ones that will be giving their passwords out over the phone, but you know what, the people whose password is "Winter05" or worse "Password" don't need to give it to anyone for it to be compromised.
Another thing, Yes, they may have to write it down, but guess what, they do. All the time. Employees will take their card that was issued to them a lot more seriously because they can feel it, they can hold it in their hands, they understand the impact. It also doesn't require them to memorize anything. The second that employee feels put out by having to memorize yet another password, they will write it down and stick it in any one of a number of common places. Sure, it has to be given in that sense, but the propensity to give it is much higher.
And finally: I'd consider "generally hardest to steal, hardest to fake, and easiest to change" as part of the explanation as to why they're cheapest and easiest to implement.... "
I don't think they are the hardest to steal at all, I would argue that they are the easiest (and putting "generally" in front of it doesn't change that). They are the cheapest because they are the easiest to implement. They are the easiest to implement because there is an order of magnitude less complexity in how the system obtains the password, and how the system verifies that the password is correct. (No extra hardware, no complicated crap to go through to digitize and compare a face, no thresholds to muck with, no proprietary formats or tokens that third parties have to universally support, etc).
On a side note, although the idea of biometrics and keycards sounds cooler than a password, there's a reason why computer security has been using the "something you know" for so long. Of the three, it's generally hardest to steal, hardest to fake, and easiest to change (in case someone else does gain access).
Actually you are giving much more credit here then is due. The reason it has been passwords for so long is because they have been the cheapest and easiest to implement. Also, I would argue it's much easier to steal a password (social engineering or brute forcing in some cases) then it would be a token or a biometric. Only the password can be stolen from across the globe using minimal effort and without any prior knowledge about who are stealing it from. (aside from perhaps their phone number and email address)
If it's not two seperate of the three, then it's not two-factor authentication. That's why "something you have" and "something you are" are important distinctions. It's ok to have token-fingerprint, but not token-token, or fingerprint-voice, etc.
The "factors" are which type they are, not the individual mechanism itself.
Saying that the something you are category fits into the something you have category is fundamentally wrong. Someone can't steal your facial structure, or your hand structure quite as easily as they can your token or smart card. You can't "copy" someones retina quite like you can the magnetic strip of their swipe card. The grandparent post had it wrong.
Flame on.
There are three categories of ways you can verify you are who you say you are:
Something you know: (password, PIN, mothers maiden name, etc.) This is the one we are all familiar with, you know your password and theoretically, no one else does, so by giving your password you can verify that you are who you say you are.
Something you have: (smart card, RSA token, dongle, etc.) This is where there is something you posess that is somehow keyed to you and uniquely yours. Think hotel key. The way you tell your hotel room that you are the resident of that room is by presenting something you have, your hotel key. Theoretically, no one else would have that key, so it suffices to verify who you are.
Something you are: (finger print, voice print, iris, retina, facial structure, hand structure, etc.) This is the wide world of biometrics. Again, pretty simple, your fingerprint is uniquely yours, and by presenting it, you can verify that you are who you say you are.
Two factor authentication is simply having two forms of verifying that you are who you say you are that are from seperate categories. We are all used to this already and may not realize it. When you drive up to an ATM, you insert your card (something you have) and type in your PIN (something you know) and then you can withdraw funds. Imagine if all you had to do was insert the card, or all you needed to know was your PIN, it would be disastorous.
Schneier concludes: Early adopters of this technology may very well experience a significant drop in fraud for a while as attackers move to easier targets, but in the end there will be a negligible drop in the amount of fraud and identity theft.
I really think he missed the boat on this one. Yes, two factor authentication won't solve everything, but to claim that it won't have an effect at all is simply short sighted. Back to the ATM example; yes, there are people that will swipe a copy of your card at the gas station counter, there are people that will lurk over your shoulder and get your PIN, and there are people that may simply put a gun to your head and tell you to enter your card and PIN and withdraw whatever you can, but Schneier is saying that it's no improvement over someone just having to copy or steal your card, or just figure out your pin and not need anything else.
There are ways around two-factor authentication, but they are a lot more involved, require a lot more effort and some times access to begin with. Setting up a man in the middle is in a whole nother ballpark then calling someone up over the phone and convincing them that they should give you their password. Try then convincing that person to mail you their debit card and then tell me two factor authentication wouldn't have a significant impact.
Disclaimer: I'm usually a big fan of Schneier, don't call me a hater;)
I see a lot of people get this wrong. Two factor authentication isn't necessarily "something you have" and "somethig you know". It's using two of the three possible forms (a lot of people seem to forget the "something you are" form).
Having a system that required smart-card and a fingerprint without ever having to provide a username or password would be another possible example of two-factor authentication.
"Something you know" (password, PIN, mothers maiden name, checking account activity) and
"Something you have" (token, smart card, etc.)
This is the most common form of two factor authentication, but not the only form.
Phishing works in numerous ways like creating fake websites like www.payypal.com which is a close of replica of paypal to trick mom and pop.
One of the ones we see most often is registering the name with "www" added on to the front. This is a double whammy, you catch the people who forgot to hit the period, or miss-hit it and end up visiting "http://wwwpaypal.com" or "http://wwwmyinternetbank.com" and you also get a domain name that isn't really a miss-spelling. It seems minor, but this is one of the many things we check for when performing security assessments.
Should the same method be used to have a legitimate claim to absolutely anything the guy had, regardless of how personal or private it may be? If he had known that his family could simply be handed his yahoo account perhaps he would have expressly forbid it. Who knows what skeletons are or aren't in that closet. The point is that it's not anyone's closet to look in except the diseased.
How should Yahoo be expected to make a measure on what would be appropriate and what wouldn't be appropriate to release and what burden of proof should there be to any of this. Yahoo would have to establish a standard by which any claims are verified as legal to show their due diligence in the matter. The last thing we want is a "release this diseased person's account to me" form and anything beyond that represents significant effort on Yahoo's part to do things appropriately, why should they bother?
If a friend occasionally confided in me, or wrote in my journal, would the information and facts that he had said to me be considered his property? Would it be appropriate to demand them? Would I have to hand them over?
Turning off the SSID is a great step towards keeping the wardrivers away, but if you have a neighbor that wants to get on that network, it won't stop them. The SSID, unfortunately, is still broadcast in the association frames even if beacon frames are disabled. A dedicated attacker is going to get in, so best use something other then just WEP with MAC filtering and beacon frames disabled.
Fake AP is a tool that generates thousands of beacon frames so that your AP, named "12381" can get lost in the shuffle. It's not fool proof, but it is funny to hear netstumbler wet itself when you come in the vicinity of it.
It certainly would be interesting if yahoo mail accounts turned into the defacto The Speaker For The Dead
Aside from that, why should yahoo take on the burden of due diligence to prove someone was actually dead as well as the people who want the access are legit. It's much easier and certainly less liability to simply say they aren't going to do it. Want more from your email service? Try paying for it to begin with.
There are two fundamental concerns when considering the placement of wireless access points on any network.
1) Someone can access my network.
2) Someone can see my traffic.
Any wireless network implementation should take both of these into account. Wireless access points, until other encryption and access control mechanisms mature, should be treated as if they were compromised to begin with. If you treat an access point like a live jack into your network that's located outside your building some where, then you are off to a good start.
To address the first issue, we need network segmentation. Locate the access point in a DMZ, only allowing communication with other network resources over controlled means, such as ssh. By located it in a DMZ, you limit the exposure of the rest of your network and have the means to properly control what it can and can't see. Ideally, it can't see anything without some form of authentication beyond what is provided by the AP. This is possible to accomplish regardless of what you want your legitimate users to be capable of through the use of properly configured proxy servers, etc.
To address the second issue, as several others have mentions, make sure that anything that is sensitive is encrypted. Don't allow people to check their email through the wireless connection using imap or pop3, require that they use a web interface with SSL encryption. Don't use telnet for your custom applications, whatever they may be, use SSH. Of course, all that being said, it's much easier to tell someone to never use telnet then it is to actually do it. Anyone care to take a guess at how a typical software vendor supporting legacy applications will respond to the request to make their programs function over SSH?
So let me get this straight, after successfully fooling a user that the site they are seeing is legit when it's actually spoofed, then they can get the results of local search queries, potentially seeing parts of a file. Don't get me wrong, that kind of stinks and all, but if you have already fooled someone into believing the sites they are looking at are legit, why bother with this? Show them a gmail login, or a yahoo mail login, or if you know a bit about them, their internet banking login.
In retrospect, I think I had this wrong. The java app, once connected to, isn't necessarily spoofing the Google page, it's simply faking the process of querying Google. The java applet is querying Google as opposed to a user who thinks the applet *is* Google. Whoops, sorry, feel free to take the insightful mods back;)
The Rice group was able to create a Java program that makes network connections back to the computer from where it was downloaded and then make it appear as if it were asking for a search at Google.com. That was enough to fool the Google desktop software into providing the user's search information. The program was able to do anything with the results, including transmitting them back to the attacking site.
So let me get this straight, after successfully fooling a user that the site they are seeing is legit when it's actually spoofed, then they can get the results of local search queries, potentially seeing parts of a file. Don't get me wrong, that kind of stinks and all, but if you have already fooled someone into believing the sites they are looking at are legit, why bother with this? Show them a gmail login, or a yahoo mail login, or if you know a bit about them, their internet banking login.
This security flaw doesn't seem like that big of a deal and if anything, it highlights that Google is being proactive about such things; addressing the issue and releasing fixed software in a reasonable amount of time. Kudos.
1) The security consulting industry is larger then a lot of people realize. This would be one of the first places to look for beginner level positions.
2) Not all security jobs require security clearance, only government jobs (or jobs that are in some way related to government work) do. There are several industries that require the services of a security consulting company. For example, Financial intuitions are *required* to have independent security audits performed of their IT environment. There are various regulations out that motivate companies to hire security people (GLBA for financial institutions, HIPAA for healthcare, etc.)
3) Security professionals are in more places then you might realize. Any one of the top 15 accounting firms in the nation will most likely have a security consulting practice. There are countless managed security solution providers. There are companies (many of them!) that do nothing but provide real time 24x7 monitoring to their clients. Any one of these companies can usually find use for an intern, especially one that has the information security mindset, and most of these will not require a security clearance.
4) Contrary to what some may have you believe, certifications aren't everything. You can not get your CISSP until you have 3 years of experience (assuming you graduate) or 2 years of experience (assuming you graduate with a Masters). No company that is looking to hire an intern will be looking for that intern to have their CISSP or CISA.
5) Good news, the security industry is booming and everyone is hiring. The company I work for has consistently hired more people every year since I started. Three years ago there were 30 professionals dedicated to information security consulting, now there are about 85, a large portion of which were hired straight from college.
So, in summary, I would focus your efforts on companies that perform security services such as consulting companies (read: accounting firms, and specialty firms like the foundstones of the world), managed service providers, datacenters and various niche services such as real time intrusion detection shops. Start making phone calls, asking if they have a security practice, and who you could talk to about a job. These places are hiring, if you aren't on their radar already, it's up to you to put yourself on their radar.
Slashdot Mirror
There are two main sources of value that come out of a pentest; the experience of the test, and the report.
The experience should help you answer the following questions:
Were my controls effective at detecting and/or thwarting the attacks?
How well did my staff respond to the test?
At what point will I notice malicious activity?
Are my current logging and review procedures effective at recording all necessary information and identifying the attacks?
Is my staff capable of responding to intrusion attempts?
Is my incident response plan effective?
Where should I invest more in training?
Are my IDS and Firewall operating as designed?
Do I fully understand my network and internet presence?
Where should I focus my future IT audit efforts, was anything identified as a result of the testing that needs to be included in future audit coverage?
And the report should help you answer the following:
What testing was performed?
What were the results of those tests?
What do those results mean?
How do those results impact your business?
What do the problems that have been pointed out mean?
What is the potential impact of items that have been identified?
Has any of the conjectured impact been verified?
What level of compromise of data or control of resources was obtained?
What is the amount of effort, knowledge, and access needed to perpetrate the things your test say are possible?
What do you need to do to fix the problem or how can you control the problem in a way that fits into your business?
The more of these questions that the pentest can answer for you, the more valuable, and the more expensive, that test will be.
This is not completely true. It should *also* be their job to help you understand those results, and to help you realize how those results apply to your business, and to help you prioritize those results. Any pentest worth jack will *not* be output of an automated tool, it will be a handwritten report explaining the discovered problems in plain english with whatever support is necessary to validate whatever claims are made. Ideally it will also include guidance on what to do about the problems. Please start to expect more out of your security vendors folks.
As a security professional it's frustrating to see companies choose my competitors becuase they are cheaper without realizing how worthless they are. Guess what, if you skimp on a pentest, all you are gonna get is a nessus scan with a cover page. If you actually get a company that knows what they are doing, then you are paying not only for the scans and the activities, but for the knowledge and effort to wead out the false positives and to *verify* the results.
Guess what folks, a nessus scan is *not* a penetration test. It's a vulnerability scan. A penetration test is executed by consultants, not automated by generic tools. Sure, they will use those tools, but they will also use their own understanding of information systems, they will also gain an understanding of the overall picture and they will also be usefull experiences and reports! If you really paid top dollar for what you described, you got screwed, shop for a different pentesting vendor.
It doesn't really matter, according to California Civil Code 1798.29:
Any agency that owns or licenses computerized data that includes personal information shall disclose any breach of the security of the system following discovery or notification of the breach in the security of the data to any resident of California whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person.
Basically, if they can't prove that the data *wasn't* compromised, then they are going to have to treat the situation as if it were and let everyone who may be impacted know about the incident.
All of your students may have had their personal information compromised? Damn, bad PR. Oh, wait a minute, they are all from California, double damn.
There's nothing quite like being required by law to notify every single student that their information may have been compromised to help an organization take security a bit more seriously.
One thing to consider though, if you use a passphrase with more then 14 characters in it, you automagically prevent the LM hash (the weaker one that is case independent) from being created, making things at least a bit better ;)
I have a client that tried using fingerprint readers at their ATMs. They were still using PINs as well. The fingerprint reader was just there so their customers wouldn't need their card. They have had a lot of problems with it mainly becuase biometric identification (vs just biometric authentication) is a ton harder to do. In the end they ended up switching back to normal card+pin methods. (As far as I know, none of their customers got their fingers chopped off ;).
The entire premise of your post talks about how easy it is to get a physical object from someone. Up front, you are ignoring the fact that you have gone from something anyone anywhere in the world may attempt to do, to something only those in your vicinity can even attempt. That's a pretty huge leap to just ignore. Yes, users will give you their tokens, they will give you your password, the two are pretty much equivalent, in that one situation, where you are already an established person that knows them, where you already have a level of trust with them.
So let's take a look at your assertions:
It's really not that hard steal keys, whereas passwords can't really be stolen.
Locale aside, it is easy to get someone's password. Ask anyone who performs penetration tests that include social engineering, and you will get the same answer, it's one of the easiest ways to gain access and sensitive information. Maybe you are thinking of how hard it is for someone to get your password, in which case you are correct, but you aren't a typical "user"
Both passwords and keys can be given.
Well, yes, but it's generally tougher to convince someone to drop ship their keys to someone they don't know, etc.
You need machinery to copy keys, but it isn't hard, nor is that machinery rare. Passwords are copied automatically by being given.
I agree with you here, but I think there are some flaws in your key analogy. A key, let's even say a good key, will have 5 pins or so in it. Each of those pins is likely to have a set number of possible positions, let's say 10. That means you have 10^5 possible keys, which is a nice high number, but pails in comparison to the complexity of pretty much any typical token that you could come up with that is used in todays environments. Not only that, but keys are inherently flawed in how easily they are picked. Any token authentication that is *that* broken is not going to survive, or make it as an enterprise solution. Picking a lock (without even knowing anything about the key) is easy, surprisingly so. Building and faking an RSA token, especially knowing nothing about it, is hard, very hard. That's why people use them. Any ways, your point above is essentially saying that the token is menially harder to copy, where as the password is copied very simply, just by giving it out.
You might write a password down, but that's almost an example of "giving" to anyone who would take it. It amounts to leaving copies of your keys for anyone to copy on a whim.
Again, I think you are considering yourself here, and how unlikely it is that you would write your password down, but the unfortunate truth is that users in a corporate environment write their passwords down all the time. Companies get things like two factor authentication to mitigate risks such as careless or uninformed employees, among other things.
Passwords can be cracked, and key locks can be picked.
Again, the analogy is a weak one. Yes, keys can be picked. And if there were a token authentication method that could be bypassed simply shaking the token reader (if that were the type it was) you can rest assured that it wouldn't get implemented anywhere.
Passwords can be guessed based on knowledge of the user, and a locksmith could try to make the key based on his knowledge of knowledge of the lock.
Again, this is true, but the analogy is flawed. Even if the analogy were true, you've limited your possible attackers from the set containing all people, to just the set containing lock smiths, which is an improvement.
Part of the reasons there aren't standards is that it's really complicated to come up with a good system. (Right! Which is why passwords are cheaper.) It's because the simple versions of these technologies are easy to get around that such expensive and complex technologies are required. And that's at least a large part of the reason why the "something you have" and "something you a
Well, I'd say that's *a* reason why they've been used for so long. I would say that *another* reason why they're used is the reason that I said.
... "
Given the weight of the two, and what really drives such decisions (cost) I would say that is pretty much *the* reason.
"Hey boss, we can implement an rsa token and be more secure. Oh, the downside? Uhm, it's a lot more expensive, and it won't quite integrate with all of our applications, and it may actually break some of the other ones. Ok, I'll stop bugging you"
However, in another way of looking at it, a password always needs to be given, and can't really be taken.
Again I'll have to disagree with you here. Sure, a *strong* password can't be taken, but a weak, stupid one can easily be guessed, and if other controls aren't in place, the password can be brute forced. Let's face it, the people in your company that use passwords like "La9k3S(2ks@!!o" are *not* the ones that will be giving their passwords out over the phone, but you know what, the people whose password is "Winter05" or worse "Password" don't need to give it to anyone for it to be compromised.
Another thing, Yes, they may have to write it down, but guess what, they do. All the time. Employees will take their card that was issued to them a lot more seriously because they can feel it, they can hold it in their hands, they understand the impact. It also doesn't require them to memorize anything. The second that employee feels put out by having to memorize yet another password, they will write it down and stick it in any one of a number of common places. Sure, it has to be given in that sense, but the propensity to give it is much higher.
And finally: I'd consider "generally hardest to steal, hardest to fake, and easiest to change" as part of the explanation as to why they're cheapest and easiest to implement.
I don't think they are the hardest to steal at all, I would argue that they are the easiest (and putting "generally" in front of it doesn't change that). They are the cheapest because they are the easiest to implement. They are the easiest to implement because there is an order of magnitude less complexity in how the system obtains the password, and how the system verifies that the password is correct. (No extra hardware, no complicated crap to go through to digitize and compare a face, no thresholds to muck with, no proprietary formats or tokens that third parties have to universally support, etc).
On a side note, although the idea of biometrics and keycards sounds cooler than a password, there's a reason why computer security has been using the "something you know" for so long. Of the three, it's generally hardest to steal, hardest to fake, and easiest to change (in case someone else does gain access).
Actually you are giving much more credit here then is due. The reason it has been passwords for so long is because they have been the cheapest and easiest to implement. Also, I would argue it's much easier to steal a password (social engineering or brute forcing in some cases) then it would be a token or a biometric. Only the password can be stolen from across the globe using minimal effort and without any prior knowledge about who are stealing it from. (aside from perhaps their phone number and email address)
If it's not two seperate of the three, then it's not two-factor authentication. That's why "something you have" and "something you are" are important distinctions. It's ok to have token-fingerprint, but not token-token, or fingerprint-voice, etc.
The "factors" are which type they are, not the individual mechanism itself.
Saying that the something you are category fits into the something you have category is fundamentally wrong. Someone can't steal your facial structure, or your hand structure quite as easily as they can your token or smart card. You can't "copy" someones retina quite like you can the magnetic strip of their swipe card. The grandparent post had it wrong. Flame on.
There are three categories of ways you can verify you are who you say you are:
;)
Something you know: (password, PIN, mothers maiden name, etc.) This is the one we are all familiar with, you know your password and theoretically, no one else does, so by giving your password you can verify that you are who you say you are.
Something you have: (smart card, RSA token, dongle, etc.) This is where there is something you posess that is somehow keyed to you and uniquely yours. Think hotel key. The way you tell your hotel room that you are the resident of that room is by presenting something you have, your hotel key. Theoretically, no one else would have that key, so it suffices to verify who you are.
Something you are: (finger print, voice print, iris, retina, facial structure, hand structure, etc.) This is the wide world of biometrics. Again, pretty simple, your fingerprint is uniquely yours, and by presenting it, you can verify that you are who you say you are.
Two factor authentication is simply having two forms of verifying that you are who you say you are that are from seperate categories. We are all used to this already and may not realize it. When you drive up to an ATM, you insert your card (something you have) and type in your PIN (something you know) and then you can withdraw funds. Imagine if all you had to do was insert the card, or all you needed to know was your PIN, it would be disastorous.
Schneier concludes: Early adopters of this technology may very well experience a significant drop in fraud for a while as attackers move to easier targets, but in the end there will be a negligible drop in the amount of fraud and identity theft.
I really think he missed the boat on this one. Yes, two factor authentication won't solve everything, but to claim that it won't have an effect at all is simply short sighted. Back to the ATM example; yes, there are people that will swipe a copy of your card at the gas station counter, there are people that will lurk over your shoulder and get your PIN, and there are people that may simply put a gun to your head and tell you to enter your card and PIN and withdraw whatever you can, but Schneier is saying that it's no improvement over someone just having to copy or steal your card, or just figure out your pin and not need anything else.
There are ways around two-factor authentication, but they are a lot more involved, require a lot more effort and some times access to begin with. Setting up a man in the middle is in a whole nother ballpark then calling someone up over the phone and convincing them that they should give you their password. Try then convincing that person to mail you their debit card and then tell me two factor authentication wouldn't have a significant impact.
Disclaimer: I'm usually a big fan of Schneier, don't call me a hater
I see a lot of people get this wrong. Two factor authentication isn't necessarily "something you have" and "somethig you know". It's using two of the three possible forms (a lot of people seem to forget the "something you are" form).
Having a system that required smart-card and a fingerprint without ever having to provide a username or password would be another possible example of two-factor authentication.
"Something you know" (password, PIN, mothers maiden name, checking account activity) and "Something you have" (token, smart card, etc.)
This is the most common form of two factor authentication, but not the only form.
Another fun way to do this is to use the "http://username:password@site.com" format.
Please visit http://www.paypal.com:login@losers.org/login.asp
Want to make it even more obscure? UUencode everything after http://www.paypal.com and that's a wrap.
Phishing works in numerous ways like creating fake websites like www.payypal.com which is a close of replica of paypal to trick mom and pop.
One of the ones we see most often is registering the name with "www" added on to the front. This is a double whammy, you catch the people who forgot to hit the period, or miss-hit it and end up visiting "http://wwwpaypal.com" or "http://wwwmyinternetbank.com" and you also get a domain name that isn't really a miss-spelling. It seems minor, but this is one of the many things we check for when performing security assessments.
Should the same method be used to have a legitimate claim to absolutely anything the guy had, regardless of how personal or private it may be? If he had known that his family could simply be handed his yahoo account perhaps he would have expressly forbid it. Who knows what skeletons are or aren't in that closet. The point is that it's not anyone's closet to look in except the diseased.
How should Yahoo be expected to make a measure on what would be appropriate and what wouldn't be appropriate to release and what burden of proof should there be to any of this. Yahoo would have to establish a standard by which any claims are verified as legal to show their due diligence in the matter. The last thing we want is a "release this diseased person's account to me" form and anything beyond that represents significant effort on Yahoo's part to do things appropriately, why should they bother?
If a friend occasionally confided in me, or wrote in my journal, would the information and facts that he had said to me be considered his property? Would it be appropriate to demand them? Would I have to hand them over?
Turning off the SSID is a great step towards keeping the wardrivers away, but if you have a neighbor that wants to get on that network, it won't stop them. The SSID, unfortunately, is still broadcast in the association frames even if beacon frames are disabled. A dedicated attacker is going to get in, so best use something other then just WEP with MAC filtering and beacon frames disabled.
Why broadcast just 1 SSID when you can broadcast several thousand?
Fake AP is a tool that generates thousands of beacon frames so that your AP, named "12381" can get lost in the shuffle. It's not fool proof, but it is funny to hear netstumbler wet itself when you come in the vicinity of it.
It certainly would be interesting if yahoo mail accounts turned into the defacto The Speaker For The Dead
Aside from that, why should yahoo take on the burden of due diligence to prove someone was actually dead as well as the people who want the access are legit. It's much easier and certainly less liability to simply say they aren't going to do it. Want more from your email service? Try paying for it to begin with.
There are two fundamental concerns when considering the placement of wireless access points on any network.
1) Someone can access my network.
2) Someone can see my traffic.
Any wireless network implementation should take both of these into account. Wireless access points, until other encryption and access control mechanisms mature, should be treated as if they were compromised to begin with. If you treat an access point like a live jack into your network that's located outside your building some where, then you are off to a good start.
To address the first issue, we need network segmentation. Locate the access point in a DMZ, only allowing communication with other network resources over controlled means, such as ssh. By located it in a DMZ, you limit the exposure of the rest of your network and have the means to properly control what it can and can't see. Ideally, it can't see anything without some form of authentication beyond what is provided by the AP. This is possible to accomplish regardless of what you want your legitimate users to be capable of through the use of properly configured proxy servers, etc.
To address the second issue, as several others have mentions, make sure that anything that is sensitive is encrypted. Don't allow people to check their email through the wireless connection using imap or pop3, require that they use a web interface with SSL encryption. Don't use telnet for your custom applications, whatever they may be, use SSH. Of course, all that being said, it's much easier to tell someone to never use telnet then it is to actually do it. Anyone care to take a guess at how a typical software vendor supporting legacy applications will respond to the request to make their programs function over SSH?
My $0.02
So let me get this straight, after successfully fooling a user that the site they are seeing is legit when it's actually spoofed, then they can get the results of local search queries, potentially seeing parts of a file. Don't get me wrong, that kind of stinks and all, but if you have already fooled someone into believing the sites they are looking at are legit, why bother with this? Show them a gmail login, or a yahoo mail login, or if you know a bit about them, their internet banking login.
;)
In retrospect, I think I had this wrong. The java app, once connected to, isn't necessarily spoofing the Google page, it's simply faking the process of querying Google. The java applet is querying Google as opposed to a user who thinks the applet *is* Google. Whoops, sorry, feel free to take the insightful mods back
The Rice group was able to create a Java program that makes network connections back to the computer from where it was downloaded and then make it appear as if it were asking for a search at Google.com. That was enough to fool the Google desktop software into providing the user's search information. The program was able to do anything with the results, including transmitting them back to the attacking site.
So let me get this straight, after successfully fooling a user that the site they are seeing is legit when it's actually spoofed, then they can get the results of local search queries, potentially seeing parts of a file. Don't get me wrong, that kind of stinks and all, but if you have already fooled someone into believing the sites they are looking at are legit, why bother with this? Show them a gmail login, or a yahoo mail login, or if you know a bit about them, their internet banking login.
This security flaw doesn't seem like that big of a deal and if anything, it highlights that Google is being proactive about such things; addressing the issue and releasing fixed software in a reasonable amount of time. Kudos.
A few things...
1) The security consulting industry is larger then a lot of people realize. This would be one of the first places to look for beginner level positions.
2) Not all security jobs require security clearance, only government jobs (or jobs that are in some way related to government work) do. There are several industries that require the services of a security consulting company. For example, Financial intuitions are *required* to have independent security audits performed of their IT environment. There are various regulations out that motivate companies to hire security people (GLBA for financial institutions, HIPAA for healthcare, etc.)
3) Security professionals are in more places then you might realize. Any one of the top 15 accounting firms in the nation will most likely have a security consulting practice. There are countless managed security solution providers. There are companies (many of them!) that do nothing but provide real time 24x7 monitoring to their clients. Any one of these companies can usually find use for an intern, especially one that has the information security mindset, and most of these will not require a security clearance.
4) Contrary to what some may have you believe, certifications aren't everything. You can not get your CISSP until you have 3 years of experience (assuming you graduate) or 2 years of experience (assuming you graduate with a Masters). No company that is looking to hire an intern will be looking for that intern to have their CISSP or CISA.
5) Good news, the security industry is booming and everyone is hiring. The company I work for has consistently hired more people every year since I started. Three years ago there were 30 professionals dedicated to information security consulting, now there are about 85, a large portion of which were hired straight from college.
So, in summary, I would focus your efforts on companies that perform security services such as consulting companies (read: accounting firms, and specialty firms like the foundstones of the world), managed service providers, datacenters and various niche services such as real time intrusion detection shops. Start making phone calls, asking if they have a security practice, and who you could talk to about a job. These places are hiring, if you aren't on their radar already, it's up to you to put yourself on their radar.