Tag Info

New answers tagged

1

"Secure Vault" is being used here in the context of tokenization, which almost always means "the Vault that someone else (e.g., your payment processor) keeps the cards in, and you only ever deal with the tokens that correspond to items in the vault." You can, of course, implement a "vault" yourself - that means a data store for PAN data which meets all the ...


0

The risk is you have one key on multiple servers (from what I understand). If it's not encrypted and someone who shouldn't have it got it, then you have a problem. That being said, AES is very safe if used with randomized IVs.


0

I'd say it's more of a performance question, basically which of these database schemas involves less overhead. Either way if the DB is compromised an attacker would be able to easily find the salt for each password hash. Since a salt just protects you from pre-compute attacks, but is needed for authentication, it's difficult and not really worth the effort ...


1

It really doesn't make a bit of difference. The salt in no way needs to be kept secure. There are arguably some very minor security advantages to it remaining secret (since it would provide some protection against cracking trivial passwords), but if your security is dependent on that, then your security is broken. Additionally, the difference between ...


0

TLDR: As long as the network connection to the DB is secure, and as long as salted hashes are stored in your tables, calling a stored procedure with a plaintext password is fine. I think your time and effort is better spent protecting the database from unauthorized access of the kind that makes it possible to obtain a trace of stored procedure calls. ...


7

Trust no one. Use secure strings to hold plain text passwords and hash them immediately. Gone are the times when you can hope your system is secure. It is not. It's just matter of time/money until a determined attacker can access your system. Even when traffic gets encrypted with SSL/TLS I can come up with several scenarios, each leading to passwords leak, ...


1

So it depends on the the trust worthiness of the environment. If you have zero trust in it, perhaps some encryption would be good. Additionally, the low branch set of configuration would probably be to restrict to only hosts that require SQL connectivity, though there are many different reasons why you'd want to open it up to access.


12

SQL Server has the option to encrypt the connection between application and database. When you operate SQL server in an untrusted environment, it is recommended that you enable it. When you do, hashing the passwords before sending them to the database is unnecessary as long as you trust your DB administrator. Additionally, most deployments of SQL server ...


1

From my limited point of view, an attacker would not be able to immediately gain access to the database. The data source in your snippet refers to a database server on 10.#.#.#. The 10.0.0.0/8 network is reserved for private networks according to RFC 1918. If you are an external attacker without direct access to the private Network the database server is ...


1

Just because you were not able to connect directly, this still poses a few problems (will speak on them in a second). Anything and all should always be reported for a few reasons, it is informational, it illustrates that time was taken to analyze information during an engagement. Now there are a few reasons I can think of, for this happening (permissions)" ...


4

First, may I ask why you think the app is not as secure as the website? Generally speaking, from a security perspective, one of the worse things you can possibly do is to involve PHP, which has more security pitfalls then, well, probably all of the other common technologies combined. Additionally: if you're any sensitive traffic from the app to the ...


1

@Craig...good practical sensible answer. Since bruce_bana said that cost shouldn't be an issue than this should be realistic to implement after using @DerekM answer (which is also good) to convince the alleged security experts. @DTK...good business CYA answer. This one I would definitely implement If i was bruce_bana. @bruce bana...try this link from this ...


2

both methods in the questions deal with 'with plaintext passwords', which is a very bad idea. Yet , for illustrative purposes is can help to clarify things. Comparison logic in application: $result = sql_query('SELECT users.password FROM users WHERE userId = %i', $userId); if ($result['password'] == $userPassword) { print 'access granted'; } else { ...


1

Think about it this way: Most system have multiple components. In a traditional set up this is usually a client that is distributed to the users, a server, and a database. The database is usually a commonly used, highly optimized piece of software written by somebody else, whereas servers are very often custom software that is written by you specifically ...


1

Application The application supplies the credentials via the application code logic to the server as a payload of the application's data flow. Database The connection directly connects to the database and issues database commands in order to confirm the credentials.


3

As per MySQL's documentation on the Encryption functions, http://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html Caution Passwords or other sensitive values supplied as arguments to encryption functions are sent in plaintext to the MySQL server unless an SSL connection is used. Also, such values will appear in any MySQL logs to which ...


0

On iOS devices there is the Data Protection API which enables apps to encrypt data so that it is only available when the device is unlocked i.e. after the user has entered their PIN/password, some information here: iOS Developer Library. I think this link will answer your questions, but in a nutshell provided a phone is locked when it is stolen the data ...


0

You could, like Mozilla Firefox, use a "master password" to encrypt "sensitive" data (like the password database). People would need to enter the password on your app before the database of sensitive "stuff" is useable. On Firefox, this feature is off by default (actually the encryption password is hard-wired into the Firefox code). You can have a timeout ...


0

Tell your direct manager that you are not authorized to accept that risk on behalf of the company. Point out that the value of the data in the database is $xxx and that that level of risk acceptance must come from someone authorized to do so, and ask him to champion getting a member of executive management to sign-off on the risk acceptance. To estimate ...


1

One good argument is that the bar really isn't that high to separate the web servers and database servers into separate DMZ's. Use a real router/firewall, and put the web servers and database servers on separate VLANs, both of them outside the internal secure LAN, with firewall rules controlling access to the bare minimum required ports from the Internet to ...


9

If you are suggesting that the database server gets moved from being in the same security zone as the web server to being in the same security zone as some internal systems, then one could reasonably conclude that you are reducing security. If status quo is that web server and database server are both in the DMZ, and no connections are permitted from DMZ to ...


23

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


4

Assuming you are attempting to persuade them to do it rather than (necessarily) convince them it is correct: Explain that when their large customers and prospects come to do a security audit they will fail. If the obstacle is the business then that will be the only sufficient, and only necessary, reason.


14

If the database holds card details, it can be very easily argued that you aren't fulfilling the PCI DSS requirement on appropriate protection. It also fails the sanity checks on single points of failure, and protecting your core assets. If the data is worth billions, why would you not spend a few thousand more to add layers of protection? Industry good ...


5

AvID has already covered the main question, but coming at this from a slightly different angle most firewalls will support multiple interfaces and can provide control of traffic between the interfaces. Configuring the multiple interfaces to host each of the aspects of the solution (frontend, middleware, backend) would reduce the risk of onward compromise of ...


33

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



Top 50 recent answers are included