leper
-
Posts
1.290 -
Joined
-
Last visited
-
Days Won
30
Posts posted by leper
-
-
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
-
-
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
-
-
Not without changes to both the simulation (to enable it to set the light environment; currently it doesn't even know that there is one) and the renderer.
-
5
-
-
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
-
-
-> Try prop- instead of prop_
I was unsure about this, but I checked the code, and both work.-
1
-
-
FMOD might be gratis for "small" users, but still uses a proprietary license, which prevents us from using it.
-
3
-
-
Techs can replace actors, which would allow you to do that. Not very nice since you might have to nearly duplicate the actor (use those file includes where possible), but currently there is no other way.
-
Check out the Upgrade component. Since the entity schema documentation is currently waiting on someone to update it (yes, I'm totally not using this post to get work on that going again), you might want to read the top of simulation/components/Upgrade.js to know what you can use.
-
You don't have to build the exe yourself since we do have windows autobuilds in the repo, which means that you don't need VS.
Would I be able to redistribute the pyrogensis.exe with new releases of my game? I realized a problem with using the dev build is I would have to base all my mod's releases on when 0AD releases a public version. I have a really frequent release schedule for updates and I don't know that I want to tie my releases around 0AD's public stable builds.
If you also provide the source code (required by the license). I guess looking into how we package the game itself would be a good idea, you might want to look into the files in source/tools/dist. A word of caution though as there is a higher likelihood for bugs (OOS especially, since the dev version is less tested in multiplayer) when using random snapshots.
I mentioned using a VCS earlier, using branching would allow you to support the latest stable version and work on the next one without too much difficulty. In some cases you might run into issues when new code needs to be added to the engine (read c++ side), so you wouldn't be able to add those things until a new stable version is released.
There have been a few discussions about separating engine releases from game releases, which would help with a frequent release schedule. However most simulation related changes don't require c++ changes, so just shipping newer JS components should help with frequent relases. So you'd just have more recent JS code in your mod, and wait with adding certain features that require c++ changes until a new release is out.-
4
-
-
I guess you should really start using SVN, so you don't run into lots of issues when a new release shows up, but only have to fix a few things while the changes are still well understood and the people who changed things are around.
Full error output would be nice, see GameDataPaths for where the logs are stored. Being able to look at what your mod looks like would also be nice. (Try using some version control system, and having that somewhat public would help with debugging things.)
To disable your mod (assuming you don't just want to rename/move your main menu files), just delete the user.cfg file (see the wiki page linked above for where to find it).-
1
-
-
However for reasons of sanity I guess you don't want
"units/hylian/hylian_citizen" : "units/hylian/hylian_citizen",
there, but rather something like"skirmish/units/default_citizen" : "units/hylian/hylian_citizen",
where you'd need to create that skirmish/units/default_citizen template. Or keep the skirmish entities that currently exist and just replace them with what you want (might not work perfectly given what quantities you want though). -
Yes, that's the section.
No, count does not work there, same as your proposal. This is an object or well set, so multiple definitions of the same key ("skirmish/units/default_infantry_melee_b") are either invalid or at the very least pointless since just one of them applies (depending on the parser the first or the last one).
If you want more units you will have to add other skirmish entities to the maps, and then just replace them with nothing for the civs that don't get extra units. Or we have to find a way to spawn units when a unit is spawned (I seem to recall someone running into issues with that and there is some ticket I wanted to look into related to that). -
The starting entities are just used in random maps. Skirmish maps use preplaced skirmish entities that get replaced by civ specific units. The generic replacements (including {civ} handling which replaces that with the civ code) is done in the skirmish templates (simulation/templates/skirmish/), and different replacements are specified in the civ.json files under SkirmishReplacements.
So I assume you might want to provide a different version of the skirmish templates (in case you want to be incompatible with the 0ad civs right now), or provide lots of replacements in the civ.json files. Assuming you don't want to follow the naming convention the game uses (which I guess is a sensible choice). -
17 hours ago, The Undying Nephalim said:
I mean showing up in the UI at the top left. Say I want faction A to have a Gold resource but faction B to not have any Gold, I don't want the Gold icon or numbers to show up in the top left. Is this at all possible in the engine?
That's some gui coding that should be relatively easy to do. Currently it isn't supported, but that is because so far nobody wanted different resources there. It might also need a few checks in the engine related to tributing resources, and possibly looting things. @s0600204 might be interested in improving the resource modding support even more.
14 hours ago, wowgetoffyourcellphone said:Well, in that case, all mods be a little hacky.
But hacky solutions do have a tendency to break, I guess I don't need to tell you that. So striving for proper code does help with reducing the maintenance work going forward.
-
4
-
-
1) Is it possible for a ranged attack to spawn a new unit upon impact? Ideally, could it be made to have a random chance of spawning as opposed to 100% of the time? I have some siege weapons that launch units at enemies and over walls, this would be really handy if possible.
Needs a small amount of code. This is related to the other damage tickets (which by now provide a relatively nice basis for this) #1909 #1910 #1911 #1912, which are being worked on by a contributor, so having a user for a few of those things will help with getting this written.
2) Is it possible to interact with corpses of dead soldiers in any way? There are a lot of undead in Hyrule, and being able to raise undead from fallen enemies would be great. In addition, units being able to "eat" corpses in order to regenerate health would be great.
33) Can units return a dead unit back to life before the corpse vanishes? Could a unit "repair" a dead unit back to life, such as the Atlantean Automatons from Age of Mythology?
2) Corpses are by default made unelectable, but I think that might be overridable. Not sure if C++ or simple template editing
33) Could be done but it’s not implemented. Adding repairable to a unit, and making it so it collapses from let say 10% of the health, could work
Ah, #2951 paying off. You just have to change what a corpse is. Corpses are "corpse|template" template names, which means the special corpse filter (the file named corpse.xml) in templates/special_filter defines what happens with the original template. So to make them selectable just add<Selectable merge=""/>
to that template.
For repairing/raising them from the dead you could take some inspiration from the foundation template and play with the initial health in addition to some health decay (negative regeneration or something).
For eating this sounds like something that was done at some point in the past, however that code was more of a quick hack to get it working and might need some updates to actually work. Also it has the limitation of preventing those units from gathering at all, possibly more limitations it has been a while.
8) Is it possible to give units a second health bar that can regenerate? Think Protoss Shields from Starcraft.
8) It has been done for capturing, so it would have been somewhat an extent of that, then again it’s not natively supported
Adding another bar is easy. Having some shield should also be somewhat easy if the health component does check if that is present and first does damage to the shield and only afterwards decreases health.
9) Is multi-target (not splash damage) attacks possible? For instance a projectile hits an enemy and then bounces to the nearest enemy, or multiple projectiles that attack multiple targets.
For just firing multiple projectiles that is what buildings and ships do. But the code that does that is somewhat hacky. So currently doable by using workarounds. Projectile bouncing would need code.
10) Adding new resources seems very possible, but is it possible for specific resources to only show up for specific civs instead of all civs?
If showing up for specific civs means just them being able to gather it, then yes, just don't specify any other resources in those ResourceGatherer tags for that civ.
12) Is it possible to make it so that a unit has a chance to "dodge" attacks or rather avoid taking any damage from an attack?
Alternatively, is it possible to make it so enemy units also take damage from attacking certain units?
22) Can a unit gain health from attacking an enemy unit?
If we care just about not taking damage this could be doable by modifying cmpDamageReceiver to just ignore a few attacks randomly.
Or we modify it to also get some information about who is causing the damage, which would allow some more fine grained possibilities, then implement a custom cmpDamageReceiver (eg cmpDodgingArmour or something) and use that for those dodging units.
With that slight modification to the DamageReceiver interface to pass the attacker information along another implementation can just do a few fancy things: attack back (though one would have to directly reduce the health, else two such units fighting with each other might cause strange issues), something vampire style, etc.
14) Is it possible for an ability that heals all units over time within a player's territory?
With a little code, yes.
15) It is possible for all of the terrain withing a player's territory to be replaced with new terrain or a decal?
I guess one could place actors there that have some decal based on territory. That seems like a somewhat strange approach, however currently there is no (or maybe no nice) way to set the terrain texture.
16) Can buildings and units spawn more units on death?
There's cmpHealth's SpawnEntityOnDeath. That's just for a single unit though.
20) Is it possible for the worker units of a player to be uncontrollable and the AI automatically makes them seek out the nearest resources?
In some way, but it would most likely run into lots of issues and be a bad experience.
24) Can a unit generate resources from attacking enemy buildings?
There is a Loot component that in conjunction with the Looter component does something when an entity is destroyed, though that isn't quite what you asked for.
25) Can workers pray or otherwise interact with a building in order to generate resources, like in Age of Mythology?
Delenda Est might have a hacky way to do something like that. A nice implementation might need some work.
26) Can a building be set to immediately destroy or knock down all trees within a certain radius of itself?
Could be done with a trigger and a range query. So not right now but the code for that (apart from figuring out how to nicely hook that to the rest) should be quite simple.
27) Are there any targetable abilities (I've not noticed any on my playthroughs yet)? For example a unit has a Fireball ability. You click the ability, select a target, and your unit launches a fireball at the target.
One of the early patches that added healing worked like that. So it depends on what abilities you'd want, and if actually having buttons for those is the best way (which it might be if there are a few).
28) Sort of tied to the last question, can units be given an ability that allows them to teleport? If so, can it be limited to only the player's territory?if (cmpTerritoryManager.GetOwner(pos.x, pos.z) == cmpOwnership.GetOwner()) cmpPosition.JumpTo(pos.x, pos.z)
Or something along those lines, and with proper checks for conditions that should be handled.
29) Is it possible to decrease enemy units' line of sight when they are in a player's territory? What about slowing down their movement speed, attack rate, or other negative de-buffs?
There currently are no auras based on territory, if that gets added this should be quite easy, for now you might have to make do with range auras on territory roots.
32) Is it possible to make it so that a unit instantly spawns at a building's rally point, rather than from the building and then they move to the rally point?
Should be a roughly 3 line diff, maybe slightly more to make that behaviour changeable based on templates.-
1
-
-
Since I haven't seen any checks in that the input and output folders exist (and create them if they don't), I guess you should add those folders to the repository itself. Since git doesn't handle folders, but just files you'll have to do something like add an empty .gitignore file or similar to those folders and commit them.
-
2
-
-
Right, and I guess it would be best if TheUndyingNephalim also used SVN (at least it would help with future improvements), but for now I just mentioned it.
-
1
-
-
The version of the game is A22. But you can modify mod.json to work with A21.
In that case I guess the instructions should just enable the mod in the mod manager (in-game, under Tools & Options) and save that, then start atlas.
A22 isn't released yet, but there are currently RC (release candidate) builds available. (http://releases.wildfiregames.com/rc/)-
1
-
-
13 hours ago, The Undying Nephalim said:
- I notice sub-factions and things of that nature in the civ .json files. Might it be possible for a UI to pop up at the start of a match that lets a player pick between different heroes that give access to different units and technologies?
You could do that in-game by providing unlocking technologies that unlock one hero (and prevent the other technologies from being researched). (At least that was the way our generic civs (hellenes, celts) handled the choice quite some time ago.) One could possibly use a Trigger script and message box to make that decision if that is what you prefer.
13 hours ago, The Undying Nephalim said:- There are priest in the game, but are there any other plans for religion based mechanics?
Probably not, but "religion based mechanics" is quite vague. One could add some way to get some "religion" resource (similar to AoM) and then use that for those mechanics, but some details on what those mechanics might be would help with answering this.
7 hours ago, Itms said:13 hours ago, The Undying Nephalim said:- Is it possible to make certain land based units able to move into water?
This is possible without touching the engine in theory (and it would be a good test for the engine!) but it will come with a performance cost for the pathfinder.
Shouldn't that depend on whether the other classes (ships, big siege engines, etc) are still needed?
7 hours ago, Itms said:13 hours ago, The Undying Nephalim said:- Similar to Age of Empires 3, is there currently or future plans for map based NPC buildings that can be bought or allied with to get access to new units?
Not really but modding that is possible. Just write a new component for this logic and add it to your building template. You will need to mod the ProductionQueue component to make it interact with your custom component.
Depending on how exactly you want that to work that is already possible. At least WC3-style camps that can be "acquired" using capturing are already doable (and IIRC are present in Delenda Est). So if the requirement for buying them or making it depend on diplomacy isn't that strict there is no new code needed.
7 hours ago, Itms said:13 hours ago, The Undying Nephalim said:- Is there any plans, even if it's far off, for a turn based over-world campaign similar to Medieval 2? I'm willing to completely ditch this feature, though many of my followers are wondering if 0AD would ever have such a component.
Probably not a fully featured turn-based over-world campaign. We don't have definitive plans in this area but the "strategic map" we could have for campaigns would be largely less important than in Total War:Rome II for instance (I never played Medieval 2, sorry)
There are a few possibilities here. A WH4k DoW-style (or maybe CnC style) territory like map (without any real interaction apart from attack this thing now) should be doable with the very wip campaign infrastructure patch. Though I guess that falls short of a TW (basing this on Rome TW) quite a bit. One could emulate something like this (the AI would need quite some work though) by using triggers to block commands of other players for a "campaign turn" and add some way to end a turn. Actually starting matches might take some more work, I guess one could at least reuse parts of the campaign infrastructure if one decides to limit the available maps.
7 hours ago, Itms said:Your first screenshots look great!
You might need a different green grass ground texture so things blend in nicer, apart from that it does look great!
-
1
-
-
Depends on what kind of xml file you want to know about. (Some reading about how xml works (tags need to be closed) might be helpful, in case you haven't figured that out already.)
For actors you might want to read the Actors wiki page, which (judging from the edit history) should be up to date.
For other files look at the file format wiki pages, and the other pages for artists and modders listed on the wiki.
In case something isn't clear and you figured out how to improve it, do so (it is a wiki). Otherwise please do ask questions, it is quite hard to improve documentation if it isn't used or people don't point out issues.-
2
-
-
They can, you are just unable to use the system to run them at the same time.
-
1
-
-
See GameDataPaths for where to find the logs with the full error messages, which does include the first error (which in some cases is the reason for the others).
Still not sure if you fixed all errors, since that last post of yours does not tell.-
4
-
-
I didn't quote the manual that tells you what you'd have to do to run a task in the background without a reason. I also didn't tell you how I got to that information so you ignore it. I'll also not help avoid reading the documentation even if you PM me (also stop doing that to everyone instead of actually trying to read answers). And no, I don't have access to the lobby server anymore, and the script is unlikely to help you since that is a bog-standard init script that also doesn't hold your hand in any way.
TL;DR: Read the earlier reply, then read the manual, then read your system documentation.-
1
-
-
As always posting full error messages (starting from and including the first one) does help.
Same for the related files.-
3
-
Save own multiplayer/lobby password in OS' keyrings
in Game Development & Technical Discussion
Posted
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.