Jump to content


Community Members
  • Content count

  • Joined

  • Last visited

Community Reputation

6 Neutral

About rugk

  • Rank

Recent Profile Visitors

242 profile views
  1. 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.
  2. Ahh now I understand this sentence. Yes, of course, I think everybody should know.
  3. 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.
  4. 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)
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. 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
  10. 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.
  11. 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.
  12. 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
  13. Okay, great. What about flatpaks? We need them both.
  14. 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…
  15. 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.