Jump to content

rugk

Community Members
  • Content Count

    36
  • Joined

  • Last visited

Everything posted by rugk

  1. Yeah, thanks for the link. (BTW the like feature in this forum is not working.)
  2. BTW, also created some ad (sources available) for the 34c3. See this thread for details: https://wildfiregames.com/forum/index.php?/topic/23610-advertisment-on-34c3/
  3. Hi, thanks for all the teams. I changed the position of the link: https://github.com/rugk/0ad-ad-34c3/blob/master/0ad-banner_originalpng1.png Also, I've of course exported the files as PNGs/JPGs, SVG was just for creating them.
  4. It is live, in two versions …
  5. Hi, I am goi ng to publish an advertisment for this nice game on 34c3. This is how it looks currently: https://github.com/rugk/0ad-ad-34c3/blob/master/0ad-banner.svg If you have any suggestions or so, feel free post them here.
  6. 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.
  7. Ahh now I understand this sentence. Yes, of course, I think everybody should know.
  8. Again: This issue is not about passwords. Also BTW, this issue is already confirmed to be "likely" solved in the next release as @implodedok said in #2. And that is okay. I also opened a trac issue. So I see no reason for discussing this anymore. And even if, then please discuss it in a serious way.
  9. Yes, and you can also say people they should not kill each other… Hmm, they seem to do it anyway. You can say many things, yes. Paper does not blush. (that's a proverb)
  10. 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.
  11. 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
  12. 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.
  13. I do not understand your sentence, but my general answer would be: 0ad is open-source, so everybody can "certify" any "defense mechanism" in the game.
  14. Every heard of three-letter agencies, which do exactly that and do not target a user individually? In any case opened a trac issue for that: https://trac.wildfiregames.com/ticket/4707
  15. 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… No, why? I explained that previously. Client send exactly the same password as usually… Servers just hash it (again!). No client work… Would you mind to elaborate this? I see no difference here. 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… 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. 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. 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. 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): 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: 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… 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. 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… Seriously if there is such a freak doing that then he can also care for the password or 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.
  17. rugk

    Freezes in Wayland

    Okay, maybe it has not that much to do with Wayland – although I feel it happens there more often, but it also froze in X sometimes. freeze-x.tar.xz
  18. Okay, great. What about flatpaks? We need them both.
  19. 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… 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… Ah, yeah, that's a fair point. But a different issue… 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. 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… 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. No OS or no desktop environment? I doubt you can use 0ad without a desktop environment… Yeah, another good idea… but another issue… 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. 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 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. 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. 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…
  24. 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? First of all, all (or almost all) standard arguments apply here. 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… 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. 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. 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. rugk

    Freezes in Wayland

    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
×
×
  • Create New...