New answers tagged

0

usually a user table provides the relational association to content in the actual database. eg user:jon_smith posted this blog post The user table is also the logical place to store login credentials. The problem/question is not 'why is a database storing login credentials', but rather 'why arent people storing hashed values of passwords and comparing the ...


0

So why do we even use full-power database software and SQL queries to handle the pretty limited needs of username & password authentication at all?. Why aren't there limited-purpose database applications specifically aimed at just doing what a password database needs to do, vs. using general-purpose applications that leave lots of room for SQL ...


0

Another angle to symcbean's answer. The whole situation seems rather simplified. Who should take care of what can be queried and what can't? The underliyng DB (using special tables for user storage), the backend of the web application server or even a WAF? What about queries including LIKE statements (i.e. PasswordHash like 'a%', you can see where this is ...


5

There's a big gap between "does not require" and "implemented by the lowest bidder". why do we even use full-power database software and SQL queries Because if you're already running a SQL database for your transactional data, implementing a second technology stack with appropriately trained development and support staff for a very specific function is ...


1

What you want in effect to know that the contents of a request is trusted. For this you would need to trust the remote application and to do this you would somehow verify that the application is exactly your application. This is called remote attestation. But, unfortunately this is impossible unless you lock down everything from start. For this you would ...


2

Your main problem is identifying who are your "real" customers. As the code is open, its easy for anyone to emulate a client. So, how can you do it? You can use asymmetric encryption. As the keys are not inside the code, there is no way they can "emulate" those keys. Each server will have its own keys. If encryption is too much for the client (and the ...


2

JDBC is a Java API. It uses JDBC database drivers to actually communicate with database servers. These drivers may or may not support TLS. The PostgreSQL JDBC driver supports TLS: https://jdbc.postgresql.org/documentation/94/ssl.html So, it would connect to the database server using TLS, then send the username and password to authenticate. You would not ...


3

You are correct to be concerned about the scenarios you presented: If a MITM attack occurs, it cannot be thwarted unless you use SSL. The IP filter will not help because the attack is already "in the middle" of the connection, so all traffic will pass through it in plain text. Once the user/pass is grabbed, the attacker can do whatever those credentials ...


1

After having a client's site go down because of this exact problem, we introduced a somewhat simplistic solution that helped dramatically minimise the effect of such attacks. As phyrfox said in his answer, a FULLTEXT index is a very effective tool for both performance and counter DoS. As we were already tracking visitors for statistic information, we went ...


2

You can mitigate both of these issues by creating a FULLTEXT index. In other words, instead of having the database system read the entire table and scan every character in every field, the system builds an index that can be quickly searched while discarding common words/letters. Your attacker can search for "e" as fast as they want, and the index will answer ...


0

There are a few things that come into mind with regards to DoS via what you described. The first is network based, the second is query based (what is the maximum cut off). The first network based: This will depend on the design or your network. E.g., is there load balancing configured somewhere, do you have multiple providers, do you have filtering in place, ...



Top 50 recent answers are included