Hot answers tagged

57

Recently, at the OWASP AppSec 2010 conference in Orange County, Bill Cheswick from AT&T talked at length about this issue. In brief, there's insufficient research. In long, here are some of his ideas for less painful account locking: Don't count duplicate password attempts (they probably thought they mistyped it) Make the password hint about the ...


50

Risk In the worst scenario, it could render website completely inaccessible for the users, it could perform particular actions as them (for example, requesting account removal, spending money) or it could steal confidential data. Prevention Can't be done. If you run someone else's JavaScript on your website, it becomes no more secure than that ...


40

You would never ignore a threat, and perhaps that is semantics over your wording. You either accept, mitigate, or outsource the risk for the given threat. In this case, that would be: accept that there will be a $X loss, mitigate fix DRM or find DRM alternate to protect the product, or outsource using insurance or place the risk on someone else in the ...


38

Like most embedded hardware (routers, etc), their firmware often sucks, and unless you have unlimited time I'm afraid there is no way to thoroughly check every single camera out there. And even if you do find one that's currently secure, what guarantees that you'll get updates for vulnerabilities that will be discovered in the future ? Instead, I suggest ...


34

Any website that complies with PCI Data Security Standards has to adhere to sections 8.5.13 (Limit repeated access attempts by locking out the user ID after not more than six attempts) 8.5.14 (Set the lockout duration to thirty minutes or until administrator enables the user ID). This is unfortunately why a lot of sites accepting credit cards have ...


24

Paranoia, professional skepticism, risk management... sometimes these concept are hard to separate. The odds that somebody is reading my packets right at this moment are relatively low. The odds that somebody has sniffed my internet traffic at some point in the past year... I guarantee it has happened, I've been to DEFCON. The advent of wireless networking ...


23

I see two sides on this: most government bodies I review/audit tend to believe that because they secure everything then they are the most secure and that is the way it should be! In actuality the organisations that go down the security nazi route usually end up more open than those who are pragmatic about it. For example, locking down your users too hard ...


19

My experience is lock out mechanisms are diminishing in popularity (at least for web apps). Instead of locking accounts out after a series of failed attempts, you begin to ask for additional information for successful authentication.


17

Yes, I think it's possible to be too paranoid. Although, also, I just finished talking security with a bunch of performing artists - people with no money who really need to spend their time promoting their work and creating new work... not building the Fort Knox of security just so they can use Facebook. They need common sense, a basic understanding of ...


14

I agree with the OP. If you think about what the lockout protects you against, there is no difference between 3 or 20 attempts (or 100, for that matter). All you achieve with these lockouts, apart from punishing forgetful users, is to prevent a brute-force attack. You can also user it to trigger a warning that an attack is on-going, but that isn't the ...


14

Wouldn't be surprised if it came from the baseball "Three strikes" rule rather than anything technical. One justification (for alphanumerics passwords anyway) is Typically a failed attempt is either a mis-type or a CAPS on/off issue. So you try to log on and get rejected (1), try again because you think you mis-typed (2) and then realize the CAPS key is ...


13

So I have to admit that my first reaction was "I would never do this." That, however, may be more because I, historically, don't like to let anybody know anything they don't need to, than for any real security reason. So that said, the only security issues I can think of are fairly limited, and fairly esoteric. It could be used to find a DoS or DDoS ...


13

TL;DR: NO (but we should define what "ignoring" means; from the text of the question I suspect we're actually of the same opinion). You do not "ignore" a threat. The ancient saw says that you do not fear a threat that you cannot avoid - stultum est timere quod vitare non potes, since fear will avail you nothing. But few threats are completely unavoidable ...


11

The short answer is this: No, CentOS 5.6 is inherently no more or less secure than any other modern supported operating system. The long answer is a bit more complicated. CentOS is the "Community" release of RedHat Enterprise Linux (RHEL). The differences between the two are fairly small so you can think of them as functionally equivalent, see the Wikipedia ...


11

This is such an astonishing question that I find it difficult to answer. This distrust doesn't come from theory, but from experience. When we say "FTP is too dangerous to use" is because we've found it, in practice, too dangerous to use. You seem to think that a "packet logger" is either difficult to obtain or difficult to use. Neither is true. It takes ...


10

Short answer: Yes, computers can get a whole lot wrong before any human can realize that there's a problem so "trust" just doesn't work in computer systems. Default distrust is the only viable posture for high-performance system. To explain why, I'll contrast interactions between computers to interactions between humans. In human interactions, default ...


10

If you read Schneier, you'll be familiar with one of the basic premises of "smart" security that he also pushes a lot: Security is a Trade-off. It simply does not make sense to go full metal paranoid on your systems, since security can NEVER be 100% anyway (we used to be told the only way to be 100% is to unplug the computer... now we know that's ...


10

The way to look at which is better for you is to work out what your risk appetite is. If you must have service at all costs then you don't want to fail closed, as any problem with that IPS will cause a Denial of Service. That is a very rare scenario though - the majority of implementations are configured to protect the server and the data on it. This is ...


10

This started off as a comment on Andre's answer, but it got a bit long. USB is fine as long as none of the cameras are more than 16 foot from the host :) Since you need to run power out to the cameras anyway, just run a wired ethernet connection to the LAN (or use POE if you can find cameras which support it). On an un-routed subnet, most of the inherent ...


10

There are four basic strategies to control risks: Avoidance: Applying safeguards that eliminate or reduce the remaining uncontrolled risks for the vulnerability Transference: Shifting the risk to other areas or to outside entities Mitigation: Reducing the impact if the vulnerability is exploited Acceptance: Understanding the consequences and accepting the ...


9

I believe I'm late to this debate, but I hope I have something useful to add here. The account lockout policy (with the number of consecutive invalid attempts usually in the range of single digits for most organizations) was not devised solely against automated brute force attacks. It is more of a protection against password guessing by human attackers, ...


9

EDIT - Modified this answer slightly (now three parts) Low Budget Version Pick up a used router (laying around the house?), install dd-wrt on it and turn off the WiFi. Bingo, ready made 4 port switch. You won't get PoE for the cameras, but, if needed, that's easily rectified (pun intended) with a PoE adapter or just wall warts. Run a VPN on the dd-wrt ...


8

There are two aspects to this; the first, as you mention, is preventing brute-force attacks. For this purpose, really any number of tries should do - 3, 5, 20, 2000... with a proper password policy (length+complexity+...) giving a large enough key space, any kind of throttling (X number of tries per hour) will ensure that brute forcing the entire space ...


8

If some people have put some hidden backdoors in your system, and if they were competent at it, then you won't be able to find them. "Competence", here, means "having an Internet access and typing 'rootkit mac os x' in Google". See e.g. this. It is theoretically impossible to completely hide a backdoor, but only in the same sense that it is theoretically ...


7

I can tell you why I act this way from personal experience. Here is what I have experienced in my life: A friend of mine didn't trust her boyfriend, and installed a snooper on her network. It was some commercial product she just installed on her windows laptop. When he came to her house with his laptop, she was able to get all his plaintext logins. When ...


7

There's always going to be hackers that do these type of things because they can. The extent to which that pool overlaps with those with malicious intent is the magnitude of the concern, I think. Like anything else in medicine, there is a tradeoff between costs and benefits, so if the convenience to the patient and power to control dosing and other ...


7

What's the worst thing that can happen? The third party can do anything that you could do with JavaScript - or anything an attacker could do with XSS. This includes stealing cookies, injecting a JavaScript keylogger, bypassing CSRF protection and thus executing any request you could execute - eg adding a new admin user -, or changing the content of ...


6

The fundamental deference between the two methodologies is that GAIT is qualitative while FAIR is quantitative. Bottom line, GAIT is another one of those methods such as SAS70, SOX, Cobit and the rest that will end up to be a checklist exercise that will tell you nothing about your security or what the monetary value of your IT risk is.



Only top voted, non community-wiki answers of a minimum length are eligible