theartisan changed the topic of #rubygems-trust to: Current Status: drafting requirements. please leave comments on :: Logs at
postmodern has joined #rubygems-trust
<postmodern> so gem signing aside
<postmodern> why can't have a separate server that only records checksums of gems?
<postmodern> and use that checksum database to verify the gems from S3 or on mirrors
<tarcieri> seems good bro
<tarcieri> I think raggi has talked about that approach quite a bit
<tarcieri> was talking to the head of Square's security team
<tarcieri> he suggested the same thing
<postmodern> i have a chat log i think of two users brainstorming it
<postmodern> z and wglynn
<tarcieri> cool
<postmodern> they did some off-the-cuff threat modeling
<postmodern> and i interjected some stupid comments
<postmodern> supposedly one of them wrote up a sinatra app that did the checksuming
<tarcieri> nice
<postmodern> i cant remember there twitter/github handles though
<postmodern> i swear z works at github now as a sysadmin
<tarcieri> github is not on my list of companies I'd trust about this shit ;)
<tarcieri> ^^^ o_O
<tarcieri> it's got a pretty UI, kind of
<tarcieri> that's about all I can say for it
<tarcieri> looks like they tried to clone Passpack (itself somewhat questionable) without knowing how to shot crypto
<tarcieri> use RSA encryption (o_O) in the browser using keys generated in the browser? WHAT COULD GO WRONG
<drbrain> tarcieri: you know that browsers since Netscape 4 (maybe 3) can generate client-side keys, right?
<drbrain> of course, doing this in javascript is entirely different
<drbrain> I can't tell if they're using JS or not from the readme
<postmodern> im waiting to see more attacks against browser based crypto
<tarcieri> drbrain: they're doing all the crypto in JS
<drbrain> oh ☹
<tarcieri> drbrain: and GLHF generating client-side certs from JavaScript in a browser, I've looked into it several times
<tarcieri> WebCrypto will kind of sort of solve the problem and will probably ship a bunch of really shitty algorithms that are vulnerable to the same things that the existing JS stuff is already vulnerable to (e.g. IND-CCA2 insecurities in PKCS#1v1.5 encryption)
<tarcieri> public key encryption algorithms should really be considered radioactive materials which shouldn't be touched by mere mortals ;)
<tarcieri> NaCl wraps its public key crypto up into crypto_box which actually uses xsalsa20 for encryption
<tarcieri> (xsalsa20 is a symmetric stream cipher)
<raggi> postmodern: you don't need to do checksumming
<raggi> postmodern: just make a HEAD request against s3 for each .gem file
<raggi> postmodern: and then put that in a db
<postmodern> raggi, ah even better
<raggi> easy peasy
<raggi> but yeah, we're going to have a mirror that does this every day
<raggi> i'm implementing a new index format first, as this will specifically not be written in ruby
<raggi> (and the current index format needs a refresh anyway)
<postmodern> raggi, although S3 only gives you md5 sums
<raggi> postmodern: OH NO!
<postmodern> raggi, also weird ones if you do multi-part uploads
<raggi> postmodern: (this isnt' a problem for a basic canaray system)
<postmodern> raggi, yeah the odds of someone using an md5 collision are low
<postmodern> esp getting an md5 collision to also be a valid tar archive
<raggi> well, they have to actually do more than find a collision
<raggi> right
<raggi> with valid gzip inside
<raggi> i mean, you could pad it out and so on
<raggi> but that's a crapton of work
<raggi> you're better off with many many other vectors at that level of investment
<postmodern> totally
<raggi> postmodern: we have versions on the s3 buckets now too, afaik
<raggi> so that helps wiht this also
<postmodern> oh nice!
<raggi> <- straw man of new index format, there will be some changes based on evans feedback
<raggi> it's the general principle i'm heading for though
<kseifried> raggi, : sorry I been awol, XML done shit itself.
<dstufft> kseifried: heh I saw that
<kseifried> this reminds me of that star trek episode with tribbles
<kseifried> except it's CVEs eating xml
<kseifried> or something
<dstufft> lol
<kseifried> and the cves aren't really cute like tribbles
<kseifried> some days I wish I could take a flame thrower to all of this
<dstufft> burn it down and lets start over
<kseifried> no
<kseifried> burn it down and go live in the woods
<dstufft> that works too
<dstufft> I grew up in the woods, I'll have an advantage :}
<kseifried> I have a flame thrower. game point. ;)
<dstufft> D:
<tarcieri> people can totally collide MD5s
<tarcieri> with NSA-level supercomputers
<tarcieri> trololol
<tarcieri> lack of even SHA1 is :sadpanda: though
<tarcieri> SHA1 is "not recommended for new applications"
<drbrain> tarcieri: not even NSA level supercomputer for MD5
<tarcieri> heh
<tarcieri> yeah you could probably bust it out with the CloudCracker hardware
<drbrain> in 2008 a fake RapidSSL CA cert was created using PS3s
<tarcieri> yeah nice
<tarcieri> this is the kind of thing CloudCracker can haul balls at
<tarcieri> they would program the target MD5 directly into the circuitry of the FPGAs
<tarcieri> like they flash a specific circuit for whatever they're trying to crack
<tarcieri> hmm, they have an "MD5" option
<tarcieri> for MD5 passwords I guess
<tarcieri> because once upon a time people actually thought that was a good idea o_O
<tarcieri> christ, I remember my friends using John the Ripper to crack our local ISP's shadow file when some incompetent admin left an insecure .swp file around of it
<tarcieri> oops
<tarcieri> ^^^ lol
<kseifried> md5 can be owned by ~140 sony playstations 3's
<kseifried> the cell processors are quite handy for this
<kseifried> and anyways if you're using SHA anything for password storage you're doing it wrong. sigh
<dstufft> kseifried: I use a sha something for password storage… PBKDF2 w/ sha ;)
<kseifried> that's not so terrible
<dstufft> Forget which sha
<raggi> kseifried: no worries, i had some stuff come up too, i'm waiting for the tuf guys to get back anyway to have a discussion with them
<dstufft> 256 or 512 or some shit
<dstufft> but I was mostly being snarky ;P
<raggi> kseifried: also started work on the new index today, which will go somewhat hand in hand with this stuff
<kseifried> nice
workmad3 has joined #rubygems-trust
workmad3 has quit [Ping timeout: 252 seconds]
* tarcieri is on the password hashing competition judges panel
<tarcieri> woo
<theartisan> passwords should be stored in plain text, how else can we email them to the user when they forget? :)
<tarcieri> you could encrypt them using rot13
<dstufft> rot13 is insecure, you need atleast double rot13
<tarcieri> seems good
<theartisan> someone needs to seriously solve the UX vs security trade off problem
<theartisan> as in not make it a trade off
<dstufft> step 1, make a UX person care about security
<dstufft> :/
<theartisan> dstufft: thats not the problem
<theartisan> not having your password database pwnd and customers losing trust in the company is a UX issue too
<dstufft> sounds like a PR problem
<theartisan> its not a very nice experience for the user ;p
<theartisan> the problem is every step you put in to secure a users account annoys them
<theartisan> i have yet to see anyone do 2 factor auth in a non annoying way too, yubikey seem to be the best ive found, but still a bit jarring as a user.
<dstufft> I've been looking at Duo Security
<theartisan> i want to login to a site, crap wheres my keys...
<dstufft> They have a neat thing where they'll push a notification to an smart phone app so all you gotta do is hit accept
<dstufft> (plus other methods ofc)
postmodern has quit [Quit: Leaving]
<theartisan> slightly better than i need to log into a site, crap wheres my phone, ok now i got to type this number in, darn time ran out…. try again...
<dstufft> I haven't *actually* used them yet
<dstufft> but they look nice anyways
<theartisan> the other fun thing about 2-factor auth is it relies too much on a single device, and one that is high on the hit list for thieves, so i now have a file that contains all the codes that can switch off the 2-factor auth and let me configure a new device, if someone can get that and unencrypt it, then the whole exercise was pointless
<dstufft> theartisan: eh I dunno, *crap wheres my phone*, my phone is basically the only thing I can actually keep track of
<theartisan> and i wonder how many people have those codes just written down
<theartisan> dstufft: i have too much crap in my pockets
<dstufft> heh
<dstufft> my phone and my wallet is the only thing I carry :/
<dstufft> well and my keys
<dstufft> I can't function w/o my phone :/
<dstufft> I think someones phone makes more sense then a hardware token, I have other reasons to keep track of my phone, the only reason I'd have a hardware token is to log into things
<dstufft> I mean the whole point of 2 factor auth is that you can lose one of the factors and not have your account compromised
<dstufft> s/lose/have stolen/
billdingo-afk is now known as billdingo
<theartisan> dstufft: thats why they generally have keyring holes on them, i have another reason to not lose my keys :)
<dstufft> heh fair enough
<theartisan> and a random thug is less likely to demand i hand over my keys
<dstufft> Though I do plug my phone into my computer and my keys are by the door. But that's not an entirely unsolvable problem ;)
<theartisan> dstufft: the problem is the recovery from failure
<theartisan> so my phones stolen, how do i recover access to my accounts?
<theartisan> normally that involves a password to disable 2-factor auth
<theartisan> or authy which lets you install their app on any number of devices, which feels like it breaks things a little
<dstufft> Duo has some nice stuff for that, You can store tokens separately that let you log in (this doesn't disable it, they are just normal tokens that you can use to log in once at anytime), or contact the admin for a bypass token (the admin can also remove your phone)
<dstufft> They also let you use landlines and such
<theartisan> google do the one off passwords thing
<dstufft> so if I associated my landline with my account, and I lost my cell phone I could just have Duo call my landline and do a voice verification
<theartisan> but thats in its self a bit fail, as its taking the security 2 factor brings, and then adding a recovery method thats as insecure as password auth.
<dstufft> well yes and no. If you write it down and store it then it's still a second factor
<dstufft> something you know (your actual password), something you have (the OTP you wrote down)
<theartisan> duo looks intresting
<dstufft> I havne't actualy used them yet, but I want to
<dstufft> they look like they have a pretty nice system
<dstufft> I like the mobile push thing
<dstufft> (They let you use hardware tokens too fwiw)
* theartisan has recently been trying to work out how to make use of his yubi key to secure his ssh keys
<dstufft> heh
<dstufft> They supposidly have some drop in unix thing for SSH
* dstufft sounds like an advertisement
<theartisan> they have a PAM module, which i have on some boxes
<theartisan> you log in, then need to send yubikey otp
<theartisan> theres also a google authenticator pam module
<theartisan> my problem is more, i have keys for bitbucket, github, etc
raz has quit [Ping timeout: 248 seconds]
workmad3 has joined #rubygems-trust
raz has joined #rubygems-trust
workmad3 has quit [Ping timeout: 256 seconds]
workmad3 has joined #rubygems-trust
cschneid has quit [Ping timeout: 264 seconds]
qmx|away is now known as qmx
qmx is now known as qmx|away
yorickpeterse is now known as yorick-cowboty
yorick-cowboty is now known as yorick-cowboy
_whitelogger has joined #rubygems-trust
davidbalber|away is now known as davidbalbert
davidbalbert is now known as davidbalber|away
davidbalber|away is now known as davidbalbert
_whitelogger has joined #rubygems-trust
yorick-cowboy is now known as yorickpeterse
sferik has joined #rubygems-trust
cschneid has joined #rubygems-trust
billdingo is now known as billdingo-afk
_whitelogger has joined #rubygems-trust
workmad3 has quit [Ping timeout: 264 seconds]
theartisan has quit [Ping timeout: 256 seconds]
theartisan has joined #rubygems-trust
davidbalbert is now known as davidbalber|away
davidbalber|away is now known as davidbalbert
havenwood has joined #rubygems-trust
davidbalbert is now known as davidbalber|away
davidbalber|away is now known as davidbalbert
billdingo-afk is now known as billdingo
havenwood has quit [Remote host closed the connection]
qmx|away has quit [Excess Flood]
qmx has joined #rubygems-trust
<raggi> theartisan: why have so many keys?
<raggi> theartisan: i jsut carry my known hosts files with my fewer keys, and hosts files divide up by key (and other factors), and if one gets breached, i have a list of places to replace it immediately. i also carry the keys in AES instead of DES as it defaults too
<raggi> theartisan: otp keys arent' useful for otps (one time password - one time pad), as the latter doesn't change. you could at best unlock a time verified vault service to unlock the real pad key (passphrase), but that seems complicated. a one time pad is VERY strong provided you use a good key.
<raggi> at that point, the service is a weaker target than the one time pad would be
<raggi> ssh keys are already two factor, if they're encryped
<raggi> and its' questionable whether adding another factor fo the same class (something you have) adds very much
<raggi> you'd be better off adding "something you are"
<raggi> i personally am not a fan of biometrics, as while they are less prone to being lost or forgotten, they're also subject to the single breach problem - once someone succesfully dupes your fingerprint, what do you do? scar you fingers? seems bad.
<namelessjon> otp at least has the advantage it's probably a on a different device (phone), vs your keys which live on your laptop (probably). But it seems like a marginal gain over keys.
davidbalbert is now known as davidbalber|away
<dstufft> raggi: I randommize my fingerprints with acid once a year
<dstufft> you know, for security
<drbrain> dstufft: you could probably just go with some 500 grit before committing any major crimes
<dstufft> :D
<drbrain> too rough and you leave DNA everywhere
<dstufft> I tried that once when I was like 12, it hurts a lot
<drbrain> I gave myself blisters from sanding due to the heat alone
<drbrain> orbital sanders don't do so well in corners
<dstufft> I saw Men in Black and thought it was a good idea to leave no traces
<dstufft> so I tried to DIY
* dstufft wasn't a particularly smart kid
<drbrain> we had curtains with the pull string
havenwood has joined #rubygems-trust
<drbrain> I tried to "slide down the rope" when I was eight or so an burned my hand
<drbrain> curtains were fine
<dstufft> lol
<raggi> namelessjon: sure, put your keys on a usb stick..
<raggi> namelessjon: or, on a yubi, iirc they have a teeny bit of space
<namelessjon> raggi: I'm more (relative term) worried about some system compromise stealing keys, than anything else. Since times system is on and times keys would needed are relatively the same times. As I said, it seems marginal over the benefit of just using keys.
<namelessjon> (with appropriate passphrases)
<raggi> namelessjon: well, load it up into the agent and auth right away, then detatch the key
<raggi> namelessjon: you could also write a more secure agent, and if you wanted to take it even further, add a kernel module that is dedicated to assist in spotting any page violations into the agents memory
<raggi> nothing is going to be perfect here though
<raggi> putting a key on a hosed system should be considered nailed
<namelessjon> Yeah, I know its not perfect. I'm not saying an otp generator would be either. Just noting it has some advantages over just a passworded ssh key. Drawbacks too.
<namelessjon> (I just use passworded ssh keys, personally)
<namelessjon> Though speaking of ways to store keys, did you see
sferik has quit [Quit: Computer has gone to sleep.]
davidbalber|away is now known as davidbalbert
<raggi> so yubi have hsm's as well, but the yubikey is not an hsm
<raggi> not in the "embedded cryptokey" sense
qmx is now known as qmx|away