Jump to content

rugk

Community Members
 View Profile  See their activity

  • Posts

    36

  • Joined

  • Last visited

 Content Type 

Posts posted by rugk

  6. Save own multiplayer/lobby password in OS' keyrings

    in Game Development & Technical Discussion

    Posted

    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.

  9. Insecure transmission of statistics/application feedback

    in Game Development & Technical Discussion

    Posted · Edited by rugk

    10 minutes ago, Lion.Kanzen said:

    we can say our user something like: use easy password but don't use your more valuable password like email password or steam...Netflix.

    Yes, and you can also say people they should not kill each other… Hmm, they seem to do it anyway. :D
    You can say many things, yes. Paper does not blush. (that's a proverb)

  10. Insecure transmission of statistics/application feedback

    in Game Development & Technical Discussion

    Posted

    1 minute ago, Lion.Kanzen said:

    Come on if a hacker wants your password they can do here, in steam

    I do not know if Steam uses HTTPS, but I really think they use HTTPS. But I think this is another typo…

    Also in this issue no password is transmitted. This issue is not about any password at all… You seem to have replied to the wrong topic or so.

    What I take from your reply is: There is not 100% security. That is correct, of course, but that does not mean you should not use HTTPS. I mean your house door can also be broken – does that mean, you do not use a door?
    Also I am not  such a big target as HBO.

    And finally when HTTPS is not used you do not have to "hack" anyone. YOu can just sit on a chair next to them, when they are logged in the same WLAN as you. It has nothing to do with hacking in the sense of breaking into computers.

  12. Insecure transmission of statistics/application feedback

    in Game Development & Technical Discussion

    Posted

    1 minute ago, Lion.Kanzen said:

    myopic

    Shortsighted?

    Yes, if I had the programming language knowledge (C/C++ or whatever you use) I could, but this is a not that easy issue, you may need interaction with openssl… or use curl, whatever… So it is not really easy. And it should be done properly, so better someone else does it.

    My reply about open source was just because of elexis' reply. I still have no clue about what he was trying to say.

  15. Save own multiplayer/lobby password in OS' keyrings

    in Game Development & Technical Discussion

    Posted

    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.

  16. Save own multiplayer/lobby password in OS' keyrings

    in Game Development & Technical Discussion

    Posted · Edited by rugk

    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" :P

    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.

  19. Save own multiplayer/lobby password in OS' keyrings

    in Game Development & Technical Discussion

    Posted

    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…

  20. Save own multiplayer/lobby password in OS' keyrings

    in Game Development & Technical Discussion

    Posted

    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. :)

  21. Flatpak and snap

    in Game Development & Technical Discussion

    Posted

    Flatpak and snap are two new technologies for distributing software. As far as I see you currently cover most Linux distros, so it is not really needed yet, but it could be an idea for offering 0ad in another way in the future.

    The advantages are that you can built the release yourself and it is (often) sandboxed. However, it may be large as you need to include all dependencies.

  22. Save own multiplayer/lobby password in OS' keyrings

    in Game Development & Technical Discussion

    Posted

    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…

  23. Save own multiplayer/lobby password in OS' keyrings

    in Game Development & Technical Discussion

    Posted · Edited by rugk

    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… :rolleyes:

     

    Edit: Clarified that I mean the password saved locally…

  24. Insecure transmission of statistics/application feedback

    in Game Development & Technical Discussion

    Posted · Edited by rugk

    In the config/log I noticed "userreport.url", which by default points to http://feedback.wildfiregames.com. No HTTPS, no basic security… :(

    You got HTTPS on your public site some time ago and I thought this, of course, also applies to your ("friendly") tracking feature (really, no offense intended!) in 0ad. However, as it seems, that's not the case. So it should be fairly easy to add HTTPS there, as the load is likely less than on any other (public) page you host. :)

    So when the data is public anyway, why use HTTPS here?

    1. First of all, all (or almost all) standard arguments apply here.
    2. As all tracking features, this of course also includes sensitive info. Yes! You submit a unique ID there, so… Attackers can intercept and manipulate that. And hardware details… not everyone wants to let those flow through the net in such a way…
    3. When the data is published, it may be aggregated. The submitted data as raw data should be kept confidential… And you promise to only publish data, which cannot be used for identification.
    4. Using this data an attacker can track a device through multiple WLAN/networks/etc. There may be other ways, but in any case, you should protect that information.
    5. You do not say that this information can be intercepted. In your in-game statement, you only state the data goes to 0ad. Well… if it is not transmitted in an encrypted fashion anyone can sniff it. I.e. you basically lie here… And users may be okay with giving this info to you, but not to anyone, who happens to be on the way (attackers in wifi, ISP, any big three-letter agency, another ISP, …).

  25. Freezes in Wayland

    in Bug reports

    Posted

    Yeah, I also think it is some driver issue… Had similar issues with another application (although a completely different area), see this issue.

     

    I could reproduce the issue generating a random game against KI (but I think the settings do not matter, also happened in multiplayer in the past). This time I could get past the loading screen and it even showed me the initial view on the CC, Music kept playing, but I could not move my mouse and also no keyboard input seems to be considered anymore.
    Logs attached. (Note that one successful game against KI offline is included, incl. win) But the logs seem to be useless, interestinglog was even empty.

    freeze.tar.xz

    • Like 1
×
×
  • Create New...