Topic: Security (Read 1777 times)

It depends, too many (delusional) security layers can be more of a problem than a solution as chances of one of them to fail increases.

Software engineering is all about measuring how much of the security can be given away, actually that's what you do when you switch on your computer: decrease its security, in order to keep the software or site usable without being a high risk at the same time.

security must be simple for the end user, not the developer, as exemplified by the recent events.

Security can't  be simple. I've never seen an online banking site that was simple to use. And for good reason.

Indeed, however it proves the point that password security is up to the site developer, not the person using the service.

Yes, the issue isn't "auditing", rather amateurish auditing and outsourcing. The entities responsible for auditing banks have themselves bank security inside or hire the auditors themselves. A bit different than our common mortal with regular pockets and not up to be bailed out by any government reality.

@Bind,

That one remembered me those guys selling stuff at eBay like iPhone4 20 USD (+450 USD Shipping).

is '123456' a secure password ?



or encrypt rather than hash as has been suggested by some. With encryption you can have a different encryption for each password saved. Like a system $salt, using some account information appended to the salt to use as  a key to encrypt the password:

If you use bcrypt, make damn sure that your system doesn't have the sign extension bug.

Financial institutions (esp those who don't operate on publicly reviewed source) are required by law in most countries to be subject to these types of audits. Not saying that Mt. Gox was, but at some point if they wanted to be an established US business entity, they would have been audited.

Why not just issue users a password.  Two English words with the capitalization varied, a couple of numbers thrown in, and joined by a special character, will foil most password cracking attempts, while still being easily remembered.  If you iterate the password hash, you can multiply the effort required to crack by any desired factor.

Letting users pick passwords is a bad idea to begin with, even if you filter out things like "123" and "xyzzy."




 

that reminds me my ex-girlfriend took 2 minutes to brutte-force my yahoo email account without knowing the password... 

You always have to calculate expected traffic / infrastructure power / kind of use (you don't need bank security for a forum with some guys talking about things that matters to no one) and adjust your site's security accordingly.
There's no such thing as one-size fits all solution.

You can adjust the difficulty so that it takes less time to hash the password (which'll reduce the security though), and in most cases you'll be a tiny small website anyway, so it won't matter. (Most cases being when I said you shouldn't use a general hash.)  If you are getting big enough hits that it matters, you should darn well hire a decent security expert. If you can't afford it, maybe rethink your business model.

Also, what do Yahoo, Google, et al. use?

Michael,

bcrypt may be good or unreliable depending on your site's size. If you get few logins, less than 1 per minute at least, it's quite a good and strong solution for store passwords.
If you've more, you can't simply use it, it will blow away your system resources and nobody will be able to open it.

You don't "encrypt" passwords. You use a one-way hash on them. A non-reversible one-way hash. MD5 and SHA512 are examples of general purpose one-way hashes, and shouldn't be used for hashing passwords in most cases.

A very too the point article "How To Safely Store A Password", the answer is simple: use bcrypt.

Indeed.

(I'm guilty, at the moment, of not following my own advice. I am working on fixing that.)

I did, the issue is, many of them are just valid for paranoia level. How in hell someone would believe his Cats&Dogs site will have a visitor that is accessing MtGox at the same time he's visiting his site to drop a Cross-Site line?
Unless you visit really really darknet unsecure sites, that attack is quite a long shot.

Clearly you haven't actually been paying attention to the flaws that have been identified. I assume you've decided to skip the self reflection. Good luck in your efforts in providing mediocre advice for free to people who didn't request it.

CSRF are so long shot that nearly would make me laugh (nearly, not quite as they're still valid for main frame sites users tend to have open such as Facebook). They would be only possible if the attacker knows that who visits his site also visits X site.
Still, they're quite easy to prevent, just throw a session var with the page where the user is at, if the CS request requests your site to buy something and the user isn't anywhere near a buy form, simply decline. Or add a random verification var along with the forms, or check the referrer...
SQLi unless you have a really badly configured server or in your code the vars jump directly to queries, they don't pass trough, they're too easy to stop.

By doing Audits you add more PEOPLE to your system, this is a major security breach by itself than all CSRF and SQLi possible attacks. But as I said, if you need to do them, at least make sure you know who is doing what and where.

While I appreciate your spirit, most of your suggestions seem to miss the mark that all of these security problems appear to relate to application specific flaws: XSS, CSRF, SQLi. Some of it is just plain bad advice: "Avoid audits". It may be worth some self reflection on whether your skill level is appropriate to be offering sweeping security advice along these lines.

I'm afraid trading sites will just add several security layers, like those folks who use antiviruses bullshit and still get hacked.

Security must be simple, it's all about knowing what the fuck you are doing, not putting more security layers and persuading yourself that now that you use "salted multi-iterated sha-512" you have nothing to worry about.

What you have to worry about, is that dumb fuck who was running audits and opened a virus in his e-mail.

Enough is enough! Having bs around about "weak passwords" with a db dump rolling on the web is way too much!

Want to create a secure web server? Fine! Here's how:

1) use a clean install or a VM and use it just for that site. No it's not OK to give 100Mb for your best friend to ftp his porn there.

2) use a damn strong root password.

3) install just what is needed for the server, remove (or not install in the first place) any unsafe and good for nothing crap like phpmyadmin, webmin, or stuff you've no use for. At the end of the day you should only have a bunch of ports listening and you must know exactly what services/daemons are using them.

4) Avoid audits, but if you are less expert and need a hand, make sure that:

a) You KNOW each person that has access to the system.
b) Your auditor/improver/developer is not outsourcing,risk increases if he's outsourcing to places as safe as China, Vietnam, India and so on.
c) You know what parts of the system he is accessing and for what purpose
d) Make sure he've no access to more data than he needs to perform his job

To encrypt passwords, what it really does?

It's not a magical trick that will make you safe, encrypt passwords will do only one thing: buy you some time to react if your database is compromised (absolutely nothing else).
If your db was compromised and it was plain-text you get 0 seconds to react; the attacker may start to enter any account he wants.
If you use MD5 you earn 5 minutes to a few hours or days depending whether they're salted or not.
If you use SHA you may earn a few days or weeks.

But the effectiveness relies on you to know your system to be compromised in the first place, make sure to drop some wires an eventual attacker may trip on.

THEN, and only THEN you can blame your users for using weak passwords, if you don't stick to this rules, users might well use 123 as password and the fault will still be yours!