Re: the limits of crypto and authentication
It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. Steven M. Bellovin wrote: > There's been a lot of discussion about how to strengthen cryptography > and authentication, to get away from problems of phishing, pharming, > etc. But such approaches can take you only so far, as this link > indicates: > > http://www.lurhq.com/grams.html > > Briefly, it's a Trojan that waits for you to log int o E-Gold, checks > your balance, and drains your account except for .004 grams of gold. > > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
To validate the transaction, a receipt could be sent to the user encrypted by the server's public key. If the receipt is correct, the user enters their PIN to 'sign' the transaction. I'm assuming an asymmetric authentication system here outside the browser. The attacker would have to steal the user's private key, their PIN and the server's private key, correct? I know that if the PC is compromised anything is possible, but I think this raises the bar significantly - perhaps to an unprofitably level. Steven M. Bellovin wrote: > In message <[EMAIL PROTECTED]>, Nick Owen writes: > >>It would seem simple to thwart such a trojan with strong authentication >>simply by requiring a second one-time passcode to validate the >>transaction itself in addition to the session. >> > > > How does the user know which transaction is really being authenticated? > (I alluded to this in a 1997 panel session talk; see > http://www.cs.columbia.edu/~smb/talks/ncsc-97/index.htm ) > > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb > > > -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
I think that the cost of two-factor authentication will plummet in the face of the volumes offered by e-banking. Also, the more uses for the token, the more shared the costs will be. The question to me is will the FIs go with a anything beyond secure cookies, IP address validation and unique images. Will they be forced to by the powers that be or by disclosure requirements after the basic systems are thwarted? I also think that the lower end cell phone is now capable of handling the task. While a PC client may not be very secure, it does offer some potential benefits such as auto-validating SSL certs. Whether the carriers will bother with a potential revenue stream in two-factor authentication when they can make more money in ringtones is another question - back to the business model ;). Ian Grigg wrote: > FTR, e-gold were aware of the general makeup of this > threat since 1998 and asked someone to look at it. The > long and the short was that it was more difficult to solve > than at first claimed, so the project was scrapped. This > was a good risk-based decision. The first trojans that I > know of for e-gold weren't spotted until 12-18 months > ago, so it was also a profitable decision. What they are > doing now I don't know. > > In the payments world we've known how to solve all > this for some time, since the early 90s to my knowledge. > The only question really is, have you got a business > model that will pay for it, because any form of token is > very expensive, and the form of token that is needed - > a trusted device to put the application, display, keypad > and net connection on - is even more expensive than > the stop-gap two-factor authentication units commonly > sold. > > iang -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
I think the failure of Amex Blue is due to poor timing and the requirement for hardware on the end-user's PC. At the time of it's introduction ecommerce and online banking were just getting started and consumers were more worried about whether the store was real or not than having their card stolen. It wasn't until identity theft and the rush of disclosures due to SB1386 et al here in the US that people cared about security and privacy (in some way). What I can't understand is why Visa and Amex haven't started to push their one-time credit card software solutions again - this time as protection for your privacy. I would think people would be much more receptive to it now. Little has changed, except the market's perception of the risk of using credit cards online. Amex actually pulled their program in 2004, IIRC. [EMAIL PROTECTED] wrote: > Nick Owen writes: > | I think that the cost of two-factor authentication will plummet in the > | face of the volumes offered by e-banking. > > Would you or anyone here care to analyze > what I am presuming is the market failure > of Amex Blue in the sense of its chipcard > and reader combo? > > --dan > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
I think the difference now is the number of vendors entering the market, the variety of solutions ( and their relative security), and demand outside of Europe. When we started in mid-2001, we were looking at the existing hardware guys and that is it. Now there a handful of venture-backed software players with different solutions all targeting the banking market, which didn't exist then. We have not seen any interest in our two-factor solution from Germany or any country where they have some form of two-factor authentication. Perhaps this is similar to the US corporate market where companies that have tokens aren't very interested in switching to save money - the CSO only takes risk in switching and sees no personal benefit in reducing costs (my theory at least) so there's no true vetting, only beating up the current vendor for a slightly better deal. Thus your banks will still complain that the price of mailing paper is too high, which of course it is when compared to software tokens. We are, however, seeing interest from US and South American banks and the numbers are huge and we will be very aggressive in pricing. We also see that we are competing against companies that use IP address verification, secure cookies and other things that are readily compromised, but apparently easy to roll-out and maintain and inexpensive. So, we have to compete against those substitutes that don't even use cryptography or two-factor authentication but would be better termed as fraud detection and prevention. Florian Weimer wrote: > * Nick Owen: > > >>I think that the cost of two-factor authentication will plummet in the >>face of the volumes offered by e-banking. > > > I doubt this is true. In Germany, we already use some form of > two-factor authentication for Internet banking transaction (account > number/password and a one-time password for each transaction). Yet > banks are desperately looking for alternatives because distributing > those one-time password lists is too expensive (!). To me, this was > quite surprising because it's just one sheet of paper every 200 > transactions or so. > > Even worse, this scheme has failed, and there are successful attacks > in the wild (involving compromised client PCs). Right now, > time-dependent tokens do help, but only because you outrun the other > guy. The real-time requirements imposed by them are not a fundamental > obstacle to the attackers, and even now, the way they route the money > makes it very hard to detect things in real-time (at least on the > money side). > > Well, you can imagine my surprise when Howard Schmidt praised > two-factor authentication as a solution to our current problems at the > FIRST 2005 conference. 8-/ > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
I would appreciate your thoughts on WiKID. We use asymmetric keys to encrypt PINs and one-time passcodes between a client and the server. The server talks to various network clients using protocols such as LDAP, Radius, or using our own SSL-tunneled wAuth protocol. We believe that replacing passwords is the right economic model to fund PK deployment widely to consumers. The client can then be extended to provide encryption for apps such as the credit card app described below. We have just released version of WiKID under the GPL. The GPL client uses RSA encryption. The non-GPL version uses Ntru, making it suitable for wireless clients (RSA key gen on a java cell phone is a bitch). We have set up http://www.wikidsystems.net as our open source home page and https://sourceforge.net/projects/wikid-twofactor/ is the sourceforge project page as well - which includes a white paper and documentation. Comments and contributions are much appreciated. tia, Nick Ian G wrote: > Anne & Lynn Wheeler wrote: > >> the major ISPs are already starting to provide a lot of security >> software to their customers. >> >> a very straight forward one would be if they provided public key >> software ... to (generate if necessary) and register a public key in >> lieu of password ... and also support the PPP & radius option of having >> digital signature authentication in lieu of password checking >> http://www.garlic.com/~lynn/subpubkey.html#radius > > > Right. And do the primary authentication of the key > using some other mechanism that is outside the strict > crypto. > > (IOW, Dave, your plan will work, as long as it is > built from ground up with no prior baggage! IMHO!) > > This is such a no-brainer that when I first came > across the solution over a decade ago now, I never > gave a thought as to how it could be anything but > the one way to do things. It just works, and very > little else works anywhere as well. > > Yet, we are still grubbing around like cavemen in > the mud. And then there is this: > > http://www.business2.com/b2/web/articles/print/0,17925,1096807,00.html > > $5M Mobile ID for Credit Card Purchases > WHO: John Occhipinti, Woodside Fund, Redwood Shores, Calif. > WHO HE IS: A former executive at Oracle and Netscape, Occhipinti is a > managing director and security specialist, leading investments in > BorderWare and Tacit. > WHAT HE WANTS: Fraudproof credit card authorization via cell phones and > PDAs. > WHY IT'S SMART: Credit card fraud is more rampant than ever, and > consumers aren't the only ones feeling the pain. Last year banks and > merchants lost more than $2 billion to fraud. Most of that could be > eliminated if they offered two-part authentication with credit and debit > purchases -- something akin to using a SecureID code as well as a > password to access e-mail. Occhipinti thinks the cell phone, packaged > with the right software, presents an ideal solution. Imagine getting a > text message on your phone from a merchant, prompting you for a password > or code to approve the $100 purchase you just made on your home PC or at > the mall. It's an extra step, but one that most consumers would be happy > to take to safeguard their privacy. More important, Occhipinti says, big > banks would pay dearly to be able to offer the service. "It's a killer > app no one's touched yet," Occhipinti says, "but the technology's within > reach." > WHAT HE WANTS FROM YOU: A finished prototype application within eight > months. "I'm looking for the best technologists in security and > wireless, the top 2 percent in their industry," Occhipinti says. The > team would need to be working with a handful of banks and merchants > ready to start trials, in hopes of licensing the technology or selling > the company. > SEND YOUR PLAN TO: [EMAIL PROTECTED] > > The funniest part of all is that even though we > know how to do it in our sleep, Paypal actually > built one as their "original offering" and threw > it away... > >> at that point your public key is now registered with your ISP ... and >> possibly could be used for other things as well ... and scaffolding for >> a certificateless trust infrastructure. > > > Yup. But this will only work if you go back to > basics and build the structure naturally around > the keys. IOW, not using anything from PKI. > >> lots & lots of past postings on SSL landscape >> http://www.garlic.com/~lynn/subpubkey.html#sslcert > > > Watching security thinking advance is like watching > primates evolve from close distance. Either we die > of old age before anything happens, or we get clubbed > t
Re: ECC patents?
James A. Donald wrote: > -- > Whyte, William: > >>It hints that only some particular curves have been >>licensed. It could be that NSA has decided not to buy >>a license for the other curves, or it could be that >>operations on those curves aren't patented. The >>presentation doesn't give enough information to >>establish which. > > > If the NSA paid anything significant for any of the > curves, we would be told. Therefore the NSA paid > nothing or almost nothing, and therefore if the NSA > licensed anything, it would have licensed everything. > > I doubt that the NSA paid any money whatsoever for this > license, making it profoundly unimpressive as evidence > that *any* curves have a plausible valid patent. If the > NSA paid real money, the patent holders would be > sticking it in our face as a price setting precedent. I had a recent discussion with a person in a government agency that indicated we would not be able to use them as a reference and that they would probably want an unlimited license - because there could be no reference to a number of users within the agency. They did say that they would get GSA pricing. I suspect that Certicom got GSA pricing for the deal as is, I assume, required by law. Nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com https://sourceforge.net/projects/wikid-twofactor/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
update: GPL'd two-factor system
Greetings: Here is a brief update on the open source version of the WiKID Strong Authentication System: * New PHP network client released * SugarCRM network client released (based on PHP network client) * Citrix Web Interface network client released * Java token client binary released * Minor code fixes and clean up on the server * Added the WiKID white paper to the downloads section All this and more available for download on sf.net: http://sourceforge.net/projects/wikid-twofactor/ The project home page is http://www.wikidsystems.net/, which includes a poll on what applications people would like to see WiKID-enabled. Work is progressing on C and Python network clients to add to the Java and COM objects and those listed above. Our focus is on adding network clients in new languages and implementing those into applications. Regards, Nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: US Banks: Training the next generation of phishing victims
Peter Gutmann wrote: > > Can anyone who knows Javascript better than I do figure out what the mess of > script on those pages is doing? It looks like it's taking the username and > password and posting it to an HTTPS URL, but it's rather spaghetti-ish code so > it's a bit hard to follow what's going where. > Why have the log on your homepage at all? Why not just a link to the https login??? If the goal is to not have SSL overhead on the homepage, don't. Or is there some extra overhead for login processing that I don't know about? Is there some user dissatisfaction with an extra click to login? I suppose if you really wanted non-SSL logins, you could use a one-time passcodes system with variable length passcodes to prevent race attacks. -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
HTTPS mutual authentication alpha release - please test
Happy Halloween! In what we hope will be a Halloween tradition, we have new release available for testing. WiKID is pleased to announce the alpha release of a major upgrade under the GPL featuring a cryptographic method of mutual authentication for HTTPS: WiKID-2.1: SOMETHING_WiKID_THIS_WAY_COMES The token client is available at sourceforge: http://prdownloads.sourceforge.net/wikid-twofactor/WiKID_Token_Client-2.1-prerelease.zip?download The system works this way: Each WiKID domain now can include a 'registered URL' field and a hash that website's SSL certificate. When a user wants to log onto a secure web site, they start the WiKID token and enter their PIN. The PIN is encrypted and sent to the WiKID server along with a one-time use AES key and the registered URL. The server responds with a hash of the website's SSL certificate. The token client fetches the SSL certificate of the website and compares it the hash. If the hashes don't match, the user gets an error. If they match, the user is presented with registered URL and the passcode. On supported systems, the token client will launch the default browser to the registered URL. We are currently seeking testers for this early release. You do not need to set up a WiKID server to test. We have set up a WiKID server for you. Testers will need to download the latest J2SE WiKID token from sourceforge. Testing information can be found here: https://sourceforge.net/forum/forum.php?thread_id=1376617&forum_id=484250 Most one-time-password systems suffer from man-in-the-middle attacks primarily due to difficulties users have with validating SSL certificates. The goal of this release is to validate certificates for the end user, providing an SSH-esque security for web-enabled applications such as online banking. Any feedback is much appreciated. Sincerely, Nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor Now open source: http://sourceforge.net/projects/wikid-twofactor/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: HTTPS mutual authentication alpha release - please test
cyphrpunk wrote: > On 10/31/05, Nick Owen <[EMAIL PROTECTED]> wrote: > >>The system works this way: Each WiKID domain now can include a >>'registered URL' field and a hash that website's SSL certificate. When >>a user wants to log onto a secure web site, they start the WiKID token >>and enter their PIN. The PIN is encrypted and sent to the WiKID server >>along with a one-time use AES key and the registered URL. The server >>responds with a hash of the website's SSL certificate. The token client >>fetches the SSL certificate of the website and compares it the hash. If >>the hashes don't match, the user gets an error. If they match, the user >>is presented with registered URL and the passcode. On supported >>systems, the token client will launch the default browser to the >>registered URL. > > > What threat is this supposed to defend against? Is it phishing? I > don't see how it will help, if the bogus site has a valid certificate. Yes, phishing. The token client isn't checking to see if the cert is valid, it's only checking to see if it's the same as the one that is on the WiKID authentication server. The cert doesn't have to be valid or have the root CA in the browser. > > >>Most one-time-password systems suffer from man-in-the-middle attacks >>primarily due to difficulties users have with validating SSL >>certificates. The goal of this release is to validate certificates for >>the end user, providing an SSH-esque security for web-enabled >>applications such as online banking. > > > What does it mean to "validate a certificate"? Aren't certs > self-validating, based on the key of the issuer? Again, what is this > protecting against? Bad choice of words on my part - validate is a loaded word vis-a-vis certs. The token client pulls down a hash of the certificate from the WiKID server. It pulls the certificate from the website and performs a hash on it. It compares the two hashes and if they match, presents the user with the OTP and the message: "This URL has been validated. It is now safe to proceed." Does that clarify? > > CP > -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor Now open source: http://sourceforge.net/projects/wikid-twofactor/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: HTTPS mutual authentication alpha release - please test
>>> >>>What threat is this supposed to defend against? Is it phishing? I >>>don't see how it will help, if the bogus site has a valid certificate. >> >>Yes, phishing. The token client isn't checking to see if the cert is >>valid, it's only checking to see if it's the same as the one that is on >>the WiKID authentication server. The cert doesn't have to be valid or >>have the root CA in the browser. > > > But this would only help in the case that an old URL is used and a new > certificate appears, right? That's what would be necessary to get a > match in your database, pull down an old certificate, and find that it > doesn't match the new certificate. The token client has the true URL as well, so the traditional phish of sending users to the wrong site shouldn't work either. The user would have to ignore the launched browser and use the fake site. > > Phishers don't do this. They don't send people to legitimate URLs > while somehow contriving to substitute their own bogus certificates. > They send people to wrong URLs that may have perfectly valid > certificates issued for them. I don't see how your system defends > against what phishers actually do. They do this too by attacking DNS servers with cache poisoning. In this case the token client will not be able to validate the certificate. nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor Now open source: http://sourceforge.net/projects/wikid-twofactor/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: HTTPS mutual authentication alpha release - please test
cyphrpunk wrote: > On 11/3/05, Nick Owen <[EMAIL PROTECTED]> wrote: > >>The token client pulls down a hash of the certificate from the >>WiKID server. It pulls the certificate from the website and performs a >>hash on it. It compares the two hashes and if they match, presents the >>user with the OTP and the message: >>"This URL has been validated. It is now safe to proceed." > > > Let me see if I understand the attack this defends against. The user > wants to access https://www.citibank.com. The phisher uses DNS > poisoning to redirect this request away from the actual citibank > machine to a machine he controls which puts up a bogus citibank page. > To deal with the SSL, the phisher has also managed to acquire a fake > citibank certificate from a trusted CA(!). He fooled or suborned the > CA into granting him a cert on citibank.com even though the phisher > has no connections with citibank. He can now use this bogus cert to > fool the client when it sets up the SSL connection to citibank.com. > > Is this it? This is what your service will defend against, by > remembering the hash of the "true" citibank certificate? No, this is not it. It is this attack and similar: http://tinyurl.com/a3b89 The phishers are not using valid certificates, but users are so immune to warnings about certificates that they don't pay attention to them. It may be a DNS cache poison or the typical email; it could be any mechanism to send the user to a fraudulent site. What is being provided is a mechanism to route the users to the correct site by providing a way to validate the certificate for them. nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor Now open source: http://sourceforge.net/projects/wikid-twofactor/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: HTTPS mutual authentication alpha release - please test
Hadmut Danisch wrote: > Mmmh, I'd have two questions about this: > > > - It seems that you are not defending against an attack, but trying to > protect the user against his own ignorance. The user ignores the > warning label, so you want to replace it with a bigger warning > label. But the bigger warning label doesn't contain any news or more > information, or any protection that the smaller label doesn't > provide. It's just that the bigger warning label is bigger (or more > red, or more alerting letters...), hoping to wake the user up? Feedback on the UI would be particularly helpful. I think it goes a bit beyond warning labels in that it should be a very familiar site and when it goes away, the warning is a shock, much like SSH when the server key has changed. I estimate it would take about 5 minutes to test this online. Directions are in the forums on sourceforge. > > But user ignorance is not a new type of attack. If the user pays > attention to the browser warnings, then I don't see what advantage > WIKD should have. Inventing new protocols and complexity, and > trusting an additional party without good reason and reasonable > advantage is never a good idea in security. I agree that user ignorance is not a new attack. We just saw a problem and wanted to attack the problem. Users do not pay attention to the warnings. I think that is widely accepted, though I don't have any references at hand. I don't think of it as a new protocol, rather a check on an old protocol that is having some problems. Perhaps a clarification is in order. While WiKID is well-suited to a service bureau model, I suspect that most people would want it behind their own firewall. They can update the certificate at any time. There is no third-party to trust and if you want to look at the code, you may as it is open. > > - The authorized owner must be able to replace the server certificate > with a new one at any time, e.g. when the secret key has been lost > or compromised. > > case 1: If it is not possible to update the hash stored at WIKID, > how would the authorized owner ever be able to replace the > compromised key with a new one? Wouldn't this force him into > continuing in using the compromised key? As noted above, the key can be changed. > > case 2: If it is possible to update the hash stored at WIKID, and if > the attacker was already able to register a bogus certificate at an > official CA, why shouldn't he be able to update the certificate at > WIKID as well? In what way is WIKID's certificate verification > procedure more reliable than the one of the "trusted CAs" ? We're not really addressing the situation where the attacker has stolen a valid private cert, but where an attacker is using some social engineering trick to fool the user with a MITM site. Thus, we believe there is value in providing another way to validate to the user that they are going to the correct site. Nick > > > Hadmut > > > > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor Now open source: http://sourceforge.net/projects/wikid-twofactor/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: HTTPS mutual authentication alpha release - please test
James A. Donald wrote: > -- > It seems to me that mutual authentication is pretty much > irrelevant to HTTPS and certificates. You mutually > authenticate by both knowing the password, as in SPEKE. > > Of course, SPEKE is patented, so is this scheme a way of > getting around the patents? We're not that smart - well, perhaps I should speak only for myself. We originally developed WiKID to target corporate VPNs with the WiKID client running on a wireless device (the Wi in WiKID) with no thought of mutual authentication because phishing was only getting under way. Only after we added the client support for Windows, Mac & linux and phishers started getting really active did we think about adding MA. > > --digsig > James A. Donald > 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG > a5RzA9UesxiZw+cjRsz+8yPLKwJdTMfUjcQq0iZf > 4ybo9wAzZZNG5YyF69jzKw/oXw3fL7FGj86oXey46 > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor Now open source: http://sourceforge.net/projects/wikid-twofactor/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NSA knows who you've called.
Perry E. Metzger wrote: > [EMAIL PROTECTED] writes: >> While I agree with you, the public does not, >> so far as I can tell, find itself willing to >> risk insecurity for the benefit of preserving >> privacy, as this article in today's Boston >> Globe would tend to confirm. > > I'm sure. On the other hand, I think it is our place, as security > professionals, to explain why the tradeoff is a false one. Respect for > individual rights is not something we do in good times because it is a > luxury we can afford when there is stability. It is something we need > most in bad times, because it is what keeps us safe and maintains > stability itself. Or to teach pollsters to ask the correct questions. Take this survey: http://www.washingtonpost.com/wp-srv/politics/polls/postpoll_nsa_051206.htm What it this question from the poll: It's been reported that the National Security Agency has been collecting the phone call records of tens of millions of Americans. It then analyzes calling patterns in an effort to identify possible terrorism suspects, without listening to or recording the conversations. Would you consider this an acceptable or unacceptable way for the federal government to investigate terrorism? Do you feel that way strongly or somewhat? Was instead: The NSA has been collecting the phone call records of tens of millions of Americans possibly in violation of the law. Would you consider it acceptable for the government to break the law to investigate terrorism? Nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication https://www.linkedin.com/in/nickowen - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Passwords jump-started Fumo probe
http://www.philly.com/mld/inquirer/news/local/states/pennsylvania/counties/philadelphia_county/philadelphia/15727557.htm The feds were unable to break the encrypted email files until one admin came up with a password list on a portable drive. I wonder if they tried to brute-force the password? nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication https://www.linkedin.com/in/nickowen - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
