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


82

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


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


25

He is the Data Owner. Not you. If you get hit by a bus, he will need access. You should absolutely give him access. This request is not a surprise at all. If you built a website for me, I'd ask the same. BUT, and this is the important part, you also cannot be competing with him for the administration of the database. You are the administrator, not him. He ...


18

Yes, such a system exists; it's called Application-Level Encryption. Under that system the encryption keys (or at least the Key-Encrypting Key, or KEK) are only available to the application. Data is encrypted by the application before being stored in the database, and encrypted blobs are retrieved from the database to be decrypted by the application. The ...


17

TL;DR No, your friend is not right. INSERT, UPDATE, DELETE and DROP TABLE aren't the be-all and end-all of SQL risks connected to SQL injection. The very simplest thing I could do with that query is ask repeatedly for a user by the name of SLEEP(3600) (or john' OR SLEEP(3600)=') and, voila, denial of service (as soon as the available connection pool is ...


11

Generally speaking, you shouldn't ask and hold user data (especially PII) that you don't need, this is even more true now under GDPR (if it applies in your scenario) but it's always been the case in security. The lesser the data, the lesser the risk. When you hash passwords, you lose knowledge about its plaintext version and the fact that you're asking ...


9

When your organization is subject to the GDPR, then it should have a designated Data Protection Officer. This person is responsible for ensuring that data protection laws are applied within the organization. This should be the first place to report to.


6

Been in this position a million times. Just explain that he could inadvertently break something if he's not careful and give him the logins as he does own it. Make sure to do a db dump before so you can restore if he does break it (for a fee of course).


5

Yeah, "designed to operate in a trusted environment" is a fairly common thing for backend servers, though you usually see it as justification for not using TLS between services, or for new nodes to join the cluster with no auth. In the Redis case, they are using it to justify a port with no auth by claiming that an attacker would need to be able to ping the ...


4

Step one is to never store the password in the webroot. You allready got that covered. Good! Step two is to not store the password in PHP code. Your code base should be free of secrets, be it in class constants or anything else. That let's you commit it to version control, make backups, share it, etc., without second thought. Keeping the secrets out of the ...


3

On a database server, two different admin accounts can exist: the system admin account(s) and the database admin accounts. @gowenfawr's answer already addresses the database admin case, so I will focus on the system admin one. In that case, you have lost. It is not possible to protect a machine from its administrator, because they have a full access on any ...


3

but what hashing key should i use? md5 or sha1 are not considered secure. sha256 produces bigger output than the key itself so it seems like it doesn't make sense to use 128bit key with sha256 It's okay for the output hash to be longer than the input being protected. Sha1 and Md5 are both deprecated for certain applications, so probably best to avoid ...


3

In theory, it should be safe to use MD5 here since it is only vulnerable to collision attacks, not the much more dangerous preimage attacks which would be required to forge an API key. However, it's certainly not a bad thing to avoid MD5 on principle, since it looks bad for auditors. Assuming the value you are hashing is randomly generated and is not a ...


3

Adding encryption on its database per-field or per-group-Of-field basis seems like the best trade off provided that an index field(s) is also created alongside with each field being encrypted. You would solve several problems at once. Searching index would be just as fast Not all fields need to be encrypted Overhead of encryption is kept to a minimal ...


2

Having separate database users (with separate passwords), in addition to the root user, is good practice. This allows you to protect the data for each database, so that if the password to one database is lost, it doesn't compromise the data in the other database. And you don't have to use the root password anywhere, except when doing database maintenance. ...


2

Threat Modeling Here is the question you need to answer first: "What is the most common way passwords are stolen?". Sometimes security measures can't help but present trade offs in one way or another, so a more "secure" method is only "better" if it protects you against the most likely threats. So let's consider where passwords are most in danger. ...


2

The bells ringing in your head are correct and I would be right there with you. This is a bad practice and I am afraid I have seen it done many times. Here are some vulnerabilities and threats that come to mind with exposing a database to a third party and the public: Authentication via username/password is weak and subject to brute force attacks and ...


2

There is no point in sending up the files encrypted to then have the vendor decrypt and process them. If you don't want the vendor to access them then the only options are to not send them up in the first place or send them up encrypted without giving the vendors the keys. If the vendor can decrypt the files then, by definition, they have full access to the ...


2

You should review the agreement with him (if you've any) and clarify such things. If he fully pays for the servers and you've created the website with full rights transferred to the client, I don't see the reason why you shouldn't give him the credentials as in few years time you could be busy with another project, and he can find another company working on ...


2

The first question you need to ask yourself is, does your service need the email address in the first place and what does it need that email address for? If you don't need the email address, then don't store it. If you need to know the email address, and if all of those needs can be satisfied by a hashed version, then it sounds like a good idea to store ...


2

This White Paper from SANS discusses network architecture and the use of a DMZ: https://www.sans.org/reading-room/whitepapers/bestprac/infrastructure-security-architectureeffective-security-monitoring-36512 The PCI DSS is related to cardholder data but, if you substitute 'sensitive' for cardholder, the guidance is pretty good - see requirement 1.3.6 Place ...


2

Yes! This is fantastic practice and a core element of modern security. What you’re describing is security engineering at its core: that is, taking 2 problems (developing and securing a product) where some may only acknowledge 1 (the former) and solving both simultaneously. As with any economics, good security engineering makes it cheaper and easier and more ...


2

Unsure where this is really relevant, but what you describe looks like a separation of concern. It is used for example in Java with aspects. The developper code the business rule classes without worrying about the authorizations required to run the methods. Then the authorization rules are implemented in an aspect, basically wrapping the methods. The well ...


2

This is not safe to do. Do not expose MySQL servers to public access. Any user with SELECT access to a MySQL database can execute a denial-of-service attack by performing queries which generate excessive CPU load. A simple example is SELECT BENCHMARK(1e20,1); performing a series of CROSS JOINs between large tables would have a similar effect. Allowing an ...


2

If the company rep's response is true, the Password is stored as an encrypted text. This makes the plain text password in unprompted email a bigger concern. is it safe to assume that my password is stored in their database as plain text? The company representative explicitly told that they are not storing the password in plain text. Assuming that he is ...


2

My threat model is as follows: A legitimate admin account's username and password is compromised. Our attacker uses that account to log in remotely and download the database. Any remote connection to your network should be protected by 2FA (Especially any admin connection). This would mitigate your threat here. Furthermore, depending on the business needs ...


2

No. You do not need to add a salt to an API key's hash. The API key should have been created from a high entropy random source, capable of resisting attacks that attempt to guess future keys based on past keys. Most passwords are created from very low entropy sources: Users. Additionally, most passwords will also be reused, so there's value in pre-...


2

No, from VirusTotal support: VirusTotal inspects items with over 70 antivirus scanners and URL/domain blacklisting services, in addition to a myriad of tools to extract signals from the studied content. If the attack you received was a SQL Injection, the best you could do is to fix the vulnerability that let the attacker to inject malicious code in your ...


2

There are several freely available threat intelligence feed around. See e.g. https://threatfeeds.io/ Do note that such lists are ephemeral in nature. Which IPs are currently being used for malicious activity is ever changing, and the information generally decreases in value as soon as it is openly published. For this reason, most high-quality threat feeds ...


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