Scope: managed applications, mobile applications, and ordinary applications.
1. When you develop subsystems that interact with various external resources (email, web services, FTP resources, and other), it is required to request and pass authentication data to these resources: a username and a password.
2. To minimize risks of unauthorized access to passwords, avoid storing passwords or any other confidential information in the infobase. The weakest protection level is provided by file infobases where files can be copied fully by any user. In client/server infobases, access to databases is available to DBMS administrators only.
That is why pass user credentials immediately without saving them to the infobase.
3. In some cases, this approach might not be applicable:
- Interactive request for credentials for each operation might significantly degrade the user experience. Temporary saving on the client side is insufficient.
- Interactions with various external resources must be performed on the server side no matter how actively users operate in the application.
In these cases, it is acceptable to store passwords and other confidential information in the infobase but notify users about possible consequences. Note that such password storage method does not solve all security issues as unauthorized access is anyway possible.
3.1. Avoid storing passwords and other confidential information in attributes of metadata objects used in day-to-day activities. To store this data, use a separate metadata object (for example, an information register) and grant secure access to it at the level of 1C:Enterprise access rights system.
3.2. If Standard Subsystems Library is used in the application, use a safe password storage, which solves the following tasks:
- If users have access to a metadata object, they can read a password inside an attribute. Such case is impossible if you use a secure storage. To avoid unauthorized access to a secure storage, receiving and writing of data (passwords) are available in the privileged mode only.
- Data is stored in a secure storage in a closed format, unauthorized access is impossible.
- Secure storage is excluded from exchange plans to prevent unauthorized disclosure of passwords from the infobase upon data exchange.
To manage a secure password storage, use procedures and functions of the Common module: WriteDataToSecureStorage, ReadDataFromSecureStorage, and DeleteDataFromSecureStorage. For more information, see comments to these functions in SSL and Section "3.4 Core - Usage upon configuration development - Secure password storage" in SSL documentation.
3.3. Avoid storing passwords in form attributes. Access them only on the server side and immediately before you use them. Otherwise, upon opening a form with masked input (or view) of the password, the password is transferred from the server to the client openly and can be accessed by malicious users. A privileged mode is set right before calling functions, not inside them to avoid receiving and writing passwords in a session with any rights. Call security must be ensured by a calling code that accesses particular passwords.
To mask a password, insert the following code in the OnCreateAtServer event handler:
SetPrivilegedMode(True);
Passwords= Common.ReadDataFromSecureStorage(Object.Ref, "Password, SMTPPassword"); // Password, SMTPPassword: data correspondence keys in a secure storage
SetPrivilegedMode(False);
Password = ?(ValueIsFilled(Passwords.Password), ThisObject.UUID, "");
SMTPPassword = ?(ValueIsFilled(Passwords.SMTPPassword), ThisObject.UUID, "");
In the OnWriteAtServer event handler:
If PasswordChanged Then
SetPrivilegedMode(True);
Common.WriteDataToSecureStorage(CurrentObject.Ref, Password);
Password = ?(ValueIsFilled(Password), ThisObject.UUID, "");
EndIf;
If SMTPPasswordChanged Then
SetPrivilegedMode(True);
Common.WriteDataToSecureStorage(CurrentObject.Ref, SMTPPassword, "SMTPPassword");
SMTPPassword = ?(ValueIsFilled(SMTPPassword), ThisObject.UUID, "");
EndIf;
where Password and SMTPPassword are form attributes. If a password was previously saved to an application, assign a unique form ID to an attribute to simulate the password availability. If you write an object in a form and another password is entered, write it to an object and rewrite the form attribute with a unique ID.