Re: Exponent 3 damage spreads...
Am Montag, den 25.09.2006, 01:28 +0200 schrieb Philipp Gühring: Hi, We have been researching, which vendors were generating Exponent 3 keys, and we found the following until now: * Cisco 3000 VPN Concentrator * CSP11 * AN.ON / JAP (they told me they would change it on the next day) (perhaps more to come) My current estimate is that 0.26% of the certificates in the wild have Exponents =17 I did a little survey one month ago for my bsc. thesis. I found out, that round about 1.19% of all https-server-certs use an exponent = 17. I did choose round about 32,000 random webservers for this survey. What is intresting is what happens when it comes to imap-ssl. Here, only 0.1% of all servers use a server-cert with exponent = 17. Imap-ssl users seem to be the better ssl-users, tls 1.0 is more widespread there, small rsa-modulus-sizes are more seldom, and ssl 2.0 is not so common there too. I will publish some more details later. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: interesting HMAC attack results
Forgery and Partial Key-Recovery Attacks on HMAC and NMAC Using Hash Collisions, by Scott Contini and Yiqun Lisa Yin (*) On Mon, 25 Sep 2006, Anton Stiglic wrote: Very interesting, I wonder how this integrates with the following paper http://citeseer.ist.psu.edu/bellare06new.html (**) According to Section 1.4 of (*), the new result on HMAC does not contradict the analysis in (**). That is the assumption used by Mihir Bellare do not hold for MD4, MD5, and SHA-1. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
From a security point of view, shar has obvious problems :-) Really, what? There are things it doesn't do, but since it's only a packaging format that's a good thing. /r$ -- STSM, Senior Security Architect SOA Appliances Application Integration Middleware - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: fyi: On-card displays
and for a whole lot of drift with respect to smartcards being pda/cellphone wanabees Storm building over RFID-enabled passports http://www.networkworld.com/news/2006/092106-rfid-passports.html from above: The chip, which is embedded inside the cover of the passport, contains only a duplicate copy of the passport photograph and the printed data. The digital data is intended to prevent forgeries by allowing inspectors to compare the printed and digital data. ... snip ... the article mentions that integrity of the electronic data is protected by a digital signature (preventing tampering and/or forgeries). At some level, the digitally signed data can be considered a electronic credential that is extremely difficult to counterfeit. posting with number of references about cloning (electronic) passport data http://www.garlic.com/~lynn/aadsm25.htm#11 And another cloning tale from three factor authentication model http://www.garlic.com/~lynn/subpubkey.html#3factor * something you have * something you know * something you are ... frequently hardware tokens (chips) are implemented as something you have authentication (i.e. the chip supposedly contains some unique information ... which differentiates it from every other chip). some recent posts mentioning something you have authentication. http://www.garlic.com/~lynn/aadsm25.htm#30 On-card displays http://www.garlic.com/~lynn/aadsm25.htm#25 RSA SecurID SID800 Token vulnerable by design http://www.garlic.com/~lynn/aadsm25.htm#16 Fraudwatch - ChipPIN one-sided story however, taking the passport chip data as an electronic credential, cloning the information doesn't (directly) represent a vulnerability ... since it is more analogous to digital certificates ... which are readily assumed to be widely distributable. the passport chip data as an electronic credential containing a digital photograph ... and matching a person's face to the digital photograph then represents something you are authentication (as opposed to assuming the chip ...or even a cloned chip ... represents any sort of something you have authentication). in theory, an electronic credential would be considered valid, regardless of any specific chip container that it might be carried in. one might then make the assertion, that a passport electronic credential could be carried in any device capable of reliably reproducing the correct bits. going back to the issue raised in http://www.garlic.com/~lynn/aadsm25.htm#30 On-card displays that most smartcards/chips are really pda/cellphone wanabees ... one might suggest that you could then even carry your electronic credential/passport in your pda or cellphone ... as opposed to needing a separate physical device. the issue that then is raised are there any significant privacy considerations similar to privacy issues raised with x.509 identity digital certificates from the early 90s (having large amounts of privacy information in x.509 identity digital certificates widely distributed all over the place). by the mid-90s, many institutions considered that the privacy and liability problems with x.509 identity digital certificates were so significant that they retrenched to relaying-party-only certificates. lots of past posts mentioning rpo-certificates http://www.garlic.com/~lynn/subpubkey.html#rpo these were digital certificates that effectively only contained some sort of database index or account number. the relying party then used the account number to retrieve the actual information of interest (w/o having to widely expose it in any way). the analogy for an electronic passport infrastructure would be just needing to present the passport number. the actual credential data (and any photos or other information necessary for something you are authentication) is retrieved from secure online repository. as repeatedly pointed out in the RPO digital certificate scenario ... it isn't even necessary to include the account/passport number in a digitally signed document ... since there is no information that needs integrity protection. the person just makes an assertion as to their correct account/passport number. the appropriate information is then retrieved from the online infrastructure and used for authentication (and whatever other required purposes). asserting the wrong account/passport number presumably retrieves information that fails to result in valid authentication. needing (some certification authority) to digitally sign the passport/account number (in the RPO scenario) for any possible integrity purposes, is then redundant and superfluous (one of my oft repeated comments). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On 9/26/06, Richard Salz [EMAIL PROTECTED] wrote: Really, what? There are things it doesn't do, but since it's only a packaging format that's a good thing. Though there are unshar tools, typically people run it as input to /bin/sh, usually without reading through it (and given the level of obfuscation sh offers, it's not clear that you couldn't sneak something through even if the person skims it). -- Enhance your calm, brother; it's just ones and zeroes. Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
National Security Agency ex-classified publication indexes now online
[The Memory Hole also publishes an interesting list of FOIA logs, listing who asked NSA for what, across many years. I see a lot of friends in there. http://www.thememoryhole.org/foi/caselogs/ -- gnu] HUGE CACHE OF NATIONAL SECURITY AGENCY INDEXES PUBLISHED ONLINE By Michael Ravnitzky , [EMAIL PROTECTED] This page, just published online at Russ Kick's site, The Memory Hole: http://www.thememoryhole.org/nsa/bibs.htm Or you can get there from his home page at http://www.thememoryhole.org contains indexes of four periodicals published by the National Security Agency, plus a listing of publications from the NSA's Center for Cryptologic History. These indexes haven't been publicly released until now, and many of the Cryptologic History publications weren't previously known to the public: Cryptologic Quarterly Index NSA Technical Journal Cumulative Index Cryptologic Spectrum Index Cryptologic Almanac Index Center for Cryptologic History Publications You can request from NSA a copy of any of the reports listed in these hundreds of pages of indexes, using the instructions provided. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Exponent 3 damage spreads...
On Sep 25, 2006, at 10:29 AM, Simon Josefsson wrote:
Leichter, Jerry [EMAIL PROTECTED] writes:
I agree that there are two issues, and they need to be treated
properly. The first - including data after the ASN.1 blob in the
signature computation but then ignoring it in determining the
semantics - is, I'll argue, an implementation error. You list only
OpenSSL as definitely vulnerable, NSS as ?, so it sounds like
only one definitive example.
Yes. I'm only familiar with NSS as a user, not as a developer. For
some reason, the Mozilla bug tracker hides information about this
problem from us, so it is difficult to track the code down.
I believe I identified the patch that solved the problem in NSS,
search for 350640 in:
http://bonsai.mozilla.org/cvsquery.cgi?branch=HEADfile=mozilla/
security/nss/date=month
The bug discussion is not public:
https://bugzilla.mozilla.org/show_bug.cgi?id=350640
Possibly also bug reports 351079 and 351848 are related to the same
problem, but these bugs are also hidden.
The actual patch for 350640 is:
http://bonsai.mozilla.org/cvsview2.cgi?
diff_mode=contextwhitespace_mode=showsubdir=mozilla/security/nss/
lib/
utilcommand=DIFF_FRAMESETfile=secdig.crev1=1.6rev2=1.7root=/
cvsroot
If some NSS developer could chime in, that would help.
Even if NSS has the same problem, one has to look at code
provenance.
Sure.
Hi Simon,
I'm not a NSS developer, but we did have a look at the code here to
figure out what EXACTLY those guys patched. The relevant portion can
quite easily be found by diff'ing the tags FIREFOX_1_5_0_6_RELEASE
vs. FIREFOX_1_5_0_7_RELEASE on their CVS tree for example. Insofar I
don't think that leaving the bug reports private after actually
shoving out the release does not really help things in this
situation; quite the opposite.
Relevant files to this problem that were patched turned out to be
security/nss/lib/cryptohi/secvfy.c and nss/lib/util/secdig.c. Have a
look at the function DecryptSigBlock() in secdig.c, lines 92-95
/* make sure the parameters are not too bogus. */
if (di-digestAlgorithm.parameters.len 2) {
goto sigloser;
}
Quite amused, we also noted the following:
/* XXX Check that tag is an appropriate algorithm? */
---
/* Check that tag is an appropriate algorithm */
if (tag == SEC_OID_UNKNOWN) {
goto sigloser;
}
This means, that before the patch was applied, NSS indeed was
vulnerable to Kaliski's OID attack.
At least some versions of PKCS#1 does NOT say that, e.g., RFC 3447.
RFC 3447 essentially says to generate a new token and use memcmp().
Such implementations would not be vulnerable to any of the current
attacks, except the Kaliski ASN.1 OID attack (an attack that doesn't
work on existing implementations).
See above.
Cheers,
Ralf
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Exponent 3 damage spreads...
From: Ralf-Philipp Weinmann
[...]
Relevant files to this problem that were patched turned out
to be security/nss/lib/cryptohi/secvfy.c and
nss/lib/util/secdig.c. Have a look at the function
DecryptSigBlock() in secdig.c, lines 92-95
/* make sure the parameters are not too bogus. */
if (di-digestAlgorithm.parameters.len 2) {
goto sigloser;
}
Quite amused, we also noted the following:
/* XXX Check that tag is an appropriate algorithm? */
---
/* Check that tag is an appropriate algorithm */
if (tag == SEC_OID_UNKNOWN) {
goto sigloser;
}
This means, that before the patch was applied, NSS indeed was
vulnerable to Kaliski's OID attack.
While the patch for Firefox obviously fixed the bugs in
security/nss/lib/cryptohi/whatever,
There is another pkcs#1-padding check in security/nss/lib/softtoken/rsawrapr.c,
see function
RSA_CheckSign() and RSA_CheckSignRecover(). Does anybody know what these
functions are used for?
I tried to find that out, but did not get very far...
(Hal Finney also noted these functions some days ago).
It seems to be another creative bug:
/*
* check the padding that was used
*/
if (buffer[0] != 0 || buffer[1] != 1)
goto loser;
for (i = 2; i modulus_len - hash_len - 1; i++) {
if (buffer[i] == 0)
break;
if (buffer[i] != 0xff)
goto loser;
}
/*
* make sure we get the same results
*/
if (PORT_Memcmp(buffer + modulus_len - hash_len, hash, hash_len) != 0)
goto loser;
So it would accept a padding ( 00 || 01 || 00 || garbage || hash ), which is
not exactly what pkcs#1 says :)
The same loop is used in RSA_CheckSignRecover(), but I did not succeed in
finding out what it is exactly used for and if that is a safe application of
the rather wrong code.
Cheers,
Ulrich
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Interesting paper on PKI and TRUSTe
Abstract Widely-used online trust authorities issue certifications without substantial verification of the actual trustworthiness of recipients. Their lax approach gives rise to adverse selection: The sites that seek and obtain trust certifications are actually significantly less trustworthy than those that forego certification. I demonstrate this adverse selection empirically via a new dataset on web site characteristics and safety. I find that TRUSTe-certified sites are more than twice as likely to be untrustworthy as uncertified sites, a difference which remains statistically and economically significant when restricted to complex commercial sites. I also present analogous results of adverse selection in search engine advertising - finding ads at leading search engines to be more than twice as likely to be untrustworthy as corresponding organic search results for the same search terms. See http://www.benedelman.org/publications/advsel-trust-draft.pdf Enjoy, Aram Perez - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: fyi: On-card displays
[EMAIL PROTECTED] wrote: From: Ian Brown [EMAIL PROTECTED] Subject: On-card displays To: [EMAIL PROTECTED] Date: Wed, 20 Sep 2006 07:29:13 +0100 Via Bruce Schneier's blog, flexible displays that can sit on smartcards. So we finally have an output mechanism that means you don't have to trust smartcard terminal displays: http://www.cr80news.com/library/2006/09/16/on-card-displays-become-reality-making-cards-more-secure/ So, when do we see the combined chip/fingerprint reader/display on a payment card :) Doesn't of course address the requirement that we want evidence (such as a signed paper receipt) that can later be adjudicated by a court with higher evidential standards than a bank statement that their systems work perfectly... for a decade or so ... i've made comments that the increasingly powerful smartcards are obsolete because they are really pda(/cellphone) wannabes (after some of the gov. technology transfer legislation in the early 90s, we did some consulting for one of the gov. agencies on attempting to move some smartcard chip based technology into the commercial sector ... and we could already see it was rapidly becoming obsolete). the smartcard target of portable computing device from 70s/80s required various kinds of iso standards because of the lack of appropriate portable input/output capability so there would be standardized, fixed input/output stations that could be used with the portable smartcards. that market niche for smartcards became obsolete with the appearance of pda/cellphone portable input/output capability sometime in the early to mid-90s. possibly part of the problem was that there was significant investment in various kinds of smartcard technology during the 80s and 90s ... and when they became obsolete ... there was some amount of scurrying around attempting to obtain some/any return on the original investments ... even if it was only a few cents on the dollar. they are now contending with various kinds of cellphone/pda payment delivery operations. there is some paradigm discontinuity tho. there is a tradition grown up where the institutions issue the card (payment, identification, etc) ... to some extent smartcard activities are attempting to capitalize on that legacy momentum. an individual's cellphone/pda tends to break that institutional centric issuing paradigm ... since it can involve an individual taking their cellphone/pda (that they already have) and registering it for various activities/transactions/identification ... aka another form of something you have authentication ... but it is possibly a personal device rather than an institution issued device. so there are already various kinds of pda/cellphones with display, input capability ... and some of them even have their own biometric sensing capability. the issue with electronic signature is demonstration of intent ... we got into that when we were asked to help word-smith some of the cal state (and later federal) electronic signature act. various past postings mentioning issue of establishing intent http://www.garlic.com/~lynn/subpubkey.html#signature - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: fyi: On-card displays
Steve Schear wrote: I have a Mondex card from years ago that used a separate reader with LCD. we were asked to do the design/sizing/cost for mondex infrastructure in the us. one of the things that turned up was much of the mondex infrastructure was based on float (initially essentially all going to mondex international) ... cards were almost incidental. somewhere along the way, mondex international even started offering to split the float with national organizations as an inducement to sign up. somewhere along the way a group was also formed to try and map mondex to the internet ... which eventually morphed into IOTP. misc. past posts that mention mondex http://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash http://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS http://www.garlic.com/~lynn/aadsm18.htm#42 Payment Application Programmers Interface (API) for IOTP http://www.garlic.com/~lynn/aadsm20.htm#7 EMV http://www.garlic.com/~lynn/aadsm21.htm#1 Is there any future for smartcards? http://www.garlic.com/~lynn/aadsm23.htm#23 Payment systems - the explosion of 1995 is happening in 2006 http://www.garlic.com/~lynn/2002e.html#14 EMV cards http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002g.html#53 Are you sure about MONDEX? http://www.garlic.com/~lynn/2002g.html#54 Are you sure about MONDEX? http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento http://www.garlic.com/~lynn/2005i.html#10 Revoking the Root http://www.garlic.com/~lynn/2005v.html#1 Is Mondex secure? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
| *That* is the Right Way To Do It. If there are variable parts (like | hash OID, perhaps), parse them out, then regenerate the signature data | and compare it byte-for-byte with the decrypted signature. | | You know, this sort of reminds me of a problem with signatures on | tar.gz files. Basically, you have to keep them around so you can | check the signature, but you can't delete them because you can't | reconstruct the original tar file from an untarred copy because it's | full of metadata that won't necessarily be replicated on your system. | For example, uids and gids. Unfortunately, cpio appears to be worse. | From a tape backup standpoint, tar doesn't store enough (extended | attributes, hard links, etc.) and so it appears to store both too much | and too little at once. VMS has for years had a simple CHECKSUM command, which had a variant, CHECKSUM/IMAGE, applicable only to executable image files. It knew enough about the syntax of executables to skip over irrelevant metadata like link date and time. (The checksums computed weren't cryptographic - at least the last time I used it, many years ago. The command was created to use in patches to provide a quick verification that the file being patched was the right one.) I've always found it surprising that no one seems to have developed similar tools for Unix - with the Gnu libraries for portable access to object/ executable files, it could be done relatively easily. The general issue here is how to checksum the information, rather than the raw data. XML signatures have horrendous problems with this because XML has many equivalent ways to say the same thing, and there is enough information in an XML file for intermediate nodes to be able to change representation without changing semantics - and for various reasons, they do so. (The XML guys try to deal with this by defining a canonical representation for data, and sign *that*. Unfortunately, there are two competing standards for the canonical representation.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Circle Bank plays with two-factor authentication
Circle Bank is using a coordinate matrix to let users pick three letters according to a grid, to be entered together with their username and password. The matrix is sent by email, with the user's account sign on ID in plaintext. Worse, the matrix is pretty useless for the majority of users, with less usability than anything else I saw in a long time. This is what the email says: The following is your Two Factor code for Online Banking for username (sign on ID changed here for privacy reasons). You will be required to enter the grid values associated with the three Two Factor boxes presented with each sign-on to Online Banking. Please save and store this Matrix in a safe yet accessible place. The required entries will be different each time you sign-on. Two Factor Matrix ABCDEFGH ________ 108421175 274992420 336069906 464514684 517686592 These are the additional instructions in the site: Check your e-mail for receipt of the Two Factor Matrix which should be delivered within 2-3 minutes of activation. You can save the e-mail to your desktop for easy access or print the matrix. However, do not write your sign on ID and password on this matrix – treat it securely as you do with a Debit or ATM card. Go back to the online banking sign on page and type in your sign on ID, password, and the three coordinates from your Two Factor Matrix. These three coordinates are randomly selected each time you sign on, so remember to keep your matrix secure and easily accessible. Well, the bank itself already compromised both the sign on ID and the matrix by sending them in an email. All that's left now is a password, which a nice phishing email giving the correct sign on ID might easily get. When questioned about this, the bank's response is that this scheme was designed by the people that design their web site and had passed their auditing. Of course, a compromise now would be entirely the user's fault -- another example of shifting the burden to the user while reducing the user's capacity to prevent a compromise. This illustrates that playing with two-factor authentication can make the system less secure than just username/password, while considerably reducing usability. A lose-lose for users. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
At 14:33 -0400 2006/09/28, Leichter, Jerry wrote: | VMS has for years had a simple CHECKSUM command, which had a variant, CHECKSUM/IMAGE, applicable only to executable image files. It knew enough about the syntax of executables to skip over irrelevant metadata like link date and time. (The checksums computed weren't cryptographic - at least the last time I used it, many years ago. The command was created to use in patches to provide a quick verification that the file being patched was the right one.) I've always found it surprising that no one seems to have developed similar tools for Unix - with the Gnu libraries for portable access to object/ executable files, it could be done relatively easily. The sum command has existed in Unixes since before VMS existed. Checksum has too many characters in the name ;-). Greg. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Circle Bank plays with two-factor authentication
| Circle Bank is using a coordinate matrix to let | users pick three letters according to a grid, to be | entered together with their username and password. | | The matrix is sent by email, with the user's account | sign on ID in plaintext. | | Worse, the matrix is pretty useless for the majority of users, | with less usability than anything else I saw in a long time. | This is what the email says: | | The following is your Two Factor code for Online Banking for | username (sign on ID changed here for privacy reasons). You will be | required to enter the grid values associated with the three | Two Factor boxes presented with each sign-on to Online Banking. | Please save and store this Matrix in a safe yet accessible place. | The required entries will be different each time you sign-on. | | | Two Factor Matrix | | ABCDEFGH | ________ | | 108421175 | | 274992420 | | 336069906 | | 464514684 | | 517686592 | ... Wow. A variation of an idea I suggested back in the '70's The problem then was with telephone calling cards. As those of us old enough will remember, at one time you didn't have a cell phone with you at all times (or at any times). You had to use these things called pay phones. Long distance calls were expensive, and you had to dump a whole bunch of change in to make them work. Very annoying. So you got a calling card, which often charged to your home phone number. Calling cards had a fixed PIN on them. Shoulder surfers would hang around heavily used phones - commuter train stations were a good spot - watch as you entered your account number/PIN, memorize it on the spot and then sell it. These could move remarkably quickly - my wife's PIN was stolen this way, and in use within seconds after she hung up. Over the next hour or so, until the fraud people picked it up, it was used to make several hundred dollars worth of calls from several locations in New York. Anyhow ... my suggestion was that a similar table be printed on the back of the card. (I would have put a multi-digit number at each intersection point and only ask for one value. All told, I'm not sure which approach is better - but with good printing technology you can use much smaller fonts than when you rely on people printing things out themselves.) I also suggested that the numbers be printed in a color - light blue, red against a grey background - that would make it hard to photocopy. No one ever did anything like this with phone cards. Interesting to see the idea re-invented for a different purpose. (Hmm, if I'd patented it, the patent would be running out soon, even assuming I went for the renewal.) Now if only they hadn't done the actual implementation so stupidly -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Circle Bank plays with two-factor authentication
Here,(Mexico) BBVA / Bancomer uses 24 special three digits numbers on a card you need to have at hand to access your account after login and username... the system asks you one of those 24 numbers to allow each session - entry. supposed to be effective. donno if there is a similar system elsewhere. On 28 sept. 06, at 14:34, Ed Gerck wrote: Circle Bank is using a coordinate matrix to let users pick three letters according to a grid, to be entered together with their username and password. The matrix is sent by email, with the user's account sign on ID in plaintext. Worse, the matrix is pretty useless for the majority of users, with less usability than anything else I saw in a long time. This is what the email says: The following is your Two Factor code for Online Banking for username (sign on ID changed here for privacy reasons). You will be required to enter the grid values associated with the three Two Factor boxes presented with each sign-on to Online Banking. Please save and store this Matrix in a safe yet accessible place. The required entries will be different each time you sign-on. Two Factor Matrix ABCDEFGH ________ 108421175 274992420 336069906 464514684 517686592 These are the additional instructions in the site: Check your e-mail for receipt of the Two Factor Matrix which should be delivered within 2-3 minutes of activation. You can save the e-mail to your desktop for easy access or print the matrix. However, do not write your sign on ID and password on this matrix – treat it securely as you do with a Debit or ATM card. Go back to the online banking sign on page and type in your sign on ID, password, and the three coordinates from your Two Factor Matrix. These three coordinates are randomly selected each time you sign on, so remember to keep your matrix secure and easily accessible. Well, the bank itself already compromised both the sign on ID and the matrix by sending them in an email. All that's left now is a password, which a nice phishing email giving the correct sign on ID might easily get. When questioned about this, the bank's response is that this scheme was designed by the people that design their web site and had passed their auditing. Of course, a compromise now would be entirely the user's fault -- another example of shifting the burden to the user while reducing the user's capacity to prevent a compromise. This illustrates that playing with two-factor authentication can make the system less secure than just username/password, while considerably reducing usability. A lose-lose for users. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On 2006-09-28, Leichter, Jerry wrote: VMS has for years had a simple CHECKSUM command, which had a variant, CHECKSUM/IMAGE, applicable only to executable image files. It knew enough about the syntax of executables to skip over irrelevant metadata like link date and time. (The checksums computed weren't cryptographic - at least the last time I used it, many years ago. The command was created to use in patches to provide a quick verification that the file being patched was the right one.) I've always found it surprising that no one seems to have developed similar tools for Unix - with the Gnu libraries for portable access to object/ executable files, it could be done relatively easily. This is incorrect. Hundreds of people have developed such tools and use them regularly. I've never bothered to look for any published versions, because my own tool works for me, but I'd be surprised if there weren't any out there in the wild. Greg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
