Re: Automatic attack alert to ISPs
Argus can alert prefix hijacking, in realtime. http://tli.tl/argus Hope to be useful to you. BR. 在 2012年6月22日星期五，Ganbold Tsagaankhuu 写道： > Hi, > > Is there any well known free services or scripts that sends automatic > attack alerts based on some logs to corresponding ISPs (based on src > address)? > I have seen dshield.org and mynetwatchman, but I don't know yet how > good they are. > If somebody has recommendations in this regard please let me know. > > thanks in advance, > > Ganbold > > -- _ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
Re: Automatic attack alert to ISPs
There are ISP feedback loops You might also try signing up at http://atlas.arbor.net - see if you can get a sensor deployed in your network. http://atlas.arbor.net/faq/#sensor On Fri, Jun 22, 2012 at 11:21 AM, Ganbold Tsagaankhuu wrote: > > Is there any well known free services or scripts that sends automatic > attack alerts based on some logs to corresponding ISPs (based on src > address)? > I have seen dshield.org and mynetwatchman, but I don't know yet how > good they are. > If somebody has recommendations in this regard please let me know. -- Suresh Ramasubramanian (ops.li...@gmail.com)
Automatic attack alert to ISPs
Hi, Is there any well known free services or scripts that sends automatic attack alerts based on some logs to corresponding ISPs (based on src address)? I have seen dshield.org and mynetwatchman, but I don't know yet how good they are. If somebody has recommendations in this regard please let me know. thanks in advance, Ganbold
Re: How to fix authentication (was LinkedIn)
On Thu, Jun 21, 2012 at 10:48 PM, Randy Bush wrote: >> That's basically the Yubikey. It uses a shared key, but since you're >> relying on a trusted third party anyway > > there are no trustable third parties note that yubico has models of auth that include: 1) using a third party 2) making your own party 3) HOTP on token 4) NFC they are a good company, trying to do the right thing(s)... They also don't necessarily want you to be stuck in the 'get your answer from another' -chris
Re: How to fix authentication (was LinkedIn)
> That's basically the Yubikey. It uses a shared key, but since you're > relying on a trusted third party anyway there are no trustable third parties randy
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
valdis.kletni...@vt.edu wrote: >> Unlike IPv4 with natural boundary of /24, routing table >> explosion of IPv6 is a serious scalability problem. > > Do you have any *realistic* and *actual* reason to suspect that the IPv6 > routing table will "explode" any further than the IPv4 has already? That's not the point. The problem is that SRAMs scale well but CAMs do not. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Owen DeLong wrote: >> It is the first step to have the RSIP style transparent Internet. >> >> The second step is to use port numbers for routing within ISPs. >> But, it is not necessary today. >> > Still doesn't scale. 40 bits isn't enough to uniquely identify a > conversation end-point. It's 48 bit. > If you use port numbers for routing, > you don't have enough port numbers for conversation IDs. That you use IPv4 addresses for routing does not make it unusable for identifications. Moreover, it is easy to have a transport protocol with 32bit or 48bit port numbers with the end to end fashion only by modifying end part of the Internet. >> Unlike IPv4 with natural boundary of /24, routing table >> explosion of IPv6 is a serious scalability problem. > Solvable. It was solvable. > IPv6 has enough bits that we can use map/encap or > other various forms of herarchical overlay ASN-based routing > to resolve those issues over time. The reality is that situation has been worsening over time. As RFC2374 was obsoleted long ago, it is now impossible to restore it. Masataka Ohta
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 21, 2012, at 5:36 PM, valdis.kletni...@vt.edu wrote: > On Fri, 22 Jun 2012 08:40:02 +0900, Masataka Ohta said: >> Owen DeLong wrote: > >>> What if my ISP just routes my /48? Seems to work quite well, >>> actually. >> >> Unlike IPv4 with natural boundary of /24, routing table >> explosion of IPv6 is a serious scalability problem. > > Do you have any *realistic* and *actual* reason to suspect that the IPv6 > routing table will "explode" any further than the IPv4 has already? Hint - > Owen's /48 will just get aggregated and announced just like the cable > companies > *already* aggregate all those /20s of customer /32s. Unless Owen multihomes - > at > which point he's a new entry in the v6 routing tables - but *also* almost > certainly a new entry in the v4 routing table. Routing table size depends on > the number of AS's, not the amount of address space the routes cover. > > Um, unlikely. My /48 is an ARIN direct assignment: 2620:0:930::/48 It's not really aggregable with their other customers. I do multihome and I am one entry in the v6 routing tables. However, I'm actually two entries in the v4 routing table. 192.159.10.0/24 and 192.124.40.0/23. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Fri, 22 Jun 2012 08:40:02 +0900, Masataka Ohta said: > Owen DeLong wrote: > > What if my ISP just routes my /48? Seems to work quite well, > > actually. > > Unlike IPv4 with natural boundary of /24, routing table > explosion of IPv6 is a serious scalability problem. Do you have any *realistic* and *actual* reason to suspect that the IPv6 routing table will "explode" any further than the IPv4 has already? Hint - Owen's /48 will just get aggregated and announced just like the cable companies *already* aggregate all those /20s of customer /32s. Unless Owen multihomes - at which point he's a new entry in the v6 routing tables - but *also* almost certainly a new entry in the v4 routing table. Routing table size depends on the number of AS's, not the amount of address space the routes cover. pgpBjpETVNgvj.pgp Description: PGP signature
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 21, 2012, at 4:40 PM, Masataka Ohta wrote: > Owen DeLong wrote: > >> Does not scale. Not enough IPv4 addresses to do that for 6.8 >> billion people on the planet. > > It is the first step to have the RSIP style transparent Internet. > > The second step is to use port numbers for routing within ISPs. > But, it is not necessary today. > Still doesn't scale. 40 bits isn't enough to uniquely identify a conversation end-point. If you use port numbers for routing, you don't have enough port numbers for conversation IDs. >> What if my ISP just routes my /48? Seems to work quite well, >> actually. > > Unlike IPv4 with natural boundary of /24, routing table > explosion of IPv6 is a serious scalability problem. > Solvable. IPv6 has enough bits that we can use map/encap or other various forms of herarchical overlay ASN-based routing to resolve those issues over time. Owen
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Owen DeLong wrote: > Does not scale. Not enough IPv4 addresses to do that for 6.8 > billion people on the planet. It is the first step to have the RSIP style transparent Internet. The second step is to use port numbers for routing within ISPs. But, it is not necessary today. > What if my ISP just routes my /48? Seems to work quite well, > actually. Unlike IPv4 with natural boundary of /24, routing table explosion of IPv6 is a serious scalability problem. Masataka Ohta
Re: LinkedIn password database compromised
On Thu, Jun 21, 2012 at 08:33:47AM +0900, Randy Bush wrote: > would be interested to hear smb on this. +1. I've been reading and thinking about: http://www.ietf.org/id/draft-bellovin-hpw-01.txt for quite some time, and I recommend that others interested in this topic do the same. ---rsk
Re: LinkedIn password database compromised
- Original Message - > From: "Tei" > If anyone have a really good idea how to fix this mess, It will be a > good idea to contact with Jeff Atwood (of codehorror.com and > stackoverflow.com fame). He and other people is working on a new > internet approach to discussions. Think forums 2.0. If this new pet > rock succeed, could change how the world use, eerrh... forums. We > could hit two problems with the same rock. Those who do not understand Usenet are condemned to reinvent it. Poorly. -- after henry@utzoo Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: How to fix authentication (was LinkedIn)
On Jun 21, 2012, at 12:15 PM, AP NANOG wrote: > What if, and I am brainstorming here, what if there was a hardware device > which plugged in via USB. It was programed (i.e verified) in person, such as > a key signing party. The serial number of the hardware device was all that > is stored in the "verified" database with say a generic email created at that > time with the domain of the verifying group. For example, your serial number > is 12345, so the email would be generated as 12...@foo.com. This device is > hardware encrypted, and stores your password (priv key) in a one way > encryption. Then when you go to a website they can ask if you are verified > by foo.com. The users selects yes, then the website pulls the public key at > that time. Then asks you for your pin, password, pass-phrase, whatever, and > at that time the users clicks a pretty eye candy button in the browser which > looks for the USB device with the serial number from the database. Once > found it then starts a secure tunnel such as VPN (can be anything just using > it as a methodology), and no data is transmitted until the tunnel and DNSSEC > has been established. Once established you can surf the site as normal. All > these connections and tunnels being setup by the browser using two factor > authentication. What you know being the public key with verification from > foo.com, which was also verified in person with the foo.com email. What you > have which is the hardware token, again serial number verified and encrypted. > Combined to give you access and the browser does most the work. That's basically the Yubikey. It uses a shared key, but since you're relying on a trusted third party anyway it's fine if they keep the key. When a Yubikey is manufactured the factory default key is stored in Yubico's public auth service database along with the serial number. Anyone on the internet can then ask the service "was this OTP in fact generated by serial number X?" If you don't trust Yubico's service you can program your own key into it and run your own verification service. The mechanics are different but I think the trust model is the same -- users get USB tokens identified only by serial number, and a third party service vouches that a signature/OTP was generated by a particular serial number. -Ben
Re: LinkedIn password database compromised
On Thu, Jun 21, 2012 at 12:56 PM, Rich Kulawiec wrote: > On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote: > > (on the use of public/private keys) > >> The leaks stop immediately. There's almost no value in a database of >> public keys, heck if you want one go download a PGP keyring now. > > It's a nice thought, but it won't work. There are two large-scale > security problems which prevent it from working: > > 1. Fully-compromised/hijacked/botted/zombied systems. Pick your term, > but any estimate of this population under 100M should be laughed out > of the room. Plausible estimates are now in the 200M to 300M range. > Any private key present on any of those is accessible to The Bad Guys > whenever they can trouble themselves to grab it. (Just as they're > already, quite obviously, grabbing passwords en masse.) > > 2. Pre-compromised-at-the-factory smartphones and similar. There's > no reason why these can't be preloaded with spyware similar to CarrierIQ > and directed to upload all newly-created private keys to a central > collection point. This can be done, therefore it will be done, and when > some security researcher discovers it, the usual excuses and justifications > will be made by the designated spokesliars for the companies involved... > which will of course keep right on doing it, albeit perhaps with more > subterfuge. > > Problem #1 has been extant for ten years and no (meaningful) progress > whatsoever has been made on solving it. > > Problem #2 is newer, but I'm willing to bet that it will also last > at least a decade and that it will get worse, since there are > substantial economic incentives to make it so. In both cases, the evildoers may only gain access to a passphrase-protected private key. That doesn't help if the private key is generated on a compromised system, but it helps if the system is compromised after the private keys are generated, or if the private key is generated elsewhere and loaded onto the compromised system. And it doesn't help if the passphrase is easily guessed. Cheers, Dave Hart
Re: How to fix authentication (was LinkedIn)
I still believe that the final solution should be some sort of two factor, something you know (i.e. a passphrase) and something you have (i.e. key / token / something which has been verified). Up till recently RSA was a good platform, but was not very effective for smartphone use. If there is no two factor methodology, which changes, being deployed then man in the middle will still work. So will compromising systems and even compromised servers. What if, and I am brainstorming here, what if there was a hardware device which plugged in via USB. It was programed (i.e verified) in person, such as a key signing party. The serial number of the hardware device was all that is stored in the "verified" database with say a generic email created at that time with the domain of the verifying group. For example, your serial number is 12345, so the email would be generated as 12...@foo.com. This device is hardware encrypted, and stores your password (priv key) in a one way encryption. Then when you go to a website they can ask if you are verified by foo.com. The users selects yes, then the website pulls the public key at that time. Then asks you for your pin, password, pass-phrase, whatever, and at that time the users clicks a pretty eye candy button in the browser which looks for the USB device with the serial number from the database. Once found it then starts a secure tunnel such as VPN (can be anything just using it as a methodology), and no data is transmitted until the tunnel and DNSSEC has been established. Once established you can surf the site as normal. All these connections and tunnels being setup by the browser using two factor authentication. What you know being the public key with verification from foo.com, which was also verified in person with the foo.com email. What you have which is the hardware token, again serial number verified and encrypted. Combined to give you access and the browser does most the work. Couple things I see as issues off the bat are: Cost of USB device Security controls over manufacturing In person verification, will require many locations and volunteers - Still involves the Human Factor of error or misuse Education of the users who are techie Browser security Browser plugin & functionality Change time limit and process (i.e. must be regenerated after x months) Complete Revocation of the token and notification to all websites using foo.com verification Again I am just throwing an idea out there to see what others think, maybe pieces of everyone's idea may result in an effective solution :-) Along the lines of iCloud, or any cloud based service. I am by no means a fan of cloud services in any shape or form. The risks are WAY to great to out weigh the benefits. If someone has a good argument for "secure" cloud services I am open to hearing those, but that's an entirely different email thread :-) - Robert Miller (arch3angel) On 6/21/12 8:23 AM, Alexander Harrowell wrote: On Thursday 21 Jun 2012 04:16:22 Aaron C. de Bruyn wrote: On Wed, Jun 20, 2012 at 4:26 PM, Jay Ashworth wrote: - Original Message - From: "Leo Bicknell" Yes, but you're securing the account to the *client PC* there, not to the human being; making that Portable Enough for people who use and borrow multiple machines is nontrivial. Or a wizard in your browser/OS/whatever could prompt you to put in a 'special' USB key and write the identity data there, making it portable. Or like my ssh keys, I have one on my home computer, one on my work computer, one on my USB drive, etc... If I lose my USB key, I can revoke the SSH key and still have access from my home computer. And I'm sure someone would come up with the 'solution' where they store the keys for you, but only you have the passphrase...ala lastpass. -A As far as apps go, loads of them use OAuth and have a browser step in their setup. So this adds precisely one step to the smartphone sync/activation process - downloading the key pair from your PC (or if you don't have a PC, generating one). that covers vendor A and most vendor G devices. "what about the feature phones?" - not an issue, no apps to speak of, noOp(). "what about [person we want to be superior to who is always female for some reason]?" - well, they all seem to have iPhones now, so *somebody's* obviously handholding them through the activation procedure. obviously vendor A would be tempted to "sync this to iCloud"...but anyway, I repeat the call for a W3C password manager API. SSH would be better, but a lot of the intents, actions etc are the same.
Re: LinkedIn password database compromised
While I am not disagreeing with your statements, nor do I believe they will work. What I am doing is playing devils advocate. I am hoping to stir all of our gray matter for ideas, maybe something said here may end up being the fix. However, which thread do we want to continue this conversation in? "LinkedIn password database compromised" or "How to fix authentication (was LinkedIn)" :-) - Robert Miller (arch3angel) On 6/21/12 11:05 AM, Leo Bicknell wrote: I want to start by saing, there are lots of different security problems with accessing a "cloud service". Several folks have already brought up issues like compromised user machines or actually verifing identity. One of the problems in this space I think is that people keep looking for a silver bullet that magically solves all the problems. It doesn't exist. We need a series of technologies that work with each other. In a message written on Thu, Jun 21, 2012 at 10:43:44AM -0400, AP NANOG wrote: How will this prevent man in the middle attacks, either at the users location, the server location, or even on the compromised server itself where the attacker is just gathering data. This is the same concerns we face now. There is a sign up problem. You could sign up with a MTM web site, which then signs you up with the real web site. There are a number of solutions, you can try and prevent the MTM attack with something like DNSSEC, and/or verify the identity of the web site with something like X.509 certificates verified by a trusted party. The first relationship could exchange public keys in both directions, making the attack a sign-up attack only, once the relationship is established its public key in both directions and if done right impervious to a MTM attack. Note that plenty of corporations "hijack" HTTPS today, so MTM attacks are very real and work should be done in this space. Second is regarding the example just made with "bickn...@foo.com" and super...@foo.com. Does this not require the end user to have virtually endless number of email addresses if this method would be implemented across all authenticated websites, compounded by numerous devices (iPads, Smartphones, personal laptop, work laptop, etc..) Not at all. Web sites can make the same restrictions they make today. Many may accept my "bickn...@ufp.org" key and let me us that as my login. A site like gmail or hotmail may force me to use something like bickn...@gmail.com, because it actually is an e-mail, but it could also give me the option of using an identifier of my choice. While I think use of e-mails is good for confirmation purposes, a semi-anonymous web site that requires no verification could allow a signup with "bob" or other unqualified identifier. It's just another name space. The browser is going to cache a mapping from web site, or domain, to identifier, quite similar to what it does today... Today: www.facebook.com, login: bob, password: secret Tomorrow: www.facebook.com, key: bob, key-public: ..., key-private: ...
Re: LinkedIn password database compromised
I want to start by saing, there are lots of different security problems with accessing a "cloud service". Several folks have already brought up issues like compromised user machines or actually verifing identity. One of the problems in this space I think is that people keep looking for a silver bullet that magically solves all the problems. It doesn't exist. We need a series of technologies that work with each other. In a message written on Thu, Jun 21, 2012 at 10:43:44AM -0400, AP NANOG wrote: > How will this prevent man in the middle attacks, either at the users > location, the server location, or even on the compromised server itself > where the attacker is just gathering data. This is the same concerns we > face now. There is a sign up problem. You could sign up with a MTM web site, which then signs you up with the real web site. There are a number of solutions, you can try and prevent the MTM attack with something like DNSSEC, and/or verify the identity of the web site with something like X.509 certificates verified by a trusted party. The first relationship could exchange public keys in both directions, making the attack a sign-up attack only, once the relationship is established its public key in both directions and if done right impervious to a MTM attack. Note that plenty of corporations "hijack" HTTPS today, so MTM attacks are very real and work should be done in this space. > Second is regarding the example just made with "bickn...@foo.com" and > super...@foo.com. Does this not require the end user to have virtually > endless number of email addresses if this method would be implemented > across all authenticated websites, compounded by numerous devices > (iPads, Smartphones, personal laptop, work laptop, etc..) Not at all. Web sites can make the same restrictions they make today. Many may accept my "bickn...@ufp.org" key and let me us that as my login. A site like gmail or hotmail may force me to use something like bickn...@gmail.com, because it actually is an e-mail, but it could also give me the option of using an identifier of my choice. While I think use of e-mails is good for confirmation purposes, a semi-anonymous web site that requires no verification could allow a signup with "bob" or other unqualified identifier. It's just another name space. The browser is going to cache a mapping from web site, or domain, to identifier, quite similar to what it does today... Today: www.facebook.com, login: bob, password: secret Tomorrow: www.facebook.com, key: bob, key-public: ..., key-private: ... -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgph9Oiiinnwc.pgp Description: PGP signature
Re: LinkedIn password database compromised
If anyone have a really good idea how to fix this mess, It will be a good idea to contact with Jeff Atwood (of codehorror.com and stackoverflow.com fame). He and other people is working on a new internet approach to discussions. Think forums 2.0. If this new pet rock succeed, could change how the world use, eerrh... forums. We could hit two problems with the same rock. -- -- ℱin del ℳensaje.
Re: LinkedIn password database compromised
I have two concerns with this thought, while at the same time intrigued by it. How will this prevent man in the middle attacks, either at the users location, the server location, or even on the compromised server itself where the attacker is just gathering data. This is the same concerns we face now. Second is regarding the example just made with "bickn...@foo.com" and super...@foo.com. Does this not require the end user to have virtually endless number of email addresses if this method would be implemented across all authenticated websites, compounded by numerous devices (iPads, Smartphones, personal laptop, work laptop, etc..) Again I think this conversation is on the right track, but ultimately a form of two factor authentication method such as pub/priv, Wikid, etc.. is needed. On 6/20/12 6:28 PM, Leo Bicknell wrote: In a message written on Wed, Jun 20, 2012 at 03:05:17PM -0700, Aaron C. de Bruyn wrote: You're right. Multiple accounts is unpossible in every way except prompting for usernames and passwords in the way we do it now. The whole ssh-having-multiple-identities thing is a concept that could never be applied in the browser in any sort of user-friendly way. Aw come on guys, that's really not hard, and code is already in the browsers to do it. If you have SSL client certs and go to a web site which accepts multiple domains you get a prompt, "Would you like to use identity A or identity B." Power users could create more than one identity (just like more than one SSH key). Browsers could even generate them behind the scenes for the user "create new account at foo.com" tells the browser to generate "bickn...@foo.com" and submit it. If I want another a quick trip to the menu creates "super...@foo.com" and saves it. When I go to log back in the web site would say "send me your @foo.com" signed info. Seriously, not that hard to do and make seemless for the user; it's all UI work, and a very small amount of protocol (HTTP header probably) update. In a message written on Wed, Jun 20, 2012 at 02:54:10PM -0700, Matthew Kaufman wrote: Yes. Those users who have a single computer with a single browser. For anyone with a computer *and* a smartphone, however, there's a huge missing piece. And it gets exponentially worse as the number of devices multiplies. Yeah, and no one has that problem with a password. Ok, that was overly snarky. However people have the same issue with passwords today. iCloud to sync them. Dropbox and 1Password. GoodNet. Syncing certs is no worse than syncing passwords. None of you have hit on the actual down side. You can't (easily) log in from your friends computer, or a computer at the library due to lack of key material. I can think of at least four or five solutions, but that's the only "hard" problem here. This has always failed in the past because SSL certs have been tied to _Identity_ (show me your drivers license to get one). SSH keys are NOT, you create them at will, which is why they work. You could basically coopt SSL client certs to do this with nearly zero code provided people were willing to give up on the identity part of X.509, which is basically worthless anyway.
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Jun 21, 2012, at 5:04 AM, Masataka Ohta wrote: > Karl Auer wrote: > >> Speaking for myself, I'm one of the "if I want to allow direct outside >> connection to my interior machines I should be able to" crowd. > > While "direct" and "interior" are not compatible that you actually > mean some indirections... > > Anyway, what if, your ISP assigns a globally unique IPv4 address > to your home router (a NAT box) which is UPnP capable? > > That's what the largest retail ISP in Japan is doing. > > Masataka Ohta Does not scale. Not enough IPv4 addresses to do that for 6.8 billion people on the planet. What if my ISP just routes my /48? Seems to work quite well, actually. Owen
Re: LinkedIn password database compromised
Tei wrote: > Anonymity on the Internet is a feature, because a lot of the world > netcitizens come from countries where saying this or that is a crime, > and can get you in trouble. Note that you need to make a distinction between pseudonymity and anonymity. In most online situations anonymity is not useful, because you want a service to be able to identify you as the same person when you go away and come back later. You want the service to attach a pseudonym to you, and you want to be in control of whether this pseudonym is linked to your identities at other services or in the real world. Whether you authenticate your pseudonym with a password or a cryptographic key is immaterial, provided the key store supports unlinked identities - i.e. it must not require you to use the same key for everything. A good key store makes it easier to decouple your identities at different services than remembering N different username + password pairs. Tony. -- f.anthony.n.finchhttp://dotat.at/ North Portland, Plymouth: Cyclonic, becoming westerly 5 to 7, occasionally gale 8. Rough. Rain or showers. Good, occasionally poor.
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Thu, 2012-06-21 at 21:04 +0900, Masataka Ohta wrote: > Karl Auer wrote: > > Speaking for myself, I'm one of the "if I want to allow direct > > outside connection to my interior machines I should be able to" > > crowd. > > While "direct" and "interior" are not compatible that you actually > mean some indirections... I am a native English speaker, and I actually meant exactly what I actually wrote. I have found "direct" and "interior" to be completely compatible. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 signature.asc Description: This is a digitally signed message part
Re: LinkedIn password database compromised
On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote: (on the use of public/private keys) > The leaks stop immediately. There's almost no value in a database of > public keys, heck if you want one go download a PGP keyring now. It's a nice thought, but it won't work. There are two large-scale security problems which prevent it from working: 1. Fully-compromised/hijacked/botted/zombied systems. Pick your term, but any estimate of this population under 100M should be laughed out of the room. Plausible estimates are now in the 200M to 300M range. Any private key present on any of those is accessible to The Bad Guys whenever they can trouble themselves to grab it. (Just as they're already, quite obviously, grabbing passwords en masse.) 2. Pre-compromised-at-the-factory smartphones and similar. There's no reason why these can't be preloaded with spyware similar to CarrierIQ and directed to upload all newly-created private keys to a central collection point. This can be done, therefore it will be done, and when some security researcher discovers it, the usual excuses and justifications will be made by the designated spokesliars for the companies involved... which will of course keep right on doing it, albeit perhaps with more subterfuge. Problem #1 has been extant for ten years and no (meaningful) progress whatsoever has been made on solving it. Problem #2 is newer, but I'm willing to bet that it will also last at least a decade and that it will get worse, since there are substantial economic incentives to make it so. ---rsk
Re: How to fix authentication (was LinkedIn)
On Thursday 21 Jun 2012 04:16:22 Aaron C. de Bruyn wrote: > On Wed, Jun 20, 2012 at 4:26 PM, Jay Ashworth wrote: > > - Original Message - > >> From: "Leo Bicknell" > > Yes, but you're securing the account to the *client PC* there, not to > > the human being; making that Portable Enough for people who use and > > borrow multiple machines is nontrivial. > > Or a wizard in your browser/OS/whatever could prompt you to put in a > 'special' USB key and write the identity data there, making it > portable. Or like my ssh keys, I have one on my home computer, one on > my work computer, one on my USB drive, etc... If I lose my USB key, I > can revoke the SSH key and still have access from my home computer. > > And I'm sure someone would come up with the 'solution' where they > store the keys for you, but only you have the passphrase...ala > lastpass. > > -A As far as apps go, loads of them use OAuth and have a browser step in their setup. So this adds precisely one step to the smartphone sync/activation process - downloading the key pair from your PC (or if you don't have a PC, generating one). that covers vendor A and most vendor G devices. "what about the feature phones?" - not an issue, no apps to speak of, noOp(). "what about [person we want to be superior to who is always female for some reason]?" - well, they all seem to have iPhones now, so *somebody's* obviously handholding them through the activation procedure. obviously vendor A would be tempted to "sync this to iCloud"...but anyway, I repeat the call for a W3C password manager API. SSH would be better, but a lot of the intents, actions etc are the same. signature.asc Description: This is a digitally signed message part.
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Karl Auer wrote: > Speaking for myself, I'm one of the "if I want to allow direct outside > connection to my interior machines I should be able to" crowd. While "direct" and "interior" are not compatible that you actually mean some indirections... Anyway, what if, your ISP assigns a globally unique IPv4 address to your home router (a NAT box) which is UPnP capable? That's what the largest retail ISP in Japan is doing. Masataka Ohta
Re: LinkedIn password database compromised
Anonymity on the Internet is a feature, because a lot of the world netcitizens come from countries where saying this or that is a crime, and can get you in trouble. Any asymetric cryptography solution that remove anonymity is a bad thing. Making censorship easier on the internet is making it worse. What could do some good, is to discredit some bad practices, and propose alternate better practices. This is hard, and part of it is because some people good practices is other people good practices. We can't start this yet, because we don't agree on these good practices. Theres something weird with passwords length, on most websites you are allowed to type a 80 or 120 characters long name. But if you try that with your password, you find a problem. Somehow VARCHAR(120) is unfeasible for passwords, but ok for first_name,second_name. Is even more weird wen people are storing hashs. The length of a md5 don't change if I choose very long passwords, so why are people limiting password length? Other weird limitations that "must go", is the idea that you can't use "special characters". The expresion "special characters" is a red flag itself. Most passwords sould allow UTF-8, and allow anything that UTF-8 allow. Forcing people to mix uppercase and lowercase.. I understand where this come from. It enhance the password strength. A what price? Making passwords a random mix of letter and numbers make then hard to remember and make life miserable for everyone. Practices to make passwords stronger may be pushing people to write password down, or reuse passwords. -- ℱin del ℳensaje.
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
> On Wed, 2012-06-20 at 19:05 -0400, Jay Ashworth wrote: > That is, I don't want the architecture of the Internet to be crippled > by NAT everywhere. If you want to NAT *your* network, go for it. in this case, an air gap might be encouraged randy
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
On Wed, 2012-06-20 at 19:05 -0400, Jay Ashworth wrote: > Ah, you're on the "I should be required to allow direct outside > connection to my interior machines if I want to be connected to the > Internet" crowd. Speaking for myself, I'm one of the "if I want to allow direct outside connection to my interior machines I should be able to" crowd. And also one of the "if I and someone else want to connect our hosts directly we should be able to" crowd. That is, I don't want the architecture of the Internet to be crippled by NAT everywhere. If you want to NAT *your* network, go for it. As a local stalwart is wont to say, "I encourage my competitors to do that" ;-) Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
