On Monday 22 Jul 2013 11:40:32 Matthew Toseland wrote: > On Sunday 21 Jul 2013 23:20:40 Robert Hailey wrote: > > > > I'm not 100% sure how this might work, but having opennet require a > > security device might be publicly acceptable, and might also serve as the > > monetary disincentive to an opennet sybil attack. > > > > Without looking too much into it, I supporting a smartcard interface from > > java (across many platforms) would be problematic. A one-time-password > > (OTP) solution might work, though. > > > > One such device I have experience with: > > http://www.yubico.com/products/yubikey-hardware/yubikey/ > > > > Such an onboarding user story might look like this: > > (1) a new user browses the freenet site and finds out that freenet > > generally requires a yubikey > > (2) they install freenet, but it doesn't work (or works poorly), and also > > says something about needing a yubikey > > (3) we lose a bunch of lookie-loos with an interest in freenet that is > > <$15+time, but security-interested folks might be further interested in > > getting "the security device that freenet requires" anyway > > (4) so those that remain order a yubikey (min quantity 1), > > (5) a few days later, the device arrives (quick-ish, as singletons are > > mailed in an envelope) > > (6) they go back to freenet, click in the "yubikey field" and mash the > > "button" (it's actually a capacitance sensor, I think) > > (7) through some mechanism not visible to the user, the OTP is verified and > > an opennet certificate is issued > > > > Maybe at some semi-obvious state change (like a machine reboot, or the > > yubikey being used on another N machines?) or period (monthly), the field > > would popup again to make it seem important & remind the user that a > > yubikey is needed to spread freenet. > > > > The generated OTP has a prefix that uniquely identifies it (sorta like a > > serial number), and can only be verified *once* (it is then, by definition, > > stale). > > > > If we use the default "short-press" identity that comes with the key, then > > we would be implicitly trusting YubiCo to not hand out gobs of identities > > to an attacker (i.e. without paying). In fact, that's the only option > > really... we could not use a custom identity, b/c either we would have to > > supply/program the keys or we'd be right back to a sybil attack (they just > > put the OTP algo in software). > > > > The implementation of step #7 really depends on wether or not we trust our > > seed nodes, and wether or not making a conventional http/https connection > > is acceptable. NB: we could always bundle a public key in with freenet to > > make it "safe" to hand off an encrypted OTP for delivery back to the > > mothership... I mean, "central server". > > > So this is just a cheat to prevent users from realising that we're charging > them to join Freenet? Dishonest, and dubious. Unless there is a really good > reason why we need two factor authentication? > > And technically, it can't be just any YubiKey - we need to sign the > certificate. > Okay so the idea is: 1. Marketing: the user has something they can keep and use for other things. 2. Uniqueness/cost guaranteed by the manufacturer: We can use an online service to establish that it's a genuine, unique yubikey, different to the yubikey's that have announced before. Then we generate a bootstrapping cert. If they take said service offline, no big deal, because we only use it once, on creation.
Maybe this is a possibility. We'd need a bitcoin option as well though.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
