The Stack Overflow podcast is back! Listen to an interview with our new CEO.
183

Yep, that's a big problem, especially if that was your old password (i.e. not a newly assigned one). Technically, the password might be stored under reversible encryption rather than plain text, but that's nearly as bad. The absolute minimum standard should be a salted hash - anything less and anybody with access to the auth database who wants to can use an ...


128

I would say this is a bit too much trouble considering what you get out of it. I think when the attacker has access to the database you have way bigger problems. Obfuscating the admin status of a user will just cost the attacker some extra time, but an APT (Advanced Persistent Threat) would probably not be deterred by this fact.


117

No. Removing spaces would not prevent SQL injection, as there are many other ways to make the parser process your input. Lets look at an example. Imagine that you had a url which used user supplied input unsafely in a query: http://example/index.php?id=1 => SELECT * from page where id = 1 In your example the attacker would use spaces: http://example/index....


117

You should store it in a single field. Do not try to divide it into parts. I know this might seem a bit unintuitive for people comming from a database background, where the modus operandi is to normalize data and using serialized strings is considered an ugly hack. But from a security practice, this makes perfect sense. Why? Because the smallest unit the ...


106

PCI DSS The major reason for this is a decade long effort by the payment cards industry to limit the extent of such breaches by requiring everyone who handles payment card data to either (a) conform to a set of security practices and (usually) audit requirements, or (b) stop handling payment card data themselves and delegate it to someone who can handle ...


98

General comments. It sounds like it would be helpful for you and your boss to learn some basic security concepts, before proceeding. Security is a specialized field. You wouldn't ask a random person on the street to perform open-heart surgery on you; and you shouldn't expect an average software developer to know how to secure your systems. I sense some ...


83

Yes, they store passwords in plaintext or equivalent, and definitely transmit them in plain text. This was discovered in 2011. This is confirmed HostGator being listed on Plaintext Offenders, as well as by its entry in the CVS file containing a list of offenders. This is not new and has been known since at least 2011. HostGator has not reformed since. The ...


78

The standard approach to this kind of issue is to create a UUID (Universally Unique Identifier) for each picture. This is generally a random 128-bit identifier which you can assign to each picture without any particular concern that it would be possible to enumerate the pictures via a brute-force attack on the namespace. For example in .NET you can use the ...


69

This is security through obscurity. While it might not hurt you in all cases, on it's own it does not provide viable security. Do not rely on this as your protection. A short parable Let's say you keep your money in a jar labeled MONEY in your house. Since you know you sometimes forget to lock the door when you leave the house, you relabel the jar ...


59

One explanation I haven't seen here is that many financial institutions are tightly integrated with older systems and are bound to the limitations of those systems. The irony of this is that I have seen systems that were built to be compatible to older systems but now the older systems are gone and the policy still must exist for compatibility with the ...


52

Think about it this way On one hand, there's nothing wrong with it. If your application is secure enough against SQL Injection, then an attacker won't be able to do much with that information. Unless you're naming your tables table_2231 and your columns column_4231 (in which case I hate you), it's not gonna be difficult to guess your tables names anyway. If ...


52

It makes sense to password protect the database if you secure access to the application's config file that holds the plaintext credentials. When you restrict read access to the application's account only, the attacker requires root access to see the password. In case he breached any other (less privileged) account, he will not be able to gain access to the ...


48

We're in 2016! SQL injections are a thing of the past unless you use insecure code. Whatever language you use, if you want to prevent any and all SQL injections, use prepared statements or any other type of data binding. Prepared statements separate the query from the data, making it impossible for the data to affect the query. To directly answer your ...


48

What you're missing is that hashes work on the original data, minus the original string. When you want to validate a string against a hash, you take the supplied string, plus the original hash data (cost, salt, etc) and you generate a new hash. If the new hash matches the old one, the string is then validated (in other words, the string is never decrypted, ...


47

End users should never get to see the gory details of your environment. Instead it is more professional to show a generic 'Sorry something went wrong' page. At least visitors can see that you have a real error handling mechanism present on your website. However those errors should be written to the mysql error log and should also trigger a notification by ...


41

Yes it is possible, and this technique is widely used. It does have some minor drawbacks compared to stateful sessions: It does not support strong logout. If a user clicks logout, the cookie is cleared from their browser. However, if an attacker has captured the cookie, they can continue to use it until the cookie expires. The use of a server-side secret ...


38

It's like, "Put the jewelry box outside the house so that robbers won't bother getting in for the TV?" Yes, it is exactly like that. If you don't care about the value of the database, relatively speaking, then sure it makes sense to leave it outside - if the assumption is that the application is horridly insecure, but you need to put it up anyway for ...


36

No, this doesn't seem secure. Collisions Mersenne Twister is a deterministic RNG, so it's not suitable for most cryptographic tasks (although it's usage makes sense, because if it weren't deterministic, your approach would of course not work). In this case, collisions would not happen at the stage you assume and base your calculations on. Instead, they ...


35

My recommendation: Don't store passwords in source code. Instead, store them in a configuration file (outside of the web root), and make sure the configuration file is not publicly accessible. The reason is that you normally don't want to keep your passwords checked into the source code repository or exposed to everyone who can view files in your web root. ...


35

The client is the attacker. Walk around your office while chanting that sentence 144 times; be sure to punctuate your diction with a small drum. That way, you will remember it. In your server, you are sending Java code to run on the client. The honest client will run your code. Nobody forces the attacker to do so as well; and you use client authentication ...


33

No, this is not a good idea! As Lukas pointed out in an comment, you want to hash a password, never encrypt it! With your schema, it would be possible to get the plaintext passwords from an database dump without any effort. Don't let that happen!


33

Some of the non DBA workers (DEV, Fraud, analysts ... ) in my organization need direct access to databases to write their own queries. ... PCI DSS requirement 8.7 stats "Only database administrators have the ability to directly access or query databases" The usual way of handling this is to create a scrubbed version of the database, with PAN data and ...


31

DOT's backend Oracle database is down due to ORA-27101. ORA-27101 has a nice explanation here with a useful reader comment stating that it happened to them because the Windows Event log was full. From the output, you can learn that they have Oracle, Java JDBC, Drupal, ColdFusion. You also see some SQL code. With that knowledge you can start digging for ...


30

SANS' "Making Your Network Safe for Databases" (http://www.sans.org/reading-room/whitepapers/application/making-network-safe-databases-24) reads a little dated in some sections, but provides a decent "for dummies" level of guidance in the direction you're after. You could also exhaust yourself poking through the US NIST's resource centre (http://csrc.nist....


30

I would simply use the picture hash. What's the problem with someone figuring out the hash you used? If I think "this part of the url looks like a sha1", download the file and it has that sha1, I was right. But that doesn't make me able to break your «cat security». Even if it was treatable to attempt breaking the hash to figure out the picture, there's no ...


28

Yes - if the malware included a keylogger, for example, it could simply read the master password when you typed it in. The only real way to prevent that would be to have KeePass be the only software running, on a verified secure computer (e.g. no hardware keyloggers, no VMs, etc.) which would somewhat defeat the purpose of having passwords to hand. However, ...


27

Assuming that You're 100% sure that your database server only accepts local connections. You're 100% sure that the attacker doesn't have access to the local environment from which connections are allowed. You're 100% sure that the application that uses the database is otherwise secure. You're 100% sure that those credentials aren't used for anything else ...


27

Letting your database handle the encryption/decryption is probably for the best: You don't need to write any encryption/decryption code and risk breaking your own security by accident. This also means, as Guntram Blohm pointed out, you won't have to prove your own security to be secure, if it comes down to it. And proving your custom software secure is as ...


26

The best placement is to put the database servers in a trusted zone of their own. They should allow inbound connections from the web servers only, and that should be enforced at a firewall and on the machines. Reality usually dictates a few more machines (db admin, etc). Obey reality as needed, of course. They should only be making outbound connections if ...


26

Great question! You are asking the right questions. Short answer. In most cases, escaping at the output side is the most important thing to do. The best solution is to use a web development framework (such as Google ctemplate) that provides context-dependent automatic escaping and automatic defenses against other injection attacks (like prepared ...


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