Battle.net log-in credentials are not preserved.

[vtheofilis]

Although Playnite preserves the necessary data for it to log in for all the other supported distribution platforms, this doesn't seem to apply for Battle.net. Specifically, every time I reload the Games list, just to refresh it or due to Playnite's start up, I have to manually enter my Battle.net password.

[v00d00m4n]

Same here

[JosefNemec]

This is a battle.net issue, it likes to invalidate logging session way too soon. Nothing I can do about it I'm afraid. For now I recommend syncing your library and then switching settings back to syncing only installed games. This way you have all games and they will properly switch their installed/uninstalled state. You will need to switch to full sync only when you add new game to your account.

[v00d00m4n]

maybe you just need to remove this annoying pop up (and instead show some log by demand when item "show error log" activated by user) with warning so we can continue using launcher like nothing happened

[CantyCanadian]

So... crazy idea, but is there a way to store credentials locally and have it so it automatically logs itself in in the background. I never really saw any captchas so a script might be able to manually make its way in.

[JosefNemec]

@CantyCanadian Yes I could store those credentials, but that would be super unsafe and I don't want to do that.

[HunterZ]

What about a setting for popping up a login box whenever the credentials expire?

I have an authenticator on my account, so my credentials are always going to expire anyway.

[Heraes-git]

@CantyCanadian Yes I could store those credentials, but that would be super unsafe and I don't want to do that.

Hi Joseph ! Maybe you could had an "option" ? So we use stored credentials at our own risks ;) Love your work. <3

[starquake]

IMHO storing credentials is not acceptable anymore these days. I can already see the blogposts and YouTube videos: "I used playnite and now my Battle.net account is stolen OMGWTFBBQ!!!!1!1!"

It's probably also not allowed by Battle.net so it might get your app banned.

Maybe you could set the default to not import uninstalled games (maybe it already is default) and add a hint that the login session probably will expire very quickly?

[JosefNemec]

Storing user's credentials is not an option because there's no way how to store them without potential way of those credentials being hijacked. Mainly because at some point we would need to use plain text representation in order to fill in the login form.

I will add some tooltip into application to notify users about this issue since basically everybody will experience this at some point. Also I will have a look at what API battle.net client uses and I'll try to switch to it.

[v00d00m4n]

Why not encrypt stored file with some key generated by a combo of unique hardware ids and hash of user created password or something like this?

[Heraes-git]

@v00d00m4n Maybe because the developer fail to fight his fear of being accused of possible account stealing because of a lack of security in his software, while many developers like the ones creating passwords safes (LastPass, KeyPass, etc) are courageous ? And maybe because people responding here are following the developer in each of his choice, in order to be seen as fellows and have something in return, so they won't contradict him ?

You know, people lack of imagination and competence when they begin to be frightened. A single checkboxe can make their entire brain to collapse.

Sarcasm aside : yeah, there is necessarily some ways to encrypt a file on a computer, in order to store important keys (it is done all the time by numerous softwares, and they don't say "it's gona be super-unsafe !"). But it seems just outside of the competence of JosefNemec wich prefer to rely on a possible hijacking, instead of just saying "I don't know how to do it". May be you need some help ? I can't offer you one, personally, but you should ask.

IMHO storing credentials is not acceptable anymore these days.

That's utterly false. This is just an actual comon idea based only on the lack of skills coming from developers who try to start a new fashion in order to hide their failure. I see more and more of those "login without credential" stuffs coming today, and who spam your e-mail boxes with constant re-activation process just because storing a password in a database table litterally scare them.

[JosefNemec]

I'm simply not going to store password in a way that could be somehow reversed to original plain text. That's not how password security is done these days. You should never store passwords in a way that could be reversible, even encrypting is not save since encryption keys can be leaked.

What you do is that you hash and salt password and store result of that. When the user is going to log in next time, you repeat the same processes (for password he entered in login form) and compare hashed results to know if the password is correct, without actually knowing what is the correct password. But we can't do that since we would need the plain version to enter to the login form.

[Heraes-git]

@JosefNemec Thanks for your kind response, and for not having taken my sarcasm too seriously ;) Now, I'm not able to discuss about technical password encryption at all, but I can rely on my logical ability to detect some contradiction, and on tools I use on my daily basis.

For instance, I use the CMS "Grav", wich use the "hash and salt" process that you mentioned (I saw that when taking a look into its files) : but I don't see any security leak in that. Indeed, there is hashed passwords stored in text files, but I don't see what's the problem with that.

But we can't do that since we would need the plain version to enter to the login form.

I don't understand that phrase. Do yo mean you would need to store the deciphered password in a text file to make your login form to work ? What do you mean by "plain version" ? And what do you mean by "to enter to" ?

Sincerely, I think that those steps aren't impossible with any software :

1. The user copies its password from a safe and pastes it into your ID's forms, or types it directly.
2. Your soft generates a hashed password, with a salt.
3. It stores it (the hashed one) in a file.
4. And the comparison process you mentioned can work based on that file. Here in your soft, it should be replaced by an "insertion" process, meaning that your soft should regenerate the deciphered password when connecting with APIs in order to connect to accounts.

At what point is there a security leak in these steps ? Of course we have to "store" something on a file : but I don't see why it should be considered as a leak, given that since decades, we stored encrypted things in files or database tables.

I'm simply not going to store password in a way that could be somehow reversed to original plain text.

For that they should crack the hashing generation process of your software, and I don't see why you should be more concerned than any other software or website embedding that technology.

[JosefNemec]

And the comparison process you mentioned can work based on that file. Here in your soft, it should be replaced by an "insertion" process, meaning that your soft should regenerate the deciphered password when connecting with APIs in order to connect to accounts.

You can't get original password after hashing it, that's the whole point of it.

The issue is that we don't have access to an API that would accept hashed password instead of plain one (basically raw text you enter into login form). The only thing we could theoretically do is to automatically fill in the login box if we detect that the login session expired. But for that we need password in original form, and that would mean storing it in a way that could be decrypted (which is not safe no matter how you look at it).

All the companies you mentioned in you previous post actually don't know your password. They have no way of getting your original password. But they have full control over the login process so they can repeat the authentication I described, and actually verify that you entered correct password without having access to the original one in the first place.

[HunterZ]

It's open source software. There's no way to implement a secret hashing+salting algorithm.

Please stop trying to pressure JosefNemec into doing something that is going to get people's accounts hacked and/or get Playnite shut down by game publishers.

On another note: I noticed battle.net allows you to log in via Facebook or Google credentials. Is there some way to leverage this?

[Heraes-git]

I'm not trying to pressure JosefNemec, I'm discussing with him in order to have more explanations than "I won't do it because I won't".

The fact that it's an open-source software may be a good point in the first place, but how could we explain that Keepass is open-source and probably using that kind of technology ?

More,

You can't get original password after hashing it, that's the whole point of it.

I had at first understood that point, by mentally projecting a process consisting in waiting for a user input, then generating a hashed version, and comparing it to a previously stored one, but then ...

All the companies you mentioned in you previous post actually don't know your password. They have no way of getting your original password. But they have full control over the login process so they can repeat the authentication I described...

I asked myself : how can they fill-in correctly the password input on webpages, if they don't decipher the hashed password (stored in the user safe) with their own hashing process being reversed ?

and actually verify that you entered correct password without having access to the original one in the first place.

We don't enter the correct password : they protect the hashed passwords with masterpass (that I indeed need to re-type each time I want to open my safe), but they fill-in forms inputs automatically based on that. If you were talking about the masterpass when saying "verify that you entered correct password", that's ok, but it doesn't change the result.

So this leads me to the conclusion : you could probably use the same technology of reversed hashing + masterpass to "fill-in" the ID's when communicating with accounts through APIs.

[JosefNemec]

I don't know how to explains this to you differently. The master password doesn't change anything, that password is hashed by them and they don't have access to original one. When I was talking about companies not knowing your password, I was talking specifically about the one you use to login, since that's what we are discussing here. Yes they may use it to encrypt your additional passwords to give your access to the plain version, but that's a special case for password managers. Traditional services (basically everything other then password managers), should never store passwords in a way that could lead to password being decrypted.

Playnite is simply in a bad place in the authentication chain, it would need to basically supply the role of user typing in password and that requires access to it.

There's no point in discussing this more, we are not going to store user's credentials, period. Storing the credentials is overall bad solution for our problem. The best solution would be to use API that actual Battle.net client uses, but I haven't look at it yet.

@HunterZ I don't think that using Google account would make any difference, the issue is that Blizzard is not allowing login session to last very long time for their standard web site.

[JosefNemec]

Also I don't think this is a big issue. New games are being added into Battle.net launcher only once year or so, so my original recommendation still stands. Login once to fully sync your account and then disable import of uninstalled games to prevent login errors. Then re-authenticate once new game is added.

[Heraes-git]

That's not because you won't store user's credential that we can't point out contradictions in what you said.

I perfectly described the steps involved in password hashing, storing, and deciphering, and used for auto fill-in, and you just answer to that with an old argument of "having access to the original one".

What did you miss in my previous comment about hashing and reverse-hashing, this based on the single input of a masterpass (re-entered for each session) used to access to the stored hashed password, this in order to deciphere them ?

Yes they may use it to encrypt your additional passwords to give your access to the plain version, but that's a special case for password managers.

And there must be a technology for that. A technology that can be reused when developping a software.

Traditional services (basically everything other then password managers), should never store passwords in a way that could lead to password being decrypted.

Decrypted unintentionally and for bad purpose ? Except that they can't be decrypted if you use the same technology I talked about, given that it doesn't use the plain-text storing you keep mentioning !! You constantly use YOUR method and its problems as a proof of impossibility to copy the technology.

It's like I was saying to you "we can make planes to fly with reactors" and you were answering me "no, we can't, because we actually use planers, and that they crash when they go too fast due to turbulences, so adding reactors would crash them".

So NO, storing passwords, as storing anything encrypted on a hard disk and possibly deciphered by a key, is NOT subject to malicous deciphering just like that. If you keep going with this assertion, I will ask the Keepass team to come here to talk about security. Maybe you'll understand that they store passwords in a hashed database on our machines, and offer a fill-in feature for webpage.

Why don't you just admit you don't know how to do it instead of spreading misconceptions about security ?

[Heraes-git]

The master password doesn't change anything, that password is hashed by them and they don't have access to original one.

So the Masterpass isn't stored in plain in the database. Yeah. So when typing the masterpass, it compares it to the hashed version stored, and gives access to hashed password that can be deciphered by a reversing process in order to fill-in inputs.

Your soft could perfectly reproduce that behavior, if it was using the same technology : we would store hashed version of accounts' IDs in your software (in a file, a database, etc), then protect them by masterpass. And then, each time we would launch PLAYNITE, we would re-enter our masterpass and PLAYNITE would decipher passwords and send them through API's.

But maybe there is something you feel as a "plain text storing" at one point in those steps ? But is it temporary, or permanently ? And more : is it more dangerous than just typing it with our fingers ?

[JosefNemec]

I stand behind what I said. The issue is not in lacking ability to implement such solution, but in storing credentials in general to solve this issue.

Please restrain yourself from commenting any more unless you offer some other solution that doesn't require storing user's credentials. I'm saying it for the last time, we are not going to store user's credentials. Otherwise I will be forced to lock this issue.

[Heraes-git]

Ok, so I guess Keepass is unsafe, and very dangerous. Feel free to lock what you can't understand.

[JosefNemec]

Ok, so I guess Keepass is unsafe, and very dangerous. Feel free to lock what you can't understand.

Do you understand that even Keepass asks you for you master password when you want to access other ones (like you have to actually type it in)? What would be the point of adding master password to Playnite and then asking people to enter it if they need to refresh Blizzard login. The whole point of this issue to remove the need to re-enter credentials (because the session is expiring). Introducing master password would not solve the UX issue we have here. You would still need to type in the password and in that case it might as well be the Blizzard one.

[Heraes-git]

Do you understand that even Keepass asks you for you master password when you want to access other ones (like you have to actually type it in)?

Yeah I understand that. I've even talked you about that. And you enter it one time (with of course some option like session time, etc), not each time you want to access a password.

What would be the point of adding master password to Playnite and then asking people to enter it if they need to refresh Blizzard login.

Maybe because they just don't want to see warn icons in notification of your software ? And they want to have uninstalled games available in their Playnite Library ? And they don't want to re-enter several accounts IDs like Blizzard, Steam, etc, each time they launch your program or that a session expires ? So, after launching Playnite, they would only type one single time their masterpass, and each time Playnite detect a login refresh requirement, it would automatically send deciphered password based on the technology we're discussing ?

The whole point of this issue to remove the need to re-enter credentials (because the session is expiring)

Yeah, and that's why having a masterpass is cool : it avoids you to re-type each password of each service you want to connect to. Even if there is just Blizzard having an issue for now, it could save time in the future. Not mentioning that entering a masterpassword can be shorter to opening LatsPass or Keepass in order to retrieve our email/password (wich can be 30 characters or more !) and insert it in an API form.

Introducing master password would not solve the UX issue we have here.

Because ? Storing hashed password is dangerous ? Ok, I'll really contact Keepass for more support. Or even Steam : they have an auto-login feature, so they might store the account password (encrypted) on our disks when we activate that.

[starquake]

Now, I'm not able to discuss about technical password encryption at all, but I can rely on my logical ability to detect some contradiction, and on tools I use on my daily basis.

I see you have a bit of knowledge about passwords. That's great! There are, however, still some parts of it you don't understand. You can reason logically about passwords but you can't just pick and choose the parts you like. There are all kinds of do's and don'ts for passwords. You're skipping a bunch of things you shouldn't do. Which is why the solutions you mention are flawed.

There are no contradictions in what @JosefNemec said. Your comments start to sound a bit rude to me. How are you able to judge the security knowledge of @JosefNemec if you don't have that knowledge yourself?

Theoretically Playnite could store passwords for sites that do not support long-lived authentication. Just like Keepass or any other password manager does. But playnite is not a password manager.

The biggest issue is: Battle.net does not support proper long-lived authentication.

• AFAIK Battle.net is the only site with that problem. So Instead of needing to enter the battle.net password you need to enter some other master password. The time-out for the master password will most probably not be longer than the time-out. So you still have to input a password as often as before.

• Playnite is not a password manager. As @JosefNemec mentioned: There aren't much new games coming out on battle.net. Putting development time in this issue (by recreating Keepass) is bad use of resources. Do you have any idea how much work it takes to actually create a good password manager that can safely store plain text passwords?

• Saving passwords might actually get playnite banned if they don't like it.

[Heraes-git]

How are you able to judge the security knowledge of @JosefNemec if you don't have that knowledge yourself?

You make the assertion that I don't have the knowledge myself, base on your first paragraph with no proofs support, and you ask me to stop something that I never started. I never critisized @JosefNemec security knowledge, I just critisized his approach. It's a pure logical thing. We don't have to be a security technician to judge when there is a contradiction in the way someone is reasoning.

So YOU come here with an argument of authority, that I could easily debunk : how can YOU judge of @JosefNemec security knowledge and presume that mine is smaller ?

There are no contradictions in what @JosefNemec said.

Yes there is, and I spotted them.

But playnite is not a password manager.

It doesn't matter. It doesn't has to. We're talking about how to store something encrypted on an hard-disk, in order to automatically fill-in a form wich has an expiration problem. Not to store thousands of passwords and to provide a full encryption software.

The biggest issue is: Battle.net does not support proper long-lived authentication.

Yeah, and for that we can store something encrypted, and decipher it to fill the form when needed.

So Instead of needing to enter the battle.net password you need to enter some other master password. The time-out for the master password will most probably not be longer than the time-out.

No, we could set a higher masterpass expiration duration (controlled by the user), this covering the BN expiration. Moreover, you're reasoning as if BN would be the only app causing problem in the future. But you can't know. So solving the problem the good way (with a masterpass), is better, not only for future problems, but also fo avoiding users repetitive tasks.

So you still have to input a password as often as before.

No. As I said, the masterpass could last longer (even indefinitely). This is a user choice. Developpers don't have to impose their own security politic. When using a software, a user is a responsible adult.

Putting development time in this issue (by recreating Keepass) is bad use of resources. Do you have any idea how much work it takes to actually create a good password manager that can safely store plain text passwords?

If this is really the problem, so @JosefNemec should say it clearly. But spreading misconceptions about security breaches is not a solution. Nobody has to cover its lazyness or lack of time with false assertions.

Just as a reminder of what Josef said :

I'm simply not going to store password in a way that could be somehow reversed to original plain text. That's not how password security is done these days. You should never store passwords in a way that could be reversible, even encrypting is not save since encryption keys can be leaked.

That's utterly false : if that was true, all encryption based program should stop using encryption. And that's because of a psychological problem (lazyness in learning how to do a thing) that wrong assertions like that spread all around the Internet, and website use more and more non-credential forms. Biometry could be the future of crendentials, but that's a different topic. And I don't see why fingertips stored on a hard-disk couldn't be subject to leak and breach too.

Then, about the time : as a developper, I would always spent more time to relieve users to do a repetitive stupid task. Thus, creating a masterpass would give users the possibility to enter a more simple password to fill-in all desired login API forms automatically (and that can save lots of time, given that typing an e-mail + a long password takes some time).

Saving passwords might actually get playnite banned if they don't like it.

That's actually the only good reason I see. But for this, they could have to do a couple a things :

1. Detect that we're using an automatic fillin-in with encryption technology.
2. And explain why we don't have the right to use it. I don't see why a website should avoid me to use LastPass or Keepass to fill-in my logins, so I don't see why BattleNet or Steam should avoid me to use a similar technology embeded in a software communicating throught API's.

See, that's pure logical things. No security top-notch level required.

[JosefNemec]

I've opened new issue #1057 for Battle.net sync rework and I'm closing this one. I've already rejected proposition to store user's credentials (we are simply not going to do it, no matter what) and current discussion is no longer constructive.