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… 2 hours ago, leper said: We are hashing the password on the local machine and only storing that. 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… 2 hours ago, leper said: If you are worried about your password getting compromised you should be more interested in getting TLS enabled Ah, yeah, that's a fair point. But a different issue… 2 hours ago, 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) 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. 2 hours ago, leper said: Your attacker definition seems to include at least read access to your local file system 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… 2 hours ago, leper said: What if a user changes their OS? What if they just change their desktop environment? 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. 2 hours ago, leper said: What if they don't use one? No OS or no desktop environment? I doubt you can use 0ad without a desktop environment… 2 hours ago, leper said: write a patch that adds a checkbox to save the password only when it is checked. Yeah, another good idea… but another issue… 2 hours ago, 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. 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 That's [sic] what would also be nice for 0ad. Patches welcome. 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? Yes. 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 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. 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… 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). 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. 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. 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. 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. (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… 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? No OS or no desktop environment? I doubt you can use 0ad without a desktop environment… 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. 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… 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 2.8.2017 at 1:41 AM, 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. 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 2.8.2017 at 1:41 AM, leper said: By the standard definition of "Web" this isn't a "Web Application" 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 2.8.2017 at 1:41 AM, 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). 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. 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. 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 2.8.2017 at 1:41 AM, leper said: Secure against what? A server compromise? Well, no, but neither would it be if we did hash it there too. 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 2.8.2017 at 1:41 AM, 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. 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 2.8.2017 at 1:41 AM, 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. Seriously if there is such a freak doing that then he can also care for the password or On 2.8.2017 at 1:41 AM, 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. 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 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. 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. 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. 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. 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. 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… 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). 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… We've known that for quite a while, the issue is that someone needs to do the work. No, exactly that's the thread model. threat 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. 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). 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. 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. [...] it is really cumbersome (especially with fullscreen applications and so on) to copy & paste the password always… 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. Seriously if there is such a freak doing that then he can also care for the password or 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. Seriouly, please do not be that rude to random people on the internet. Welcome to the internet, I see you must be new here. If one uses 1234 as a password it can get cracked easily even when properly hashed anyway. 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. Actually one could just try it o0ut by hand against the live service. So you do not have to care about that people. Unless rate limiting kicks in. True one can just use something distributed to try those, but that wasn't listed in the attacker model. But actually depending on what stat you look at at least 50% of all users reuse their password. 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. So they are all stupid people, who deserve it? 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. 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… Why not? Because someone might get offended because they themselves are doing stupid things? How do they remember 500 accounts? 1. Saving password locally in plain-text/locally hashed is suboptimal and could be improved. But this is not urgent. But something that you could fix quite easily (probably a diff with about 5 lines (and most of that is adding a checkbox)). 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. 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). And yes, I know, you are "just a game", but you are also a "password provider" and this comes with responsibility. 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, ...) Since the salt is the same for everyone, one can still create only one table afaics. It isn't. People with read access to the hashed password are moderators. 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 23 hours ago, elexis said: Since the salt is the same for everyone, one can still create only one table afaics. 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… 14 hours ago, 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. No, why? I explained that previously. Client send exactly the same password as usually… Servers just hash it (again!). No client work… 14 hours ago, 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. Would you mind to elaborate this? I see no difference here. 14 hours ago, 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). 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… 14 hours ago, leper said: (probably a diff with about 5 lines (and most of that is adding a checkbox)). 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 No, why? I explained that previously. Client send exactly the same password as usually… Servers just hash it (again!). No client work… 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.