How does emby store passwords?

[abeybaby 0]

When I reset my emby password, I get my new password emailed to me in plaintext. This isn't even a temporary password either, you are encouraged to change it but it is not mandatory at login

 

This suggests emby is storing passwords in an unhashed form (otherwise they would not know the password itself and wouldn't be able to email it)

 

Given the recent hack at Plex, security should be top of our minds, that's the only reason I'm asking

 

Also, is the password for Emby forums and the emby web client the same?

[Koleckai Silvestri 1151]

Emby uses the same forum software that Plex used to use. As such, they are most likely using the same hashing scheme. Latest published methodology for Invision Power Board is:
 

$hash = md5( md5( $salt ) . md5( $password ) );

However I don't think Plex was actually hacked via the forum software, that is just what they stole.

 

Someone else would have to answer the other questions. However the lack of security with MD5 hashes is one reason why I don't use Emby Connect. Hopefully they use Blowfish or some other system that is more secure.

[Luke 39847]

We don't store in plain text. The behavior you're describing only applies to the password reset function, where IPB emails the random password before hashing and storing. However, your suggestion of a mandatory password change at login is a good idea and something we can look into.

[abeybaby 0]

However I don't think Plex was actually hacked via the forum software, that is just what they stole.

 

 

Actually Plex confirmed they were hacked via their forum software.

 

https://blog.plex.tv/2015/07/02/security-notice-forum-user-password-resets/

As we had suspected, the attackers gained entry via exploiting bugs in the forums software, some of which may not be well understood or publicly disclosed, or have patches readily available.

What made the Plex hack so bad is that they had a ridiculous policiy whereby you could only log into their support forums using your Plex server/Plex Web username and password - you couldn't have a separate login just for the forums, Thus when the forum was hacked, all the Plex server users info was also taken.

 

Luke - thanks for the info 

[ebr 15610]

They also don't have Abo keeping on top of every forum software patch .

[SonicYonex 0]

We don't store in plain text. The behavior you're describing only applies to the password reset function, where IPB emails the random password before hashing and storing. However, your suggestion of a mandatory password change at login is a good idea and something we can look into.

Are regular passwords stored salted and hashed then?  And are they in some form of database or flat file?

[SonicYonex 0]

Are regular passwords stored salted and hashed then?  And are they in some form of database or flat file?

I created a user with a password of "password", found "C:\Users\SonicYonex\AppData\Roaming\Emby-Server\data\users.db", opened with a sqlite editor, and the password listed for the user is "5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8" which matches a SHA1 hash result when fed "password."  So no salt, it's just a straight SHA1 saved in a regular column.

[ebr 15610]

Emby Server does not salt passwords but this forum software does.

[runtimesandbox 160]

I see it's still the case that SHA1 is used to hash passwords. Could Emby look in to migrating to a more secure hash format (bcrypt / Argon2 / PBKDF2) and implement salting?

 

There are even .net libraries out there that could be used 

 

https://github.com/BcryptNet/bcrypt.net

https://github.com/neoKushan/BCrypt.Net-Core

[ebr 15610]

I see it's still the case that SHA1 is used to hash passwords. Could Emby look in to migrating to a more secure hash format (bcrypt / Argon2 / PBKDF2) and implement salting?

 

There are even .net libraries out there that could be used 

 

https://github.com/BcryptNet/bcrypt.net

https://github.com/neoKushan/BCrypt.Net-Core

 

Hi.  What is it you are really trying to achieve?

 

The only place passwords are stored like this is in the database on the local server machine.  Someone would need access to the actual file system of the server machine to even start digging around.  At that point, your Emby user passwords are kind of a moot point, no? 

[runtimesandbox 160]

Whilst I understand your point there, another angle to look at it would be for users that reuse passwords.

 

If an emby server is compromised you can assume that the whole server is compromised, but if a user is then reusing that username / password combination elsewhere with either other self hosted services or online accounts (which IMO is very likely, credential stuffing attacks happen successfully all the time) then its trivial for an attacker to use these compromised details elsewhere.

 

Having passwords stored using a modern hashing method makes decrypting a stolen user db non trivial and greatly increases the difficulty of cracking the hashes

[rbjtech 4950]

Whilst I understand your point there, another angle to look at it would be for users that reuse passwords.

 

If an emby server is compromised you can assume that the whole server is compromised, but if a user is then reusing that username / password combination elsewhere with either other self hosted services or online accounts (which IMO is very likely, credential stuffing attacks happen successfully all the time) then its trivial for an attacker to use these compromised details elsewhere.

 

Having passwords stored using a modern hashing method makes decrypting a stolen user db non trivial and greatly increases the difficulty of cracking the hashes

 

Whilst I don't disagree with anything you said - I think Emby have an adequate level of password security for the intended platform.  a) it's local only b ) it's for local media sharing (yes some PPI may be available)

 

In this day and age, if you really are naïve enough to use the same password for emby as you do for say your on-line banking - then it is my view that emby are not responsible nor accountable for that, the user needs to take some responsibility for their decisions.

Edited May 29, 2020 by rbjtech