opencaching.com Geocaching by the community, for the community italian charms 87744    FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Talking about security Goto page Previous  1, 2, 3, 4          opencaching.com Forum Index -> Tech Stuff View previous topic :: View next topic   Author Message Vinnie Joined: 23 Sep 2003 Posts: 71 Location: Cologne, Germany Posted: Wed Oct 08, 2003 3:40 am    Post subject: marc wrote: neun.keruch kib.schoechaem gleuz.keisauch fluex.fliflob fis.juschaum GIMME THAT PERL FUNCTION!! Back to top amnesius Joined: 27 Sep 2003 Posts: 147 Location: ./earth/europe/* Posted: Wed Oct 08, 2003 3:52 am    Post subject: marc wrote: amnesius wrote: If you log in, you have to enter a node nr. or node name + username + password. The system validates your login against your home node. I'm sure users will not know what a home node is and dont know what to answer to this question. Another point is that if the home node is down, users cant login at all. Marc. Yes if the home node is down you can not login, thats correct. Well you create an account you can provide this information to the user. For e.g. Your Node Number is 102 Your Username is Amnesius Your Password is PaSSwOrD Its the same with my homebanking, they ask for branch office number, account number and password.. (Guess which bank it is ) And i this wont be too much informations for a user. You can let the user choose ( i know it hav been mentioned before ) if the user want to distribute the password or not. But if you add distributed password validation you have always the option to login at other nodes... -stefan _________________ ~Amnesius Back to top raven Joined: 29 Sep 2003 Posts: 84 Location: Bielefeld, Germany Posted: Wed Oct 08, 2003 5:31 am    Post subject: i think there was one very important thing said in this thread: Quote: We are talking about a geocaching site and not a bank accout, arent we? If a core node wants to modify users caches it can do this easily without any passwords. hmarq, remember, we are talking about one of OUR nodes trying to crack the password of one of OUR users. what would that be good for, they can modify the cache-data etc. anyway... and if we say clearly and in a big, bold, red font on the account creation page: "DON'T USE A PASSWORD THAT YOU ARE USING ANYWHERE ELSE" or at least, anywhere important, than i don't see a problem with that system. and/or the checkbox "i want my password to be shared on all opencaching-nodes" is also a good idea... _________________ Quoth the raven, "Nevermore" Back to top Vinnie Joined: 23 Sep 2003 Posts: 71 Location: Cologne, Germany Posted: Wed Oct 08, 2003 6:39 am    Post subject: raven wrote: i think there was one very important thing said in this thread: Quote: We are talking about a geocaching site and not a bank accout, arent we? If a core node wants to modify users caches it can do this easily without any passwords. hmarq, remember, we are talking about one of OUR nodes trying to crack the password of one of OUR users. what would that be good for, they can modify the cache-data etc. anyway... Everything very true, but hmarqs argument was: People use the same passwords as for their bank accounts, and this combination of stupid user and evil core site admin may be dangerous. Back to top Team BMW-Biker Joined: 01 Oct 2003 Posts: 209 Posted: Wed Oct 08, 2003 7:15 am    Post subject: hello, ok, here is my point of view: 1. password-hashes are replicated between core-nodes (not given out to anything else) this is because if one node will go down (like hdd-crash), passwords arent in digital nirvana and it would be easy to give its data another corenode. For brute-force attacks, the attacker must first get the hash and if he can get this, he could also modify what he wants directy. passwords are crypted while replication over any possibly insecure way (i.e. HTTP-XML) - if we do replication over ssh-rsync or NNTP (nntp with authentification ?) there is no need ... 2. replication-datas are signed with private-keys 3. informations are owned by one corenode (stored on every). only this corenode can change the informations but every corenode has a local copy for searches. 4. every corenode-backend implements the same basic-functions (changing, adding, deleting ... informations) so there wouldnt be any use of changing his home-corenode 5. if a corenode gets a replication-record of which he is the owner - from another corenode - it wont accept it ... so if one corenode is cracked - only informations of this corenode are compromised (and replicated to every system) ... (but then the cracker has all hashes and can take brute-force attacks against other corenode-users) 6. the backend connects the right corenode for this user (to change/add/delete ... informations) - so if you want to use any other corenode than your home-corenode, you can do this (you have not to know which is your home-corenode ... the system handles it) 7. emails are crypted with a privat key of the owner-corenode - no other corenode has this email uncrypted 7. if a backend implements special features like "my backend will remind you that you wants the search cache xyz today" ... this corenode can authentificate the user with his password-hash, ask him for his email (to send the remind) and store the needed informations on his local system 8. if one corenode goes down (i.e. hdd-crash), all private keys must be given to one other corenode and IP/URL from the new corenode must given out to the other corenodes ... and the users can use the new corenode (or any other) to change their informations ... So we have a good way of replication in our "not full trusted" network Any better ideas ? What do you miss in this idea ? To complex ? ... Oli Back to top amnesius Joined: 27 Sep 2003 Posts: 147 Location: ./earth/europe/* Posted: Wed Oct 08, 2003 8:31 am    Post subject: Team BMW-Biker wrote: 8. if one corenode goes down (i.e. hdd-crash), all private keys must be given to one other corenode and IP/URL from the new corenode must given out to the other corenodes ... and the users can use the new corenode (or any other) to change their informations ... Wow do you have a Hardware Cash forcast algorithm written in Perl, PHP or C++ may i buy a licence.. -Stefan _________________ ~Amnesius Back to top amnesius Joined: 27 Sep 2003 Posts: 147 Location: ./earth/europe/* Posted: Wed Oct 08, 2003 9:44 am    Post subject: Well for my feel we are drifting away from a discussion about the security level of a gaming server. Someone mentioned before that we talking about bank accounts. I can imagne that there are ppl not willing to distribute their passwords along the whole OC Network. But for this case the Password is not that important. All the Data you want to protect are stored on the nodes anyway. The node has full access to the data and they can be changed by the admins without knowing the particular password of a user. So what in detail do you guys assume as the threat? Someone logging caches under your name? Someone placing caches under your name? Someone modifying the logs of your Cache? Distributed authorisation is always based on a thrusted system. Otherwise we need to use centeralized authorisation as i darfted in a previous posting. Just my personal opinion.. Any other opinions? -Stefan _________________ ~Amnesius Back to top Team BMW-Biker Joined: 01 Oct 2003 Posts: 209 Posted: Wed Oct 08, 2003 1:38 pm    Post subject: Quote: All the Data you want to protect are stored on the nodes anyway. The node has full access to the data and they can be changed by the admins without knowing the particular password of a user. sure, admins are "trusted" people ! Its not about the admins what we (should) talk about, its about crackers, blackhats and the baddest are script-kids. In my opinion: If you want to make one system like this to be a good one without many problems (for which admins have to spend their freetime - and problems will come, if we get many users over the world), you must do it secure ! If only one corenode (and i think this wont be so hard to do for semiprofessionals - he could choose 1 of 10, 20 or how much corenodes ever ... he will find one with any unpatched service !) is cracked and you have no protection against such situations implemented - the time to repair the damages will take much more time as a secure implementation ! And if this goes public to many users ... you can forget about thinking to get new users. I also think a cache-service like navicache (and geocache) will prove our system very hard, before they only think about to join ... Quote: So what in detail do you guys assume as the threat? Someone logging caches under your name? Someone placing caches under your name? Someone modifying the logs of your Cache? all this and many more think about manipulating coordinates (only 100 meter - nobody could pay attention to this) and nobody will find your any more ... Quote: Distributed authorisation is always based on a thrusted system. Otherwise we need to use centeralized authorisation as i darfted in a previous posting. I dont want to talk about "implementing a secure banking-system for opencaching" ... or do you want to use TAN's for every transaction ? Should i make some drafts to implement it ? My written points are very basically and not very hard to implement. Quote: For e.g. Your Node Number is 102 Your Username is Amnesius Your Password is PaSSwOrD Node Number isnt needed - this can be stored on the corenodes ... on my online-banking-account i have only a username and a password (and of course transaction numbers). So if there comes more feedback, we can see how other users think about it ... for me is no security needed, on my email-account comes every day round 40 spam-mails - and if my account on opencaching isnt secure and someone changing my informations/loggs/caches, i will decide how to react on it - maybe give up my opencaching-account (and i realy dont want to do something like that - i'm posting here and spend my time for this project because i think its a huge step into better caching) ... Oli Back to top amnesius Joined: 27 Sep 2003 Posts: 147 Location: ./earth/europe/* Posted: Wed Oct 08, 2003 2:36 pm    Post subject: Team BMW-Biker wrote: think about manipulating coordinates (only 100 meter - nobody could pay attention to this) and nobody will find your any more ... well yes, but you can break into nearly any system using dictionary or brute force attacks. To prevent this you can easily implement a timelock function like: After 3 unsuccessfull logins you have to wait for 15 mins to try again. Quote: I dont want to talk about "implementing a secure banking-system for opencaching" ... or do you want to use TAN's for every transaction ? Should i make some drafts to implement it ? No thanks, i guess we wont implement this for any reason, arent we? For my opinion we need a working security concept to prevent dictionary or brute force attacks against the frontend and to prevent spoofing attacks against the replication sublayer. For the first point a timelock should be ok, mixed with a reasonable Passwort generation tool. For the 2nd point we can use something like seperatly distributed checksums or digital content signing. But before we think about the security system we should think about who has an interest to harm our data and how strong is this persons interest to do this, which means how many time/money is this person/group willing to spend on doing this.. Regards -Stefan _________________ ~Amnesius Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         opencaching.com Forum Index -> Tech Stuff All times are GMT - 5 Hours Goto page Previous  1, 2, 3, 4 Page 4 of 4   Jump to: Select a forum OpenCaching.com----------------General (The Catch All)Issues, decisions, answersLegal StuffTech StuffContentDesign WizardsCode MonkeysJust Say Hi Projects----------------Geo TagsHosting ScriptsGPX Standards Diskussionsforen----------------Opencaching.de Dutch Mirror----------------Opencaching.nl Opencaching The Organization----------------Let's Get Organized  Powered by phpBB 2.0.6 © 2001, 2002 phpBB Group