Answer the question
In order to leave comments, you need to log in
What is the best way to securely store critical variables?
Good morning everyone.
In connection with recent events around the well-known site and its code, I wondered how then it would be more correct and preferable to store such values ​​as secret keys, payment information, etc.?
The database is not suitable, because it is more vulnerable than hardcode. So far I have found only two options:
- Collect in php.ini (here, apparently, you will need to build php with your own parameters)
- Store in server configs. But if you need to change, the server will have to be restarted
Answer the question
In order to leave comments, you need to log in
Understand that all the leaks that occur - in 99% this is not an exploit, but a stupid human factor.
All solutions with server configs, ORM and other things are absolutely meaningless when your system administrator is presented with a new X6 and he will merge the entire server dump.
The only thing that can be done is to minimize the number of people who have access to really critical data at the project architecture level, and to check these people properly.
Ideally, create a situation where the leakage of any data is impossible without the collusion of several such trusted people and, again, regularly check these people with the Security Council.
Your company is writing a well-known multi-messenger that works on a certain protocol with external services.
In order to connect to them, you are forced to store logins and passwords from the external network somewhere in an unencrypted form.
It is clear that if you just put them in the base, everything will leak right away.
We write a storage that gives associated logins-passwords from an external service using a login-password from our multi-messenger.
Only 1 person in the company has access to changing the storage and to the database in which all passwords are located. The rest stupidly walk through the storage room. There is no way to get a complete list of service logins and passwords.
The first solution is good in principle, but the person who has access is bigboss and is a little tired of personally dealing with this magical server.
Solution 2:
Duplicate solution 1 on N servers, each password is spread over N servers.
The initial store is engaged in the fact that it collects data from N stores from N servers.
Divide each password from an external service into N parts (N >= 3)
Each server has its own responsible person. Only the responsible person and bigboss have access to each server (in case of emergency).
The solution is quite expensive both in terms of people and hardware and in terms of speed of work - but in my entire career, I have not seen anything better.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question