Security

[BCEmporium]

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!

[digimag]

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.

[finack]

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.

[BCEmporium]

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.

[finack]

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.

[BCEmporium]

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.

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.

[Michael]

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.)

[BCEmporium]

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.

[Michael]

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?

[BCEmporium]

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

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.

[Enochian]

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!

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."




 

[nhodges]

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.

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.

[kjj]

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

[Bind]

is '123456' a secure password ?

Code: (php)

<?php
$password = '12345';
$salt = 'XlGc9lcVPWaLdps5jBekeFIFOCYlGcqbJ0zuRLno3eXLieDXKnCcBrWdcQwW9qSZev9pbPK8EmdCzBVcoRF5d
hwAEqQAFI7RpWW0HO6eubpYLJ5f3twQyE8oQ7wrgWRYXb2u0sJASNBFE93UQlyN5umOUCvvA5uUq8vpNylX
Br2BlNY0lAW6ySQPIpNBjkjqCj9dfHnmutWOJjCcbZDvuVJyp6jyGIWq6vx6FmyvVMvQ8IWbFUm6Z3e3bKaLkJ
6caVbWoczITlkifhT1Lq4BDgAbiG2Nlnv0Pm6CUxeX42RKoyvOpGwJSWcNsnPqDo6JgIvzdhE7gIeJWNhuUz9Pr
J1efFHQqIyUlQRxtQMC6BkbXBH0HBcNaGeX0e688gW0yv2DTwedRL82dEaIi65hXH5vOimZsQHU2CTBU1e2I
1aYnYYZzw101e7HNxeFBtQFYOVmreXVaZpCqbJ2c6Qvuax3GmTcZNsvddnKGk1ZBsjOl9U8mNbY20Ptzh8UW
Rl13omDT1irlT5h6QFTLqPs1jGcXGL6R65MoHs5v7QBFihnPsZZRYigCka06Lg1tx816Ln2AkiinlBihJYWjlKBqZ5C
sHM5sjnBAb0YshkjlCVkuCrjJd5taZFoy8hmdoMmCHCYwUpksfDuL6M2C6lSJjpjXUXh0ypvxin1sSSTQJ9lRkZ5F
ShbqOi5EWWBbCystP6yzscMcZN8qV5jajfNta9GvucDRZjO3Ke9qzuxvKL8GHBAM2j3L6iV5BLHEiczd73IL3eiV1
varoxcsCEpSJsxGN8SMr7EiTfCAeqQZ3fxcSkpM17OnhUcF0WXqPFGopChAHKXYkL3DtfphbbofZT8VQUDdQtXZ
c1ZLp8UBVuslx0pkWWkHjdFJ0029A0GMXHUiVwjY2PUHnx2ZbB2ajcdJXVpzPswNQHiGXTeDWEX9m9Tjd3AzlP
wiWH3zk1jHYHa9dzq6U8wxdLxNpHjOX721aEBvej3vcTWdrHVuEQiVHDv66DLy7NAudEtQQ8ch8kzFE1SpPYltp
2N3JYRdA9mmPpAdBk8onmMDKXA8YZUCWwmPetheCh8ELiiLm8VJ6oB0kPO3rmzAg47vEq5AQlzh78HGOvlrL
RaZDnpiPCu1dPYH7LJuvn5NEwZ5dY3F8vJ8ZzZDyI8ZvSiBTp7xQ3CwA9i1trcHySXjcCbHDx07LkqdMU3MJUXL
xxyPfw6jv0tdtfMoNJM6QFDMOjSpHJ6nGYLGzZhrhrBUpcntOJGjzjey8hqoZcXyfEwsrpET5ypMj2cz362SrvXJ4s8
x6LhSf7BMWb9zjU3EJa6jm48KSlyKB2qLkPUBkY3jnIlMW6c7f5YG3ljdsbGG1KsxN97b6MmnPTwQrIUfxXcNl9jz
G831HQWKAr';
$pass2db = sha1($password.$salt);
?>

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:

Code: (php)

<?php
$encrypted_password = mcrypt_ecb (MCRYPT_3DES, $password.$salt.$email.$name.$ip, $password, MCRYPT_ENCRYPT);
?>

[BCEmporium]

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.

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).

[Bind]

@Bind,

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

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

[Timo Y]

Security must be simple

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

[Bind]

Security must be simple

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

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

[BCEmporium]

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.