Avideo: [Security] Password hashing is horribly insecure

[Amunak]

Seriously, stop using md5. Especially without salt it's almost like having plaintext passwords. This is unacceptable. PHP has easy-to-use, native functions for password hashing.

[hersche]

for video-files this is ok, but it's used for passwords too..

better whirlpool or sha-512.. or directly use scrypt?

https://en.wikipedia.org/wiki/Scrypt - i would give that my +1 ;)

[DanielnetoDotCom]

I want to migrate this pass hash, but there are so many issues to consider.
The biggest one is the communication between encoder and streamer.

[hersche]

yeah, i wrote this before my comment on #361 .. isn't that easy withouth break anything..

[TheAssassin]

Duplicate of https://github.com/DanielnetoDotCom/YouPHPTube/issues/360. The original issue has been closed, whyever...

[hersche]

i've implemented my idea in

https://github.com/hersche/YouPHPTube

https://github.com/hersche/YouPHPTube-Encoder

so at least, it should be a sha512 now, after you set your password again and it's complete downward-compatible (for example, for update the db, the admin has to log in first with the old hash in db). with this, it should be also good prepared for upgrade the hash-algo withouth break in future.

it is not finished nor PR-ready, but open for reviews and ideas.

a big thing in my opinion is to inform at least the users using the encoder, that they should update the streamer's password to be able to log in (because it's prehashed in encoder) OR we send the type of hash as a config to the streamer.. but inform the deprecated users would be good anyway.

also: sha512 or whirlpool? @TheAssassin do you may have a prefer out of pro/cons? both are 512bit so doesn't look very diffrent to me.

[hersche]

i just found a important point, before you nerve yourself.. you have to do the regular database-update, but after apply, it will still be there. do not the same progress again, since it will break the user table - it would need further edit for proper upgrade, and i will do this when it's ready (can be v5.6 instead of 5.5).

[Amunak]

The sha512 algorithm isn't really suited for password hashing either (well not on its own, in a single iteration, as it's too fast). Current industry standard is probably bcrypt (with high enough cost and, of course, a salt).

Is there any reason why cou can't use functions like password_hash and password_verify? With those you can be sure that you didn't fuck up the hashing and they make it easy to upgrade in the future if necessary.

[TheAssassin]

See this comment in the original issue: https://github.com/DanielnetoDotCom/YouPHPTube/issues/360#issuecomment-381562766

[Amunak]

Sure, but what specifically is the issue? The encoder is still written in PHP, so you can even use that native method, and the salt (and not just salt; also the algorithm and cost) is already embedded in the singular "password string", so there's no issue with reusing it in the encoder.

Or did I miss something?

[TheAssassin]

The problem is the encoder part, @Amunak. Please read the other issue and you'll notice that the authorization depends on these MD5 hashes... To be able to make this change, something like OAuth 2 needs to be implemented to replace the encoder authorization.

[hersche]

Is there any reason why cou can't use functions like password_hash and password_verify?
yeah, that's nice, its on a level with scrypt then (with the cost-factor). i just not used these methods yet, but looks good.

The problem is the encoder part, @Amunak. Please read the other issue and you'll notice that the authorization depends on these MD5 hashes... To be able to make this change, something like OAuth 2 needs to be implemented to replace the encoder authorization.

i discussed this with daniel, and we will solve this in a very simple way (only as plan yet) - we send the password via cleartext, when you enter it in the encoder (i think i will encode it with base64, but not for protection).

while this CAN be dangerous, it simplify a lot. and, if you use SSL, the transmitted password is encrypted. i was unshure on this poin first but the encryption is definently on tcp/ip-level.

if you use http, a attacker will see passwords anyway. and if you mix https and http, nothing will work out of browser-rules. so https will be used fast and is the easiest, but secure solution (if there no heartblead 2.0 is coming).

[TheAssassin]

@hersche how much are you into web application security? This is actually _worse_ than before. Not only it requires to store passwords in _cleartext_, but furthermore any CSRF attack will give an attacker a raw password. Now, considering many people use the password for other software as well, this makes all these other applications insecure. You really introduce a _critical security issue_ because you say "this is more simple"? This reminds me of all those companies that lose data on a regular base (well, for them, it's "cheaper")...

Then, there's a legal aspect. With the introduction of the GDPR (in German data protection law this has been included already), you are _required_ to protect data with suitable methods. Hashing is one of those methods. If you really remove the little bit of security you _have_, people must stop using YouPHPTube in Europe (or if they have European users), as it doesn't comply with the laws. This is a really problematic situation.

And there's common sense: sending passwords in _cleartext_ is like... WHY? There's really easy to implement and more importantly secure authorization schemes out there! Don't roll your own! Especially if you're not into the topic!

Please, don't! do! this! It is a _horrible_ idea! You rely on weird "browser rules" which are non-standard, you refer to some weird unlike events ("heartbleed 2.0") to justify your broken idea here, this is really worrifying. I've been waiting for months for something to happen in this case. And in the end, it's only getting worse!

Please, get yourself some literature on web app security, and reanalyze this situation.

[hersche]

Not only it requires to store passwords in cleartext

not only that this isn't true... (user type in in password, this goes into a variable with limited scope, sendet, and bye). in fact, the encoder stores the passwords in cleartext RIGHT NOW, but this is NOT REQUIRED! it is absolut nonsense! so we are about to remove it, unimportant if hashed or clear..

@hersche how much are you into web application security? This is actually worse than before. Not only it requires to store passwords in cleartext, but furthermore any CSRF attack will give an attacker a raw password.

my personal favourite solution would be to set the same salt on the encoder as on the streamer in the configuration.php-file. then hash it the password on encoders site. so send the hashed and salted value and compare this. i think that would be the best, most secure method.

well, there's the first problem: one encoder can have multiple streamers. lead to the next point, the admin has to enter it or we have to transmit (and that's a bad idea).

so we would be able to store the salt into the mysql-database streamer's config. the database is less optimal than the php-file, but well, secure enough in my opinion.

well, this will lead to break existing installations. so there's @DanielnetoDotCom idea to send the password plain, so the encoder don't need any salt. that make sense in some way. i rechecked if the url is encrypted too, if you have a certificate, MITM is prevented also (the user will be at least warned).

anyway, it's the most unbreaking, compatible variant, not my favourite (as you imagine), but a possible way. i absolut understand the solution, because break stuff sucks too..

You rely on weird "browser rules" which are non-standard, you refer to some weird unlike events

you mix up context - i just mean, when it has to be secured with ssl, it's automatic forced to be both way.

Please, get yourself some literature on web app security, and reanalyze this situation.

we are on finding a solution that NOT break all the stuff AND is secure. instead of say all others it's just a crap idea, we try to get a good solution and are here to discuss about.

it's not needed to start flout. just say your arguments and explain them - or do it yourself, with oauth and impress all of us, please! but remeber to not break it!

Then, there's a legal aspect. With the introduction of the GDPR (in German data protection law this has been included already), you are required to protect data with suitable methods.

open source is near always withouth any warranty. it's not that we have to implement it now this insecure way then, but this is a problem of the countrys which have servers using it public. so this makes you happy, but we are absolut free to do it as insecure as we like (if we would like, what we don't do!).

btw, you wait for your hashes, did you see that also that i started secure it against sql-injections or just focused on this part? if a attacker can overwrite user's fields, the hash also not really matters.. so wait for your hashes isn't the worst, is it?

i give a lot of time into this project, discuss a lot to don't have to change the stuff always again aka work together instead of against, but donations stay small. but get nerving posts like this - feels * disrespecting -.- (also, if it WOULD been my idea, what is not, we do the MOST work and you WAIT for this - see my point?)

[TheAssassin]

my personal favourite solution would be to set the same salt on the encoder as on the streamer in the configuration.php-file.

This actually makes the whole salting unnecessary, as it'd remove the protection it provides.

then hash it the password on encoders site. so send the hashed and salted value and compare this.

That doesn't really make sense, as you'd still need to transmit some "raw" data. If that's an unsecure hash or the raw password, well, doesn't make such a big difference (the key word is "rainbow tables" here).

i think that would be the best, most secure method.

No. Not at all. Please read my _thorough_ explanations in the _original_ issue. I described why _anything_ you described is insecure (it's actually similar to what you have at the moment). What you suggested in your last comment is even _worse_, and way more attackable.

The most secure solution would be that the encoder never sees the password, but is authorized to make some API calls to the main site on behalf of the user using tokens. This is nothing you actually need to _invent_ even, because that is just what OAuth2 does.

anyway, it's the most unbreaking, compatible variant, not my favourite (as you imagine), but a possible way. i absolut understand the solution, because break stuff sucks too..

That's not true either. OAuth2 doesn't break any existing installations, it only requires an update of the software so that both encoder and main page use the same method. That's not _really_ an issue.

well, this will lead to break existing installations. so there's @DanielnetoDotCom idea to send the password plain, so the encoder don't need any salt. that make sense in some way.

It doesn't make _any_ sense if you stop ignoring the _obvious_ security issues.

Don't share _secrets_. Authorize using (temporary) tokens!

MITM is prevented also (the user will be at least warned).

That's wrong. That's _really_ wrong. There's for example anti-virus software that intercepts all communications that always has bugs allowing attacks. There's enterprise proxies etc. which do the same. This is just not sufficient.

we are on finding a solution that NOT break all the stuff AND is secure.

The latter part is just not true. I already proved that all you suggested is insecure. I even described potential attack scenarios.

instead of say all others it's just a crap idea, we try to get a good solution and are here to discuss about.

I hope you listen to my criticism then. I am just worried about you implementing something even less secure than the current solution (which is _far_ from secure).

just do it yourself

If I could, I would, buddy. But I'm not a PHP person (I don't like PHP, nor am I good at it). Therefore I try to help you guys by analyzing your ideas and giving you feedback.

If your ideas are bad and insecure, well, you need to live with people commenting they're bad and insecure. That's how open source works.

Then, there's a legal aspect. With the introduction of the GDPR (in German data protection law this has been included already), you are required to protect data with suitable methods.

open source is near always withouth any warranty. it's not that we have to implement it now this insecure way then, but this is a problem of the countrys which have servers using it public. so this makes you happy, but we are absolut free to do it as insecure as we like (if we would like, what we don't do!).

This is still annoying, though. Not only your solution is insecure, but you publish it and advertise it as secure. Now, of course you can't be held liable, but do you really want to put people at such a risk? I mean, if you _know better_?

Considering you offer and host a YouPHPTube encoder instance publicly, you actually even need to comply or stop accepting European users. Otherwise, you may be sued, which I really don't want to happen.

btw, you wait for your hashes, did you see that also that i started secure it against sql-injections or just focused on this part? if a attacker can overwrite user's fields, the hash also not really matters.. so wait for your hashes isn't the worst, is it?

Are you actually trying to justify this insecure method (that is attackable on many other ways and doesn't require any SQL injection bugs)?

"Nerving posts" -- is that how you call critism, or notes about security issues? How did _I_ offend you? Because I asked you about your experiences? You're interpreting too much from my text, I guess. I consider code and methods reviews as contributions, too.

This is really _not_ how to deal with security issue reports.

What are your problems with OAuth2? I mean, there's libraries with some example code, which seems to be fairly easy to integrate. If you need more information, please ask questions, refer to the original issue (a lot of information is listed there already), etc.

TL;DR:

You must stop thinking of the encoder as being a "trustworthy" instance. Why share secrets with it? That violates multiple OWASP top 10 rules. And OWASP know what they're doing.

I don't want to offend anybody. But you people don't seem to know very much about web application security. Maybe think about listening to somebody _with_ experience. You should really stop inventing your own systems here. I could imagine many attacks which are quite possible.

[DanielnetoDotCom]

Hi guys, thanks for the hard work to make it secure.

I will try to describe here what is my Idea

1- Every time when a user login into the encoder he will use the encoder login form. On this form he will set his user, streamer site and password and send it to the streamer in a clean text.
2- Streamer site will authenticate the user, if it is OK the streamer site will answer the password (hash with salt) back to the encoder.
3- encoder will store this password and use it when the encoder queries for that user is done
4- in case the password is changed, on the next login the hashed password will be updated

I hope it is clear

[TheAssassin]

@DanielnetoDotCom this is clear, sure. Do you mind if I tell you what problems you have with it? I don't want to be "nerving" again...

[hersche]

This actually makes the whole salting unnecessary, as it'd remove the protection it provides.

why it should, when you transmit the salt to the various configs manualy?

then hash it the password on encoders site. so send the hashed and salted value and compare this.

unlucky and unclear expressed: hash("sha512",$clearPw.$salt) -> send that result. i was nerved.

That's wrong. That's really wrong. There's for example anti-virus software that intercepts all communications that always has bugs allowing attacks. There's enterprise proxies etc. which do the same. This is just not sufficient.

when you get apps, that search the web for you, open your mails, change your root-certs then you allow this. trusted certificates have definently the sense to prevent man in the middle, but i also dislike antivirus, cause it's often more spyware - and i can't prevent people of not using linux and have this on theyr computer.

If I could, I would, buddy. But I'm not a PHP person (I don't like PHP, nor am I good at it). Therefore I try to help you guys by analyzing your ideas and giving you feedback.

even you should be able to learn it!

If your ideas are bad and insecure, well, you need to live with people commenting they're bad and insecure. That's how open source works.

this was not originaly my idea! my idea was hash("sha512",$clearPw.$salt) = hashing salt and password together and use this to compare. i still don't belive this is insecure, i have expressed myself unlucky in before post.

"Nerving posts" -- is that how you call critism, or notes about security issues? How did I offend you? Because I asked you about your experiences? You're interpreting too much from my text, I guess.

maybe i intepret too much, i have my expiriences, i may not know every kind of security-hole, but i just don't have only bad ideas i think.. but i just stop here. anyone else who's not so bad, please just do., whatever and however

[Taz8du29]

I do agree with @TheAssassin: Implement OAuth2.
It solves all you questions. No password, only tokens.
There's no need to even think about the password.

[DanielnetoDotCom]

@TheAssassin I do remember, the things you have mention.
I dont think it is a final solution, but it is the first step to make it more secure.

The next step would be the token for each video, what will be stored instead the password, and will expire after usage.

[TheAssassin]

why it should, when you transmit the salt to the various configs manualy?

Salts are not supposed to be equal for all users. Not even for a single entity. But when you add them to multiple ones, it gets only works.

If a salt is equal for every user (and the algorithm is publicly known) it's easy to crack the passwords once you have the salt. This is not "salting" but maybe some form of "shared secret".

when you get apps, that search the web for you, open your mails, change your root-certs then you allow this. trusted certificates have definently the sense to prevent man in the middle, but i also dislike antivirus, cause it's often more spyware - and i can't prevent people of not using linux and have this on theyr computer.

There's been very many examples in which "trustworthy" CAs issued certificates for domains without being authorized to do so. You can't solely rely on this. And users will always be subject to such systems. Please avoid sending the password to the encoder at all. Not even a static hash. Temporary tokens for the win!

even you should be able to learn it!

Really? You should be able to learn web app security and OAuth2, shouldn't you? I could stop contributing, if you think that it's a good idea to talk to contributors like that.

You're sounding like big companies: "security is expensive, but doesn't add anything". What an ancient way of thinking.

this was not originaly my idea! my idea was hash("sha512",$clearPw.$salt) = hashing salt and password together and use this to compare. i still don't belive this is insecure, i have expressed myself unlucky in before post.

Next problem: hashing once is always insecure, even with a salt. There's a reason people hash multiple times (normally >1k times, depending on the hardware). This is to slow down the computation of the hash and therefore delay the authentication. This way, brute force attacks are slowed down significantly. And also, there's likely no rainbow tables to crack passwords hashed this amount of times. This makes attacks a lot harder.

@DanielnetoDotCom yeah, we worked out a quite secure system in the original issue, I'd say.

[hersche]

Really? You should be able to learn web app security and OAuth2, shouldn't you? I could stop contributing, if you think that it's a good idea to talk to contributors like that.

i also see myself as a contributor, i can stop as well..

[TheAssassin]

Now you took this too personal. I just wanted to say that this shouldn't be a "if you don't do it we use the insecure system" situation.

[DanielnetoDotCom]

@TheAssassin Agree, with you the salt should be different for every user, so the salt may be the "secret" (different on every site) and a mix of user and password combination, repeated X times (we can create an configuration option for that)

[DanielnetoDotCom]

But again, what @hersche is trying to do is making it more secure, (NOT a FINAL solution).

We will never have a system 100% secure, we all know that, but we will improve it everyday

[TheAssassin]

@TheAssassin Agree, with you the salt should be different for every user, so the salt may be the "secret" (different on every site) and a mix of user and password combination, repeated X times (we can create an configuration option for that)

I'm not sure what you mean.

But again, what @hersche is trying to do is making it more secure, (NOT a FINAL solution).

How is it making this more secure? The problem is that the encoder has the password at all, although it doesn't need to have it. Furthermore, by transporting the password to the encoder in cleartext (in the query string), the user can read it, XSRF attacks would get the raw value (making all other software insecure to use for which the user uses the same passphrase), the value is stored in the browser history in _clear text_, etc. etc. etc.

[DanielnetoDotCom]

About the "browser history in clear text", I dont see I thing what we can do.
but about the way to use a better hash to store the password (for sure better them MD5). this is make more secure on the way I see.

[hersche]

i repeat myself..

unlucky and unclear expressed: hash("sha512",$clearPw.$salt) -> send that result. i was nerved.

my original thinking.. but it's all wrong so ** off.

the value is stored in the browser history in clear text

not even true, the request is not done in a way it will be saved in history (ajax-request)

anyway, this discussion doesn't seem to make sense to me anymore..

[TheAssassin]

Well, this is only _one_ special scenario. There's more attack scenarios.

Really, just don't send passphrases in clear text. I'd really like to see something non-does-share-my-passphrase solution.

By the way, did you think about server logs? They contain the query string as well...

The point is, why should my passphrase be compromised just because I want to use an encoder instance? It doesn't need it technically, but may process it. Now, if I'd hijack your instance, or could somehow set up a fake one and make people use it (using a DNS attack or something), I would just easily get access to all the passphrases.

I could use something like an SQL injection, and change the URL which is requested by the user to authorize the requests to the encoder. This way the user would see an error, sure, but I would be sent all the passphrases.

Often, server logs are publicly accessible, even on share hosters where the web server stuff is managed by a company. This is mostly due to wrong information. But, _holy shit_, that'd be a leak if such a mass of passphrases would be leaked.

Please don't limit yourself to thinking about the _transport_ of the passphrase. (Not to forget that even that is a problem... if you don't require a secure HTTPS setup in your software _by default_, the passphrases will be available as the transport can be attacked.)

@hersche why doesn't this make sense to you any more? You don't want to accept your solution is prone to errors and attacks, and is not even remotely secure? Come on.

Telling people to

** off

is far from professional behavior, guys...

[hersche]

Telling people to
** off
is far from professional behavior, guys...

this was me, not we. and i, individual, can loose my nerves.

i can accept my solution is not final, but you always say, my only solution is the transmission in cleartext. it's not. this was the result out of a long discussion, we had to break up, i prefer it hashed maybe i will still not be understood, but it's the last time i repeat this.

i will wait with a solution with salting and / or oauth (if some "professional" will implement this, thats fine), if whished by the community or so, we can do a simple upgrade of the hashes (bcrypt,sha512 or similiar). if people dislike, md5 also works for now (no change)

[TheAssassin]

@hersche I tried to explain to you that you use some terms wrongly, for example, you do not salt anything, but instead you use some shared secret.

It doesn't matter whether you use SHA512 or whatever hash with your solution. It is maybe 0.01% more secure than the previous solution. Changing the hashing algorithm for another one doesn't harden your solution very much, it only makes sure that MD5's weakness can't be exploited. It's still prone to most of the other attacks. This has been explained in #360.

If you _really_ want to proceed like that instead of spending time on a final solution, at least make sure to hash more than once with your SHA512 hash... maybe 1000 times, maybe more. Most systems make that value configurable, so that more powerful hardware can still slow down attacks. Some even measure how many hashes per second can be calculated, but that's probably out of scope here.

Please check out http://www.bubblecode.net/en/2016/01/22/understanding-oauth2/. It explains how OAuth2 works. I think it's a good introduction and it's possible to understand it even if you never heard about OAuth2 before.

[Amunak]

Holy shit I just skimmed the conversation because you managed to produce quite a lot of words overnight.

@hersche, you said this:

so we would be able to store the salt into the mysql-database streamer's config. the database is less optimal than the php-file, but well, secure enough in my opinion.

But that's literally the industry standard of hashing passwords. Use a strong hashing function and store the salt with or next to the password (unique to every password and every time it's generated). This is to prevent rainbow tables from working. I'd like to point out again that that's what the native hashing functions do natively. They generate a strong salt, use a strong hash, and store all that including some metadata in a single, 60-character long string in a single column in the database. You just need to be able to read that value from both the encoder and the main site so that you can use it in password_verify(). If you want to keep the databases for encoder and main site separate you'd have no choice but to use some other mechanism like OAuth2 or other some other (secure!) token-exchange method. Also, there are libraries for implementing OAuth that make it very, very easy.

Your current implementation (if it truly is a single "salt" for all passwords, stored in a config file) is actually usually referred to as pepper, and is redundant to some degree. You still need the regular salt but by adding pepper if say, only your database is compromised (but not the code with the pepper) then the passwords are even harder to recover, which is nice. But it's not mandatory, though nothing prevents anyone from having the same pepper for both the encoder(s) and the main site. More on pepper here.

[hersche]

Is there any reason why cou can't use functions like password_hash and password_verify?

yeah, that's nice, its on a level with scrypt then (with the cost-factor). i just not used these methods yet, but looks good.

that was my upper answer.

Your current implementation (if it truly is a single "salt" for all passwords, stored in a config file) is actually usually referred to as pepper, and is redundant to some degree.

the current implmenetation does not have anything like fake-salt aka shared secrect aka pepper. it has to be all done first.

If you want to keep the databases for encoder and main site separate you'd have no choice but to use some other mechanism like OAuth2 or other some other (secure!) token-exchange method. Also, there are libraries for implementing OAuth that make it very, very easy.

if someone like to implement this, feel free.

for me (personal) it looks as a heavy setup is needed (4 servers) and it doesn't look very easy. i can be wrong. we also do not use any user- or other authentication for the moment (that would be included = too much?). it looks a bit heavy for our need. anyway, for something this project is open ;)

i have another idea how to solve that lite, but it's too much for write all down for now. and it's not every question solved there.

[TheAssassin]

for me (personal) it looks as a heavy setup is needed (4 servers) and it doesn't look very easy. i can be wrong. we also do not use any user- or other authentication for the moment (that would be included = too much?). it looks a bit heavy for our need. anyway, for something this project is open ;)

Not really. In terms of OAuth2, the resource and authorization server is the main server, whereas the client is the encoder. I don't know why you think it's 4 (the resource owner is not a server, it's merely the user who authorizes the encoder to access the main server).

Scenario: user wants to encode video on encoder

• user clicks "encode" or whatever
• user is redirected to encoder, e.g., `https://encoder/encode?main_url=https://youphptube&video_id=1234
• encoder requires access to the main server, so it tries to get an OAuth 2 token -> it redirects to the main server's authorization endpoint, e.g., https://youphptube/oauth2/authorize?... (the parameters are automatically generated by any OAuth2 framework)
• user is prompted to confirm that the encoder may get access to:
  
  
  
  • downloading the video with ID 1234
  
  
  • uploading the encoded version of video with ID 1234 (ideally with a sane timeout of this token, for example, 2 days)
  
  
• user confirms, and is redirected to the encoder
• the encoder now has access to the video's API endpoints on the main server

It's not really that complex, but a really secure system. The encoder gets all the information it needs (YouPHPTube address, user name, video ID to encode), never sees _any_ secret, etc. There's only two servers in this scenario. I bet you can implement this faster than any home brew password based authorization scheme.

[hersche]

that's a good post, try to show simplified how it works.

my last idea is going in a similiar direction (i did nowhere wrote this here, but would be able to paste my chat-part with daniel here, like look only, if the user is logged into the streamer and encoder only looks, if streamer is logged in, by the session the streamer should have - i have open questions for myself there) - anyway: of course it is better to use a tested lib than something own.

with that explination and my try with a session, i can understand the concept better and, as far as i understand, it has not to break anything because the encoder even do not need any own users then. and like you said, nothing critical has to be transmited.

user is prompted to confirm that the encoder may get access to:

on this point, you speak about a allowed videoid. i think, it's also possible to just give the user itself upload-rights securly and a limited time, to simplify our part of the implementation (depends on implementation) - is this insecure in any way (except maybe, that the user can upload as many videos as he wants when this is the only restriction, by logic)?
i speak here about doing this with oauth2, for clearence.

if someone can recommend a php-lib/framework, in best case with a working example for the essential, that would be great to know then.

[TheAssassin]

i think, it's also possible to just give the user itself upload-rights securly and a limited time

You're thinking of the user here, but that's wrong in this scenario. The user only exists on the main server, not the encoder. The user requests encoding on the encoder, therefore the _encoder_ as a system requests permission to access the main server to fulfill this request. The user authorizes this access on the main server, and the encoder gets a minimum of access required to finish the encoding job (i.e., upload the final product). The minimum amount of access is a token that is valid for a single video ID on the main server that is associated with the pair [email protected] (this uniquely identifies a user, similar to e-mail, XMPP, etc. accounts).

The user data can be stored in two tables for example, with a foreign key from the user ID table to a "known YouPHPTube services" table. Then, a job table containing the video ID the encoder got from the main server could have a foreign key on the user ID table to associate the encoding job and video ID with the user. Then, on subsequent logins of the user on the encoder, the encoder knows which jobs to present to the user.

It's of course a bad idea to allow the encoder to upload anything at any time for some time span. An encoder could upload anything it wanted, which is undesirable. Instead, the access must be limited to only the videos the user ever wanted to encode on an encoder. And the video tokens the encoder stores download the initial video and later upload the encoded result must expire when the encoder has finished uploading it (perhaps after an integrity check, the encoder could provide a checksum of any kind to the main server when uploading the video).

These per-video tokens aren't much more complicated than the classic token based scheme. Instead of associating a token with every user, you just associate the token with the video. That's not very much more complicated.

Think about this scenario: I trust my YouPHPTube main server, but I use a non-trustworthy external encoder server (e.g., the publicly hosted one). I want it to encode a single video. All the encoder needs to know is "who am I rendering for (user ID), where can I get the current video (and can upload the final result), how can I authenticate on the main server to be able to download and upload files".

We combine two strategies: classic OAuth2 authentication to allow users to access the encoder and check the state of the encoding processes (this is already possible, so we should allow it in the future, too) which is entirely read-only, and the video tokens to allow uploads of the encoded files (which are really the most minimal amount of access I could imagine that is necessary to allow the encoder to upload files, but don't allow any other changes, and don't allow one encoder to interfere with another one).

Thinking about this, I just thought, the video tokens even allow using different encoder instances, right? This might be really useful in the future to scale the encoding processes horizontally. It's a really powerful approach. Much more powerful than any other authorization system. And, most importantly, it's really secure, tested, well known and not much more complex than using OAuth2 to allow any kind of uploads.

In the other issue, I mentioned that I once tried https://bshaffer.github.io/oauth2-server-php-docs/ with success. It's probably the de-facto PHP server framework for OAuth2. You'd still need something for the client side, but there's a lot of options. I just can't tell anything about their quality. I bet there's some good blog posts comparing them out there.

[hersche]

ok, thanks for the hints.

it is still not clear how to do those video-token-steps. like always, if it is clear to someone else (includig php) feel free doing so.

for a first, i will let the systems basicly stay like it is. since i made some commits for upgrading the hash already, including testing the auth of the encoder i think i will do those steps first:

1. remove the cleartext-password in the encoders-database
2. upgrade the hash to sha512 (why not native functions, more down)
3. implement a shared secret, that's empty by default, but that can be set additional (not a salt, as i learned)

to point 2: the native password-functions of php will not work with the current way.

why? we have to pass the cleartext-password and the hash to the password-verify-function.
the auth is done on streamer, the streamer has only the hashed value in the database, the password is comming from the encoder - so for using the native functions for NOW, we would have to send the password cleartext, what's unuseable.

when someone implement oauth2, upgrading to the native-password-functions is no problem anymore and would be great.

maybe i am lazy, but by (my) logic, this changes should only increase security (a little bit) - if i am wrong (not too lazy, but wrong), correct me

edit: after discussion, we came to the conclusion, that we just completly let it untouched until oauth.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Amunak]

Reopen.

This is critical to the project's security and should not be missed.

[hersche]

When it stays open - i do not develop on ypt since more than a half year, so i will not do this. Hope, it will be done once by someone.

[DanielnetoDotCom]

Actually it can be closed

the hash already changed, it is a mix of hashing

md5(hash("whirlpool", sha1($password)));

also if you want more security you can change your salt on the configuration.php file and enable it on the customizeAdvanced plugin.

you can check the code here:

https://github.com/DanielnetoDotCom/YouPHPTube/blob/efac0aa71d552936d7ea9dde7d7bff5bc224cdfa/objects/functions.php#L1255

[TheAssassin]

There should not be a global salt, but one per user. Also, both MD5 and SHA1 are cryptographically insecure. When changing your hashing algorithm, you should use modern hashing algorithms.

Your technique is also pretty outdated, this shouldn't have been used for at least 10 years any more. Use bcrypt or PBKDF2 with a few thousand rounds (for PBKDF2, for instance, 10k-100k is a sensible choice).

The password hashing isn't horribly insecure any more, but still quite insecure.

[DanielnetoDotCom]

@TheAssassin thanks, I like all your ideas, I will try to implement them always when I can

[TheAssassin]

Great! I always try to make my suggestions sound constructive, and it's nice to see them being welcome.

Just an addition to the password hashing: The rounds count should be configurable. The idea behind hashing in a loop is to delay the password verification. This can slow down brute force attacks significantly, and is the reason why it must be configurable. More capable machines can hash 10k times in a fraction of a second, however something low-level will need a few seconds, which is too long. Ideally, there's a script that will hash until e.g., 0.1-1 seconds are over, and count the number of hash cycles (repeating the process a few times to provide a meaningful result, perhaps also test a few values and let the user pick (feature for advanced users)).

It's important to store the rounds count along with the password, otherwise as soon as the value would be changed (e.g., by accident, during an upgrade, ...), all old passwords can't be validated any more.

PHP's password_hash can use crypt, which will automatically set up all you need: a strong hashing algorithm with a suitable rounds count. I _strongly_ encourage you to use this instead of shipping your own algorithm. It's known to be secure. And extra bonus: it will be improved on every new PHP version.