rugk Posted July 31, 2017 Report Share Posted July 31, 2017 (edited) Currently you seem to save the password in the config file of 0ad (yeah, maybe some BASE64 encoding or so, but this does not add any security, it is basically plaintext). So, this password is not for very confidentially things, but well… you know… people reuse passwords and such things, so no need to argue here: It is a password and deserves to be protected. A nice and (probably) the only secure way using well-proven/standard techniques is to use the OS' keyrings such as of KDE/Gnome or Max OS, to save the password. All, of course, offer APIs for that, but they are likely very different. So maybe it is a long-term goal, but as 0ad is an open-source project I could imagine this being a tiny thing, which can set it apart from the competition, which likely do all crazy things with passwords instead of using the proper™ way… Edit: Clarified that I mean the password saved locally… Edited August 1, 2017 by rugk Quote Link to comment Share on other sites More sharing options...
Lion.Kanzen Posted July 31, 2017 Report Share Posted July 31, 2017 @elexis @fatherbushido Quote Link to comment Share on other sites More sharing options...
Imarok Posted August 1, 2017 Report Share Posted August 1, 2017 Afaik we only save some hash of password and username Quote Link to comment Share on other sites More sharing options...
Stan` Posted August 1, 2017 Report Share Posted August 1, 2017 Windows doesn't have such a thing though. For now 0ad passwords on Windows are about as safe as WiFi passwords. Quote Link to comment Share on other sites More sharing options...
elexis Posted August 1, 2017 Report Share Posted August 1, 2017 The hashing of the password is done in JSI_Lobby::EncryptPassword and the PBKDF2 algorithm is used, which still appears to be secure. The hashing only protects the players from having their original password leaked in case the lobby db is leaked. But if an attacker gets the players config file, he can just use the hashed password to connect with that account. Implementing N different ways to protect the user pw that only work on a subset of supported OS seems like too much work to be supported for a long-term realistically. Also if someone hacks your computer, then the keystore is most likely accessible too, so it wouldn't help much. 1 Quote Link to comment Share on other sites More sharing options...
rugk Posted August 1, 2017 Author Report Share Posted August 1, 2017 Ah, you misunderstood what I mean: I do not talk about the servers and the lobby db. It is good you use PBKDF2 there, but hopefully you also salt it and maybe even switch to a better key stretching algorithm such as bcrypt or scrypt. https://crackstation.net/hashing-security.htm is a good doc for this. In any case, I was not talking about this. I rather meant how the password is saved locally on the device where 0ad is running on. This is currently done in the config/user.cfg file. That is what could be improved by using the GNOME/KDE/etc. keyring. Doing so on a server would not make sense… Quote Link to comment Share on other sites More sharing options...
Loki1950 Posted August 1, 2017 Report Share Posted August 1, 2017 That is a Linux only solution what about OSX and Windows they would need separate code and be subject to policy changes on both platforms and a maintenance nightmare even the Linux solution is not trivial to implement, multi-platform development is always a compromise dependent on the availability various libraries on the relevant platforms. Enjoy the Choice 1 Quote Link to comment Share on other sites More sharing options...
rugk Posted August 1, 2017 Author Report Share Posted August 1, 2017 Actually, it's worse… You need an implementation for each desktop envoriment on Linux (KDE, Gnome), but you are not correct that it is Linux-only. Also Mac OS has a keychain… Windows is, well…, Windows and does not really have such a thing. There may be some ways, but if it is not possible then just fallback to the current method of plain-text storage. Generally I think such a thing can be maintained by the community quite well and I also hope that there are some libraries available, which do implement this for all OSes. Nobody said the wheel must be reinvented here. Quote Link to comment Share on other sites More sharing options...
leper Posted August 1, 2017 Report Share Posted August 1, 2017 We are hashing the password on the local machine and only storing that. If you are worried about your password getting compromised you should be more interested in getting TLS enabled, which might need some work to get some Let's Encrypt cert handed to the lobby server, and then switching the authentication mechanism used to one that only stores the hash on the server (in our case the hash of the hash of whatever the user enters) (and yes, this would mean invalidating all accounts currently existing). Your attacker definition seems to include at least read access to your local file system, in which case you are more than screwed already. If you are considering backups, well encrypt those, same for your file system in case you are worried about that. The keyring "solution" has quite a few issues. What if a user changes their OS? What if they just change their desktop environment? What if they don't use one? And all of that doesn't really do anything but protect you against an attacker that allegedly already has quite some access, at which point they could just hook the game and get your password. If you really don't want that hash to be stored in the config file, write a patch that adds a checkbox to save the password only when it is checked. While you're at it you might also want to prevent copying the text that is in the password field. Also don't use the same password for some random game you found on the internet as you do for your banking or your nuclear power plant controls. And don't use quite a few other programs that save passwords, you might be surprised by quite a few (I'll just list Pidgin here, since that seems somewhat similar to the lobby). 3 Quote Link to comment Share on other sites More sharing options...
rugk Posted August 1, 2017 Author Report Share Posted August 1, 2017 Beginning with end. Pidgin is really a good example. There you can install pidgin-gnome-keyring (see https://github.com/aebrahim/pidgin-gnome-keyring) and it saves them in the keyring. That's what would also be nice for 0ad. So now beginning at the top again… On 01/08/2017 at 8:32 PM, leper said: We are hashing the password on the local machine and only storing that. Expand That's interesting, if this is really true. Because in 0ad you actually provide an autocompletion, i.e. after having to enter the password once, you never need to enter it again. As a hash is an one-way function, you can now only sent the hash to the server… Is that what you are doing? If so that is insecure. At least for authenticating. You can additionally hash a password client-side, but it must be hashed on the server side too. See the article I linked earlier, headline "In a Web Application, always hash on the server". If you really do it in that way, this is a design flaw… On 01/08/2017 at 8:32 PM, leper said: If you are worried about your password getting compromised you should be more interested in getting TLS enabled Expand Ah, yeah, that's a fair point. But a different issue… On 01/08/2017 at 8:32 PM, leper said: then switching the authentication mechanism used to one that only stores the hash on the server (in our case the hash of the hash of whatever the user enters) Expand Is this what I've told before? If so, then again, just so you know: If you only hash on the client, that is not secure. On 01/08/2017 at 8:32 PM, leper said: Your attacker definition seems to include at least read access to your local file system Expand Yeah, but I have not invented those keychains nor the thread model. One could argue whether they are useful or not, and that is what you are doing here, but some users may perceive them to be useful and in certain scenarios they also likely are. (consider a multi-user machine, where one user has physical access and can likely access other users data…) And they are a system that is well working… On 01/08/2017 at 8:32 PM, leper said: What if a user changes their OS? What if they just change their desktop environment? Expand Then they have to export that keychain and they likely do so when they know all their passwords are saved there. But in any case, that's not 0ad's problem. Keyrings are used by many applications and once users know that an application uses a keyring, it's fine. On 01/08/2017 at 8:32 PM, leper said: What if they don't use one? Expand No OS or no desktop environment? I doubt you can use 0ad without a desktop environment… On 01/08/2017 at 8:32 PM, leper said: write a patch that adds a checkbox to save the password only when it is checked. Expand Yeah, another good idea… but another issue… On 01/08/2017 at 8:32 PM, leper said: Also don't use the same password for some random game you found on the internet as you do for your banking or your nuclear power plant controls. Expand Very good advice. The thing is just that many (the majority?) people won't listen to it… That's the reality, unfortunately. And we cannot always fix the user, we have to fix the tech… Quote Link to comment Share on other sites More sharing options...
leper Posted August 1, 2017 Report Share Posted August 1, 2017 Quote That's [sic] what would also be nice for 0ad. Expand Patches welcome. Quote That's interesting, if this is really true. Because in 0ad you actually provide an autocompletion, i.e. after having to enter the password once, you never need to enter it again. As a hash is an one-way function, you can now only sent the hash to the server… Is that what you are doing? Expand Yes. Quote If so that is insecure. At least for authenticating. You can additionally hash a password client-side, but it must be hashed on the server side too. Expand See the comment earlier about us needing to invalidate all accounts if we were to switch to another SASL mechanism, since at least last I checked there was no way to nicely upgrade that otherwise. Quote See the article I linked earlier, headline "In a Web Application, always hash on the server". If you really do it in that way, this is a design flaw… Expand By the standard definition of "Web" this isn't a "Web Application" :P Yes, this does suck a little, however so far nobody really cared about passwords for some random game, and we don't even send the actual password (true, one could build a table for that, but the same is true if one hashes on the server; so whatever you do you just make it harder for some attacker once they have already gotten too far). Quote Is this what I've told before? If so, then again, just so you know: If you only hash on the client, that is not secure. Expand Secure against what? A server compromise? Well, no, but neither would it be if we did hash it there too. It just makes things a lot more work intensive. Quote Yeah, but I have not invented those keychains nor the thread[sic] model. One could argue whether they are useful or not, and that is what you are doing here, but some users may perceive them to be useful and in certain scenarios they also likely are. Expand One could store the password in some password manager or keychain and just copy it into the game every time one logs in. That'd require not storing the password as an option though. Quote (consider a multi-user machine, where one user has physical access and can likely access other users data…) And they are a system that is well working… Expand So they should use file system encryption, or encrypted containers. And how many multi-user machines are likely to run games and include users that don't trust each other? Quote No OS or no desktop environment? I doubt you can use 0ad without a desktop environment… Expand I haven't heard of anyone deciding to run it atop of a rump kernel so far, but I don't consider that impossible. Without a desktop environment, I haven't run one of those for years. Quote Very good advice. The thing is just that many (the majority?) people won't listen to it… That's the reality, unfortunately. And we cannot always fix the user, we have to fix the tech… Expand If someone uses the same password for their nukes (instead of the default 00000000) and some random game they deserve what they get. The user will get more stupid to work around your "fixed" technology, so you can either make things useless to people able to read the documentation, or you should stop rewarding people unwilling to read. 1 Quote Link to comment Share on other sites More sharing options...
rugk Posted August 5, 2017 Author Report Share Posted August 5, 2017 (edited) On 01/08/2017 at 11:41 PM, leper said: See the comment earlier about us needing to invalidate all accounts if we were to switch to another SASL mechanism, since at least last I checked there was no way to nicely upgrade that otherwise. Expand No, I think you do not have to do this. So currently your algo is: CLIENT --> SERVER send_to_server(hash(pwd)) --> store(sent_pwd) Now, just change it to: send_to_server(hash(pwd)) --> store(hash(sent_pwd)) That only requires some server changes, and you can just go through all passwords once and hash them. Not even the client needs updating here,. so that seems to be 100% compatible. On 01/08/2017 at 11:41 PM, leper said: By the standard definition of "Web" this isn't a "Web Application" Expand Come on. Now don't get nit-picky here… You know that the whole article also applies to your system. The 0ad client is basically the "browser" and your server is the server. On 01/08/2017 at 11:41 PM, leper said: (true, one could build a table for that, but the same is true if one hashes on the server; so whatever you do you just make it harder for some attacker once they have already gotten too far). Expand Yeah, not taking rainbow tables into account here. (You should use a salt to protect against this.) The attack is something different… Again let's talk about why we hash passwords (on the server): Quote It is completely possible to store a password in plain text on a server[…].The reason that passwords are hashed is because the problem isn't the authentication, but the storage. If the server is ever compromised, the attacker would immediately have access to all user accounts as they would now know the secret used for authentication of the users. […]So, the problem with client side hashing is that it effectively makes the result of the hash the password rather than the password. Expand And that's why we hash on the server. Is the server compromised anyone can just use the hash to login. If every site would do so, an attacker does not even need to know the password itself for impersonating a user, but just the hash… As the Stackexchange answer goes on: Quote Put another way, while it does provide some minor protections, from the point of view of the server, the client side hash should be treated as if it was the user's direct password. It provides no more or no less security on the server than if the user had directly given their password and should be protected as such. Expand It is not bad you hash on the client. It is just bad that you do not hash on the server. So you know now, that this is bad… On 01/08/2017 at 11:41 PM, leper said: Secure against what? A server compromise? Well, no, but neither would it be if we did hash it there too. Expand No, exactly that's the thread model. You do not need to hash passwords at all if you think your server can never be compromised. That's the whole reason for hashing passwords and no, they are secure if hashed properly (bcrypt and salt e.g.) even if the server is compromised. And we have plenty of examples of that. You still know the Ashley Madison hack two years ago? Yeah, all the data was exposed, but their passwords were actually protected/hashes properly. One tried to crack them for 5 days and still only got some of the most easy/supid passwords such as 12345 and so on. On 01/08/2017 at 11:41 PM, leper said: One could store the password in some password manager or keychain and just copy it into the game every time one logs in. That'd require not storing the password as an option though. Expand Yeah, basically as a keychain also just is a password manager, of course. But – even if the game would not store the password automatically – it is really cumbersome (especially with fullscreen applications and so on) to copy & paste the password always… On 01/08/2017 at 11:41 PM, leper said: I haven't heard of anyone deciding to run it atop of a rump kernel so far, but I don't consider that impossible. Expand Seriously if there is such a freak doing that then he can also care for the password or On 01/08/2017 at 11:41 PM, leper said: If someone uses the same password for their nukes (instead of the default 00000000) and some random game they deserve what they get. Expand Seriouly, please do not be that rude to random people on the internet. If one uses 1234 as a password it can get cracked easily even when properly hashed anyway. Actually one could just try it o0ut by hand against the live service. So you do not have to care about that people. But actually depending on what stat you look at at least 50% of all users reuse their password. So they are all stupid people, who deserve it? Do not judge other people out of the way, you actually do it. Not everybody can or does always have such a good way to remember 500 different passwords… Not everybody (actually, sadly, few) people use password managers, etc… But in any case we are getting offtopic. We do not have to analyze how people use passwords, what they use etc. or how secure a keyring is or so… The only point I am making is that: 1. Saving password locally in plain-text/locally hashed is suboptimal and could be improved. But this is not urgent. 2. What is actually a urgent matter is that you do not hash passwords on the server. And as I explained, it could be made without any interruption/compatibility change or so. And yes, I know, you are "just a game", but you are also a "password provider" and this comes with responsibility. Edited August 5, 2017 by rugk Quote Link to comment Share on other sites More sharing options...
elexis Posted August 5, 2017 Report Share Posted August 5, 2017 Since the salt is the same for everyone, one can still create only one table afaics. The current hashing does not protect from a client attacker but prevents people with read access to the hashed password from finding out which password players use for the nukes in case they use the same password for 0 A.D., so it's not entirely useless. People with read access to the hashed password are moderators. The password is explicitly removed from the logfiles, but in case the user config gets leaked somewhere, it would have that little effect (so the current hashing is not entirely useless). Admittedly using some kind of private/public flavored crypto would be an improvement. Quote Link to comment Share on other sites More sharing options...
leper Posted August 5, 2017 Report Share Posted August 5, 2017 Quote No, I think you do not have to do this. [...] That only requires some server changes, and you can just go through all passwords once and hash them. Not even the client needs updating here,. so that seems to be 100% compatible. Expand Quote See the comment earlier about us needing to invalidate all accounts if we were to switch to another SASL mechanism, since at least last I checked there was no way to nicely upgrade that otherwise. Expand Expand Except it requires updating the clients to only use that mechanism (you'd want to prevent clients from using the old one, right?), someone to actually do the work, quite some testing so it actually works properly. There is a difference between what is the required amount of work needed in theory, and what needs to be done in practice. Quote Come on. Now don't get nit-picky here… You know that the whole article also applies to your system. The 0ad client is basically the "browser" and your server is the server. Expand You suddenly used the word "Web". If you start using words in a context where they just appear to indicate that you didn't think about the problem, then you'll have to deal with being called out on that. Quote And that's why we hash on the server. Is the server compromised anyone can just use the hash to login. If every site would do so, an attacker does not even need to know the password itself for impersonating a user, but just the hash… Expand If the server is compromised an attacker doesn't even need to look at the passwords to impersonate anyone. And in this case they could just try a downgrade attack to get the actual password (we did disable the plain mechanism, but a few of the supported ones aren't that hard to break). Quote It is not bad you hash on the client. It is just bad that you do not hash on the server. So you know now, that this is bad… Expand We've known that for quite a while, the issue is that someone needs to do the work. Quote No, exactly that's the thread model. Expand threat model Quote You do not need to hash passwords at all if you think your server can never be compromised. That's the whole reason for hashing passwords and no, they are secure if hashed properly (bcrypt and salt e.g.) even if the server is compromised. Expand No, they are not secure. You just increase the amount of work an attacker needs to do to get possible candidates that match (and how many users do you know with very long passwords (phrases would be better, but I digress). Quote One tried to crack them for 5 days and still only got some of the most easy/supid passwords such as 12345 and so on. Expand That's not really long, then again you haven't defined your threat model at all, so if the attacker is someone with brains and a Pentium, then you might have a point. If we are talking about server farms or tons of graphics cards that's something completely different. Quote [...] it is really cumbersome (especially with fullscreen applications and so on) to copy & paste the password always… Expand Windowed mode without decorations, or run things in some other X server, or copy the password, then start the game, or get a better program to handle your passwords. Quote Seriously if there is such a freak doing that then he can also care for the password or Expand Some things are more interesting than others to work on. And so far I've seen lots of talk and no single line of code. Quote Seriouly, please do not be that rude to random people on the internet. Expand Welcome to the internet, I see you must be new here. Quote If one uses 1234 as a password it can get cracked easily even when properly hashed anyway. Expand Only if you try common passwords, at which point the issue is that you are using a common password. One could just try the list from that one Yahoo! leak and get quite far. Quote Actually one could just try it o0ut by hand against the live service. So you do not have to care about that people. Expand Unless rate limiting kicks in. True one can just use something distributed to try those, but that wasn't listed in the attacker model. Quote But actually depending on what stat you look at at least 50% of all users reuse their password. Expand And there is no issue with that, as long as the places they reuse it for are things that for some reason require an account, so they just use hunter2, because if it gets leaked nobody will even care. Quote So they are all stupid people, who deserve it? Expand Depends on whether they used the same password for something that doesn't need a lot of security as for something that most likely should. Quote Do not judge other people out of the way, you actually do it. Not everybody can or does always have such a good way to remember 500 different passwords… Not everybody (actually, sadly, few) people use password managers, etc… Expand Why not? Because someone might get offended because they themselves are doing stupid things? How do they remember 500 accounts? Quote 1. Saving password locally in plain-text/locally hashed is suboptimal and could be improved. But this is not urgent. Expand But something that you could fix quite easily (probably a diff with about 5 lines (and most of that is adding a checkbox)). Quote 2. What is actually a urgent matter is that you do not hash passwords on the server. And as I explained, it could be made without any interruption/compatibility change or so. Expand Could maybe be done without any interruption, but most likely couldn't. At least it didn't seem that way last time I checked (which allegedly has been quite some time). Quote And yes, I know, you are "just a game", but you are also a "password provider" and this comes with responsibility. Expand Well, I'm not responsible for the lobby in any way anymore, so meh. Also you should really define threat model, attacker model, and most of all help with fixing things instead of writing lots of prose. (Eg upgrading the lobby server to something that isn't mostly unsupported, enabling TLS for lobby communication, getting the actual game download links to use HTTPS, ...) Quote Since the salt is the same for everyone, one can still create only one table afaics. Expand It isn't. Quote People with read access to the hashed password are moderators. Expand Not server admins? 1 Quote Link to comment Share on other sites More sharing options...
rugk Posted August 6, 2017 Author Report Share Posted August 6, 2017 On 05/08/2017 at 2:59 PM, elexis said: Since the salt is the same for everyone, one can still create only one table afaics. Expand Exactly. And that's why you should use an unique salt for each password/user and save it together with the password. Maybe read the links I've provided, there is plenty of information how this should be done… On 05/08/2017 at 11:55 PM, leper said: Except it requires updating the clients to only use that mechanism (you'd want to prevent clients from using the old one, right?), someone to actually do the work, quite some testing so it actually works properly. Expand No, why? I explained that previously. Client send exactly the same password as usually… Servers just hash it (again!). No client work… On 05/08/2017 at 11:55 PM, leper said: There is a difference between what is the required amount of work needed in theory, and what needs to be done in practice. Expand Would you mind to elaborate this? I see no difference here. On 05/08/2017 at 11:55 PM, leper said: You just increase the amount of work an attacker needs to do to get possible candidates that match (and how many users do you know with very long passwords (phrases would be better, but I digress). Expand Exactly that's the thing we want. If you would not care, sure, go ahead and do not hash passwords at all and store them in plain-text! If you do not value your user's securty at all, do so, but please do not complain when you are being called out when something bad happens… On 05/08/2017 at 11:55 PM, leper said: (probably a diff with about 5 lines (and most of that is adding a checkbox)). Expand To get back to topic: I originally requested keychain integration. I could not see that this thread/topic was going such crazy… (And keychain integration needs more than 5 lines.) I also think it makes no sense to discuss three different feature suggestions in one thread. This is going weird here, anyway, already… So I am opening issues in trac for all discussed things, in order to track them properly and – most importantly – separate from each other. Quote Link to comment Share on other sites More sharing options...
rugk Posted August 6, 2017 Author Report Share Posted August 6, 2017 HTTPS for lobby: https://trac.wildfiregames.com/ticket/4705 Checkbox for not saving password: https://trac.wildfiregames.com/ticket/4708 Hash passwords on server: https://trac.wildfiregames.com/ticket/4709 Passwords in OS keychain: https://trac.wildfiregames.com/ticket/4710 Secure downloads: https://trac.wildfiregames.com/ticket/4706 Quote Link to comment Share on other sites More sharing options...
leper Posted August 6, 2017 Report Share Posted August 6, 2017 Quote No, why? I explained that previously. Client send exactly the same password as usually… Servers just hash it (again!). No client work… Expand Because you haven't even bothered to look at the actual code at work here, so your "proposal" will fall apart when confronted with reality. The first hint would be that the lobby doesn't use HTTP, so using HTTPS would be more than cumbersome. Same for that secure downloads ticket where you have more text that confuses issues, doesn't clearly state the actual issue (or at least I stopped reading after seeing that wall of text), and ignores that the downloads are already mirrored somewhere. Also tickets are for somewhat workable issues, not long walls of text that call for discussion. I'd strongly suggest finding out what is actually used before all those proposals, as currently you are just making it harder for anyone actually wanting do work on any of those. Quote Link to comment Share on other sites More sharing options...
rugk Posted August 6, 2017 Author Report Share Posted August 6, 2017 Are you kidding? I am trying to help and you write this nonesense… I explained each issue in every detail, presented solutions instead of just complaining and you are complaining that you have to read too much text? If that is your problem do something else and do not reply me – you just have to read so much text afterwards. Downloads are mirrored. Yes and I don't care. Nobody cares. No user ever notices the download mirrors… What are you even trying to say? And if no HTTPS is used you can just say that, instead of defaming me or pushing blames here. The easy logical alternative is TLS under whatever protocol you actually use. And BTW: I am a user of 0ad. Not a dev. So I do not look at the code, obviously. Do you want to require that one has to browse through the source before opening issues? Okay, sure, I do not report any bugs anymore without looking at the source. And I should suggest everyone to do the same. Then you will likely have a big problem. Your "free" QA department you have just vanished. I was very calm and tried to excuse every thing you said, but at some point you have to stop. I am very willing to help and to do something constructive, but not in that way, with such destructive replies. I thought you care about your game, but at least for @leper, I am obviously wrong. Quote Link to comment Share on other sites More sharing options...
leper Posted August 6, 2017 Report Share Posted August 6, 2017 Exept solving a different issue that doesn't apply in every detail doesn't help, but pointing that out seems to be nonsense. Ah well, I guess doing research first seems to be a strange way of operation, same as first asking questions instead of providing "complete" "solutions". 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.