opencaching.com

Team BMW-Biker · Joined: 01 Oct 2003 Posts: 209

Hello everybody,

we should talk about security ...
How much security is needed ? Does we have to protect us against blackhats using sniffers and stuff like this ? I think yes - but how much ?!

The gratest problem is: Our project will be open-source ... and security in an open-source project is difficult - you can for example make no "hardcoded" passwords ... or calculate checksums from anything like the IP-Address to authentificate ...

I would say we need 3 sorts of security:

Sort 1: replication-security

Sort 2: DB-security - only a dataengine should have the rights to write to the database and to read password-hashes, email-addresses and such things - normal applications could have direct read access to tables like caches without using the dataengine (so performance will be better) - password used by the dataengine must be secret !

Sort 3: "normal" user authentification

Has anybody any (maybe other) idea ?

Thanks for discuse ...

... Oli

hmarq · Site Admin Joined: 15 Sep 2003 Posts: 351

I think we collectively are committed to having an open data model ... I think we're further committed to having collaborative development for code that supports the network ...

Open sourcing the web site code for each node would be security suicide and i'd argue against it.

That doesn't preclude publishing a snapshot of the code or the libraries at some point (and doing so under gpl); but I have no expectation of geocaching.de or opencaching.de releasing their endpoint website and I don't expect that to be the case for any other endpoint endpoint either.

programmers do dumb things from time to time (myself included) and having the development branch in particular would just be silly.

Further each node might use a different data back back end at the local level ... so there will definitely be variation in all the code bases.

If we adopt a standard DTD for exchange, use nntp (which is an open server) for replication and publish the spec for updates/retreive therefrom the data and the network are *completely* open without exposing each endpoint.

Team BMW-Biker · Joined: 01 Oct 2003 Posts: 209

hmarq · Site Admin Joined: 15 Sep 2003 Posts: 351

My appologies, I misunderstood you.

Interesting topic. I never really considered whether to syndicate the *user* table for each endpoint as that does raise a lot of ugly questions with respect to privacy.

I ask rhetorically, "Do we need to syndicate the entire user table?" ... I don't think most would want to have email address and password (even encrypted or hashed) distributed. ... the rest of the info wouldn't be an issue I'd think.

I don't know what real benefit you get by syndicating it? ... ubuquitous login?

It's a conversation worth having certainly.

Team BMW-Biker · Joined: 01 Oct 2003 Posts: 209

Team BMW-Biker · Joined: 01 Oct 2003 Posts: 209

ok ... i should read the complete thread Rolling Eyes

raven · Joined: 29 Sep 2003 Posts: 84 Location: Bielefeld, Germany

hmm, i really think the login/pass should work on ALL nodes. what if "my" node goes down and i wan't to edit my cache-descriptions? all my caches would be "owner-less" if my userinfo would have been saved only on one node.
so the user-data should definitely be synch'ed between the "core-nodes", but it should of couse not be given out to anyone else, using our http/xml-syndication-interface or anything like that.
if we save the passwords crypted (which we should, of course, do. md5 will probably be fine for that), there wouldn't even be a really big problem if somehow the user-data leaked out, because you can't get the plaintext pass from the crypted one. we should, of course, still do everything to prevent a situation like that from happening...
_________________
Quoth the raven, "Nevermore"

nici- · Posted: Sat Oct 04, 2003 12:35 pm Post subject:

Vinnie · Joined: 23 Sep 2003 Posts: 71 Location: Cologne, Germany

Team BMW-Biker · Joined: 01 Oct 2003 Posts: 209

raven · Joined: 29 Sep 2003 Posts: 84 Location: Bielefeld, Germany

ok, here's a suggestion on replication security (if the replication works the way it's described on ollis site and/or in my post in the nntp thread):
the node sends the "item-changed" message to his peers as usual, they request the modified datasets since their last replication (or the "modification-time" the first node sent them) and now my idea plugs in:
every core-node has it's own GPG key-pair and every node knows the public keys of all their peers. so instead of sending the changed datasets directly, it first writes their data to a textfile and then signs (only signs, not encrypts) this file using it's own secret key. this file is then returned to the requesting peer, who in turn checks if the signature is valid and only imports the changed datasets into his own database, if it is.

advantages:
it effectively protects us from fake data entering the network and ensures that only peers that are known to be secure can update data in the network. if a node that was trusted becomes known to generate wrong or fake data you can simply exclude their public key from the list of valid keys.

disadvantage:
the core-nodes must have a way to install gpg/pgp on their sites.

oh, and of course the keys of new nodes must be exchanged in some relatively secure way...
_________________
Quoth the raven, "Nevermore"

Vinnie · Joined: 23 Sep 2003 Posts: 71 Location: Cologne, Germany

hmarq · Site Admin Joined: 15 Sep 2003 Posts: 351

OK, I'm going to go against the grain here ...

I think authenication should be local and should not be syndicated.

First the practical side -- who is really going to use more than one site? answer: probably no one unless there is a failure of that persons preferred site. Could some arrangement be made so that a non-recoverable, catostrophic node failure be made such that *a* new node could aquire and support a failed node ... I'd be for that, but I don't think we need, nor want to be passing login credentials around to anyone that asks for them. ...

Second, whether you use md5, SHA, crypt or something else to store the passwords, the passwords themselves will still be subject to brute force attacke if they are available. People pick bad passwords, it's human nature. What makes it worse is they use the same freakin' password for their web logons as they do for their ATM, brokerage accounts, pension plans and who knows what else .... I don't think I'd sign up for my own site here if I know the password is going to be given to anyone that asks for it .... and further, I don't want that kind of liability for having distributed someone elses password ....

I really believe a user must have a home node, be owned by that node and be authenticated at that node ... lets work out some protocol to make the user 'acquireable' if a node fails without passing the whole user record.

Same thing with email address ... you can't just give that to anyone that asks for it or we'll just be viewed as a validated mailing list for spammers ... again, not something I'd like to be associated with.

If you really want to have a single logon, you could add a 'site' field to userid and password at logon and work out an RPC for remote authentication ... but I think we've got some more basic things to worry about before we get there.

Finally, switching gears ... but answering the other topic in this thread .... no, logins are not over a secure connect ... just as they aren't on most non-financial sites ... your userid and password are sent in the clear unless the target is an https:// ... which most aren't ... this site and gc.com included.

raven · Joined: 29 Sep 2003 Posts: 84 Location: Bielefeld, Germany

sorry, hmarq, but i think you are confusing the "syndication" of the data to anyone (for small stats-sites, the users local "my geocaches" list etc.) and the synchronization between our core-sites. of course we don't want to give out passwords or email-adresses out to anyone, but the other core-nodes are not "anyone". and yes, we should be a bit picky about who actually becomes a core-node, because they get write-access to all out data anyway. so i think we can trust (and make sure we can) these few core-sites enough to share privacy-relevant data like password-hashes and email-adresses between them.

and yes, i would use two different core-node-frontends, if for example core node A offers a feature that the others don't and core node B offers another such feature, but not the same one like A. come on, that situatuion isn't so unlikely that we shouldn't be able to handle it?

i say, either we replicate all our data between the core-nodes, or no data at all. and of course i vote for the former...
_________________
Quoth the raven, "Nevermore"

Vinnie · Joined: 23 Sep 2003 Posts: 71 Location: Cologne, Germany