Tag Info

New answers tagged

1

Possibly, yes. In many typical configurations, where servers have not had extensive security hardening, it would be possible. Factors that might permit this: The application server would naturally require a network path to the database server, therefore any firewall would be configured to allow connections. The application server is likely, in a typical ...


4

Could there be some miscommunication between you and the IT department head? As Xander had already pointed out, such a scheme does not work, and I would even add that it is ridiculous. In order to authenticate a user, a database lookup has to be performed on the login email address in order to retrieve the corresponding hash used for comparison: SELECT hash ...


9

As far as I can tell, this scheme doesn't make any sense. As you've noted, you still need to store the plaintext email address for the user, so there isn't any significant security benefit to using the plaintext email and email + password + salt hash vs just using plaintext email and password + salt hash. As I'm sure you've already noted, without the ...


2

No, your understanding of TDE is not wrong. A user with the appropriate permissions on the SQL Server instance can access the data in the database, and with SQL Azure, even if TDE were enabled, the DBAs in charge of the instance would certainly still have full access to the data. What can you do? Well, you can encrypt the data in the application before ...


-1

Addslashes you will fall in the all mighty encoding... Its basicly a skill war in terms the one that knows more.... Thruth is we say it like that because its sopose to make ppl like you do what your doing unfortunatly in the incorrect place lol. Since the point is to you to learn how to write decent code and not just copy a recepie i will leave some hints, ...


0

This is quite similar to Protect database data from everyone, including sys admins, etc. Your second option doesn't work (at least in isolation). Just knowing the health info data may be "bad enough" (and indirectly matcheable to the user). It may be interesting to additionally hide that relationship, but I'm not convinced it's worth doing it. The second ...


2

Even though noSQL databases are on the rise, the vast majority of web applications still use some kind of SQL database. The basic SQL features are standardized, so many simple SQL queries work on any SQL database. I doubt there is any database which calls itself SQL and doesn't understand password = '' OR '1'='1'. So in many cases it isn't even required to ...


0

well it depends on so many things i will be "including some" . 1 web application most web attack are based on scanning lets take the Wordpress as an example you are trying to inject the database of an Wordpress based website .. & wordpress is not sql-I vulnerable but perhaps the plug-ins are vulnerable . you make a scan for the plug-ins installed on the ...


5

There are three common ways to deal with the variety of databases out there: Many web applications are tied to a specific database backend, rather than being able to use a variety of backends. For example, if someone's using MediaWiki, you know they're using either MySQL or MariaDB. An attacker can attempt to generate an error condition, then look at the ...


1

Short answer : you don't. Private keys are , by definition, meant to remain private. If you need to store a secret for each user, the odds are symmetric encryption is a better fit. You should edit your quetstion with more details about what you're trying to accomplish. If there's a flaw in your design as I guess, we can provide you advice to make it better. ...


0

To disagree with previous comments. It is OK (but highly unusual) to store private/public-key-pairs in a database, depending on your infrastructure. We could talk about special Identy-Based-PKIs for example. So, what you need to provide, is more information about your infrastructure, to get a proper answer. However, as you gave the two examples: "encrypt by ...



Top 50 recent answers are included