New answers tagged

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


4

The "common solution" you mentioned has one glaring and obvious flaw: it can't use salt. If your hash has a salt (it should), then you need to fetch the salt before performing the hash operation. And if you're fetching the salt, you should just fetch the hash result at the same time. In fact, the two are typically stored in the same string. Ideally, you ...


3

Assuming that your stored procedure uses something like bcrypt with a secure salt and many rounds, I see no problem with what you are implementing. Your basically treating the database as an identity provider in a federated identity system where the applications are PHP applications. That said, I see no reason why you would do this. PHP has builtin ...


-1

Is the stored procedure doing salting, and multiple rounds of secure hashing? If you don't implement this right, it could effect DB performance and your security. There's a LOT of libraries out there in pretty much every web language to handle secure authentication. Using a stored procedure is a good idea when authenticating the user or interacting with ...


3

You need to figure out if the parameter is being parsed as an integer or a string (most probably as string). If the query is balanced and successful, It won't die(). try .. 1' order by 1-- - or .. 1 order by 1-- - If the first one returns an error, that means the parameter is being parsed as an integer so you don't need a quote (') to perform the ...


0

There's another aspect to this discussion beyond the technical: if it is your design to not secure passwords, then you, as the service operator, are responsible and liable for them. Passwords are security measure for individuals. They aren't the property of the service. If passwords are properly secured (hashed, etc.), then the service operator has done its ...


0

There is a slew of reasons you shouldn't plaintext store passwords. I'll go through some of them (since realistically you should only need ONE reason not to do it - it's not hard) travel - at some point your password has to be read from the database and that requires it to actually GO somewhere, having the passwords not in plaintext grants another level of ...


5

To make it simple, if passwords are in plain text, the security would be compromised by anyone having a glance at it. Now, you need to remember that website log-in isn't the only access to a database. An attacker might be able to get some information from your database in various ways. First you need to know that it happens. And a hacker typically won't ...


2

Why should I don't store passwords in plaintext? There are 2 main reasons: If a database dump is obtained, attackers can simply login with the plain-text password in the dump. If the passwords were hashed, the password would first need to be brute-forced. Lots of users reuse passwords, as bad an idea as it is, so your security failure could compromise ...


0

What would be ideal would be for gmail to scan your mail and when placing it in your inbox encrypt it with your public PGP key. That way, they get to accomplish their goals per their agreement and the user has the assurance that their e-mail is encrypted and safe on disk when it is at rest. The added benefit is the user gets the benefit of security and ...


1

I would say that this adds nothing to security. But if you cannot (or do not want to) rely on schemas to separate your tables among different applications, using different prefixes allow different applications to share same database without risk of conflict. But is adds no real security.


5

In widely adopted DBMS-based systems like WordPress, it's common practice to configure an instance to use table names like my_fav_prefix_posts in place of wp_posts. Why? It purportedly slows down script kiddies. A few years ago there was a spate of mass attacks on WordPress instances. Unsophisticated cybercriminals (script kiddies) used unsophisticated ...


66

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


19

No, it's snake oil. When someone finds an SQL injection vulnerability in an application, then not knowing the table names is only a very minor hurdle. Many stock injection payloads (like the good old universal password ' OR '1' = '1) do not even need to know any table name. And if the attacker discovers a way to dump data from arbitrary tables, they just ...


0

Security of a database system, or any system for that matter, is about more than simply which type you use. Who has access, is remote access possible, can root login remotely, is there a web interface, and if so, is it secure against injection attacks? There's hundreds of factors. You could try asking a more specific question.


0

The 3/2/1 principle Keep at least three copies, in two different formats and at least one of them must be in a remote geographic location. Why? Number: First one is your working copy. It may get broken anytime. Virus, ransomware, hardware failure... Then, you'll go to your backup. It should work. But! If it doesn't? That's why you have at least two ...


3

Mike Ounsworth answered this to an extent, but I will chime in here. What are your requirements for backups? Do you need to follow any regulatory controls that have specifics? For example, HIPAA/HITECH had specific mandates for 2 years. If so, that is your final answer regardless of what anyone here can tell you. As for full backups, is there a ...


10

I feel like random people on the internet are not going to be able to answer this for you. This is a business decision. How valuable is the data? What is the risk of loss / corruption vs the cost of more disk space? Imagine your worst disaster-recovery scenario, how far back would you need to go to get a clean snapshot? I certainly can't answer any of this ...



Top 50 recent answers are included