The You are Now in France attack, still with us after all these years
I was browsing through the Windows download centre for reasons not relevant here and came across KB955417, dated 22 August 2008: Install this update to resolve an issue in which protected storage (PStore) uses a lower quality cryptographic function when the system locale is set to French (France). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
EV certs: Doing more of what we already know doesn't work
Inspired by Ian Grigg's comment (in the subject line) and various remarks made in a recent thread, I had a look at the Verisign 1.0 CPS from 1996 and the very latest Verisign CPS from June 2008, twelve years later. Here's the authentication requirements for businesses. One is from the 1.0 CPS, which was going to Solve the Problem twelve years ago. The other is from the 2008 EV-cert CPS, which is going to Solve the Problem today. Without going out to check, see if you can tell which is which. I've harmonised the style and wording a bit since it's otherwise possible to make a pretty good guess based on the form of the text, the current CPS has way more legalese: Where required, the third party confirms the business entity's name, address, and other registration information through comparison with third- party databases and through inquiry to the appropriate government entities. Confirmation of information of companies, banks, and their agents requires certain customized (and possibly localized) procedures focusing on specific business-related criteria (such as proper business registration). The third party also provides telephone numbers that are used for out-of-band communications with the business entity to confirm certain information (for example, to confirm an agent's position within the business entity or to confirm that the particular individual listed in the application is in fact the applicant). If its databases do not contain all the information required, the third party may undertake an investigation, if requested by the IA, or the certificate applicant may be required to provide additional information and proof. The third party must be a legally recognized entity whose formation included the filing of certain forms with the Registration Agency in its Jurisdiction, the issuance or approval by a Registration Agency of a charter, certificate, or license, and whose existence can be verified with that Registration Agency, and must have a verifiable physical existence and business presence. If the third party represents itself under an assumed name, VeriSign verifies the third party's use of the assumed name. The only difference I can see is that one CPS exhaustively itemises the various bits and pieces that are checked whereas the other gives it in general terms, I've left out the list itself because it'd make this a five-page posting with not a lot more content. If you want to see the verification requirements for yourself, they're in section 5.1.3 (old CPS) and Appendix B1 5(c) with an almost-identical copy at 14(C) with more detail in sections that follow (new CPS). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Leichter, Jerry [EMAIL PROTECTED] writes: The sitation today is (a) the decreasing usefulness of passwords - those anyone has a chance of remembering are just to guessable in the face of the kinds of massive intelligent brute force that's possible today and (b) the inherently insecure password entry mechanisms that we've trained people to use. It's actually not that bad, we have some really good password managers that can take care of this for us, alongside quite a bit of research from HCI people that examine their effectiveness. By password manager I mean one that generates a strong password for you and supplies it as required, not the noddy managers built into things like web browsers, look at something like Roboform for an example of what I mean. The problem is that I don't know of any application that natively uses them, there are between half a dozen and a dozen Firefox plugins and third-party apps (it varies over time) that all provide enhanced password-handling capabilities but the browser itself still has the incredibly clunky 1.0 manager that it's always had (not specifically picking on FF here, all the others are just as bad, the difference is that FF has a pile of functioning plugins and usability research that demonstrate how to get it right). The problem isn't with passwords, it's with developers: Passwords are insecure because developers have chosen to make them insecure. We have mechanisms to address a lot of the problems with passwords but no-one ever uses them. Even suggesting some of these things is hard ehough, the response to What about using security measure X which addresses problem Y isn't to use measure X but to find some obscure corner case where X won't work, declare the problem unsolveable, and keep on doing the same thing that already didn't work the last 100 times we tried it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Leichter, Jerry wrote: The problem is what that something else should be. Keyfobs with one-time passwords are a good solution from the pure security point of view, but (a) people find them annoying; (b) when used with existing input mechanisms, as they pretty much universally are, are subject to MITM attacks. The equivalent technology on a USB plugin is much easier on the user in some circumstances, but is subject to some bad semantic attacks, as discussed here previously. Also, it's not a great solution for mobile devices. DoD/government uses smartcards, but that's probably not acceptable to the broad population. There's been some playing around with cellphones playing the role of smartcard, but cellphones are not inherently secure either. Cellphones are not inherently secure, but *could* be inherently secure. Each cellphone sim card has a unique identity. It is possible to guarantee that a message goes to or from a cellphone containing a particular sim card - but present phone software provides no means to do this. If a cellphones has nfc communications capable of talking to a pc, then the whole interaction could be made painlessly automatic - touch your cellphone to the pc nfc sensor to login to the website, touch it to the security door to unlock the security door, touch it to the cash register, observe the indicated payment on the cellphone screen, and press OK, touch it to the screenless, keyboardless atm, and the interaction comes up on your phone screen instead of the ATM screen, touch cellphones to pay money from one individual to another. The major obstacle is that the government would want a strong binding between sim cards and true names, which is no more practical than a strong binding between physical keys and true names. Absent useful cellphone software, passwords must suffice. With a limit on the number of guesses before people get locked out, passwords *do* suffice - but then we need a means to unlock the account, and a means of password recovery. Although cellphones and email are insecure, a use once short lived password emailed or instant messaged to the user is secure enough. Trouble is, what happens if the user's email account is stolen? I had this problem. I was using my hotmail account as the password recovery account for various high value domain names. Someone called up hotmail's password recovery, and human engineered a password reset out of the hotmail staff, and then used email based password recovery to seize my domain names. I eventually got them back, using reset passwords snail mailed to my physical post office box, and now the email account associated with my domain names is at a service that provides no password recovery mechanism - and therefore provides an attacker with a very large number of opportunities to guess, requiring an insanely strong password. Snail mail to a post office box is a secure password reset mechanism, short of a well timed physical attack on the post office. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Lava lamp random number generator made useful?
A cheap USB camera would make a good source. The cheaper the better, too. Pull a frame off, hash it, and it's got entropy, even against a white background. No lava lamp needed. I sort of agree, but I feel cautious about recommending that people use their holiday snaps. And then post them on line... if you see where I am going :) But it is a good suggestion. That's not at all what I suggested. There are so many ways that one can creatively screw up reasonable cryptographic advice that I don't think it's worth bothering with. The point is that if you take a cheap 640x480 (or 320x240) webcam and point it against a photographic grey card, there's going to be a lot of noise in it, and this noise is at its bottom quantum in nature. Thus, there's a lot of entropy in that noise. Photographic engineers work *hard* to remove that noise, and you pay for a lack of noise. I'm willing to bet that if I give you hashes of frames, knowing this process, you can't get pre-images. I'll bet that you can't get pre- images even if I let you put a similar camera next to the one I'm using. In short, I'm willing to bet that a cheap camera is a decent random number source, even if you try to control the image source, to the tune of 128-256 bits of entropy per frame. No lava lamps are needed, no weird hardware. Just use the noise in a CCD. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Peter Gutmann wrote: The problem is that the default has always been to be insecure, and there's no effective way to get people to move to the secure non-default, or at least none that isn't relatively easily circumvented by a bit of creative thinking and/or social engineering. If the user is used to logging in by a user interface that is not easy for forge remotely - click on bookmark to bring up a user interface that is difficult to remotely forge - then this does indeed work. There is always the give-your-password-over-the-phone attack, but the fact that phishers seeking WoW gold actually have to use the give-your-password-over-the-phone attack against WoW players shows the potency of a deliberately non standard, difficult to forge, user interface. WoW security does not stop phishing, but it makes phishers work for their money. WoW keeps telling users never give your password to another person, no one at WoW will ever ask you for your password. Obvious advice, easy to understand and follow. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
On Mon, Sep 22, 2008 at 08:59:25PM -1000, James A. Donald wrote: The major obstacle is that the government would want a strong binding between sim cards and true names, which is no more practical than a strong binding between physical keys and true names. I've a hard time believing that this is the major obstacle. We all use credit cards all the time -- apparently that's as good a strong binding between [credit] cards and true names and as the government needs. (If not then throw in cameras at many intersections and along freeways, add in license plate OCR, and you can tie things together easily enough. Wasn't that a worry in another recent thread here?) More likely there are other problems. First, there's a business model problem. Every one wants in: the cell phone manufacturer, the software developer, the network operators, and the banks. With everyone wanting a cut of every transaction done through cell phones the result would likely be too expensive to compete with credit cards, even after accounting for the cost of credit card fraud. Credit card fraud and online security, in any case, are pretty low on the list of banking troubles these past few weeks, and not without reason! Second, there's going to be standard issues. Third the nfc technology has to be commoditized. Fourth there's cost of doing an initial rollout of the POS nfc terminals and building momentum for the product. Once momentum is there you're done. And there's risk too -- if you fail you lose your investment. ... Trouble is, what happens if the user's email account is stolen? Touble is: what happens if the user's cell phone is stolen? Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
James A. Donald [EMAIL PROTECTED] writes: If the user is used to logging in by a user interface that is not easy for forge remotely - click on bookmark to bring up a user interface that is difficult to remotely forge - then this does indeed work. It might have been secure enough back in the days before almost every machine was infected by things like drive-by malware. Now that the hardware the user is on can no longer be trusted, this would only raise the bar slightly, and cause the bad guys, who already own half the machines on the net, to work a few more hours. I won't say such a thing would be bad if it already existed, but it seems like it would no longer be enough. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
