![]() Monetization opportunity!) an Emby supplied HTTPS certificate that their thick client apps will just recognize and be cool with. What this would let you do is provide (perhaps just to paid subscriber people. It's more secure (because you're only trusting one CA and not the whole list of foreign governments in the default CA list) and more convenient. It effectively bypasses the main weakness in HTTPS: The certificate authorities. The idea is that rather than using the Certificate Authorities built into the platform, you create an Emby CA, hardcode its public key into the thick clients (Android app, Roku app, etc.), then have the client validate against that CA. Though that can be considered separately from the question of how to store credentials in the One option to consider for for certificate validation on thick clients is certificate pinning. HTTPS being mandatory would be a great step forward for security. No amount of client side hashing can solve that problem. Good comments! For sure, the only way to ensure confidentiality when submitting user credentials is an end-to-end encrypted channel. Remove the client side hashing functionality, submit passwords in plaintext to the server, and securely hash and salt passwords before storing. If ever a user's password hash is compromised in any way, an attacker can hijack the user's account by replaying the password hash back to the server. The password hashes themselves have become the effective password itself. This defeats the entire purpose of hashing passwords at all. This represents a security vulnerability.Īn attacker who compromises the database no longer needs to crack any passwords at all. (In JavaScript, for the web interface) This password is then stored directly into the backend database as is. ![]() For security against eavesdropping, an HTTPS (or other encrypted connection as necessary) connection is required.Įmby, however, hashes the user's password on the client side. The server then securely hashes this password and stores only the hash in a backend database for later retrieval. The standard model for providing credentials from client to server is for the client to send the password in plaintext to the server. Google Security Blog: Deprecation of SHA1 ![]() Instead of SHA1, use a modern password hashing algorithm which has been specifically designed for the needs of password storage such as bcrypt, scrypt, or PDKDF2. This is a trait that only helps attackers as they attempt to crack password hashes. SHA1 is a hashing algorithm designed to be processed as quickly as possible. The SHA1 algorithm is unsuitable for password storage. Note that if you choose to use a hashing algorithm like bcrypt (see below) salting is already taken care of for you. Salts must be generated using a cryptographically secure random number generator, and appended to the plaintext password before hashing. Without salts, attackers who gain access to password hashes (via eavesdropping on the network or by compromising the database) will be able to reverse the hash into the original password very easily. Salts ensure that every user's password hash is unique. When password hashes are stored in a backend database, they must be salted in order to prevent against precomputation attacks. Emby user passwords are insecurely stored using an unsalted SHA1 hash, processed client-side.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |