Phishers Defeat 2-Factor Auth
Full article at http: // blog.washingtonpost.com / securityfix / Citibank Phish Spoofs 2-Factor Authentication Security experts have long touted the need for financial Web sites to move beyond mere passwords and implement so-called two-factor authentication -- the second factor being something the user has in their physical possession like an access card -- as the answer to protecting customers from phishing attacks that use phony e-mails and bogus Web sites to trick users into forking over their personal and financial data. These methods work, however, only so long as the bad guys don't fake those as well. Take this latest phish, spotted by the people over at Secure Science Corp. It uses an impressively crafted Web-based e-mail that targets users of Citibank's Citibusiness service, which -- as its name suggests -- caters to businesses. Citibusiness also requires customers who want to log into their accounts online to use a supplied token in addition to their user name and password. The small device generates an additional password that changes every minute or so. The scam e-mail says someone (a nice touch added here -- the IP address of the imaginary suspect) has tried to to log in to your account and that you need to confirm your account info. Not a whole lot that's revolutionary there, but when you click on the link, you get a very convincing site that looks identical to the Citibusiness login page, complete with a longish Web address that at first glance appears to end in Citibank.com, but in fact ends at a Web site in Russia called Tufel-Club.ru. The site asks for your user name and password, as well as the token-generated key. If you visit the site and enter bogus information to test whether the site is legit -- a tactic used by some security-savvy people -- you might be fooled. That's because this site acts as the man in the middle -- it submits data provided by the user to the actual Citibusiness login site. If that data generates an error, so does the phishing site, thus making it look more real. Update, 4:41 p.m. ET: I forgot to mention that while this phishing site was active late last week and during the weekend, it has since been shut down. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NIST hash function design competition
Hal Finney wrote: I had not heard that there had been an official decision to hold a new competition for hash functions similar to AES. That is very exciting! The AES process was one of the most interesting events to have occured in the last few years in our field. Seemed like one of the lessons of that effort was that, even though it was successful in terms of attracting the interest and hard work of some of the top researchers in the field, in the end we have learned considerably more about Rijndael's vulnerabilities only after the process was over. My understanding is that no actual vulnerabilities have been found in Rijndael. What has been found are reasons to suspect that vulnerabilities will be found. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Call for Papers for the 4th VirtualGoods Workshop in Leeds
C A L L F O R P A P E R S The 4th International Workshop for Technology, Economy and Legal Aspects of Virtual Goods Organized by the GI Working Group ECOM and in parallel with IFIP Working Group 6.11 Communication Systems in Electronic Commerce December 13 -15, 2006 on AXMEDIS 2006 in Leeds, England http://VirtualGoods.tu-ilmenau.de - Full version: http://virtualgoods.tu-ilmenau.de/2006/cfp.html Topics of interest include, but are not restricted to, the following aspects: - * business models for virtual goods * incentive and community management for virtual goods * economic and legal aspects of virtual goods * infrastructure services for virtual goods businesses Important Dates: July 27, 2006 Full papers submitted August 25, 2006 Notification of acceptance September 2, 2006 Camera-ready papers due Technical Committee: Juergen Nuetzel: mailto:[EMAIL PROTECTED] Ruediger Grimm: mailto:[EMAIL PROTECTED] Please freely distribute this call for papers. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Factorization polynomially reducible to discrete log - known fact or not?
Charlie Kaufman wrote: I believe this has been known for a long time, though I have never seen the proof. I could imagine constructing one based on quadratic sieve. I believe that a proof that the discrete log problem is polynomially reducible to the factorization problem is much harder and more recent (as in sometime in the last 20 years). I've never seen that proof either. --Charlie OK, I had the proof checked. I put it here: http://www.ms.mff.cuni.cz/~miklo1am/Factorization_to_DLog.pdf Warning: it may be not what you'd expect. First of all, it reduces the factorization to a discrete log in a group of unknown order (or put in another words: you'd need to factorize to learn the group order). It has been proven by V. Shoup that when group operation and the inverse are the only operations that can be done with group elements, then the best algorithm can be O(sqrt(n)), where n is the number of elements. I guess then the group of Z_N* (where N=pq) of unknown order qualifies for this if we don't want to use factorization (actually you can't compute inverse group operation here). In the light of this fact, is this proof of any use? Even if the proof is not useful, is the generator picking lemma (lemma 2) anything new? It states basically this: In any cyclic group of order n there is at least 1/log2(n) probability of picking a generator randomly and thus generator can be found in polynomial time with overwhelming probability of success. The only facts close to this lemma I found were: 1) Product phi(p_i)/p_i for consecutive primes p_i approaches zero as more and factors are added to the product (phi is Euler phi function). The lemma states a lower bound for the product. 2) If the generalized Riemann hypothesis is true, then for every prime number p, there exists a primitive root modulo p that is less than 70 (ln(p))^2. (http://en.wikipedia.org/wiki/Primitive_root_modulo_n) Charlie: Thanks for answering my second question which I have not asked yet :-) (the reduction in opposite direction). I'm also working on the opposite reduction, but I'm at best halfway through (and not sure if I am able to finish it). Last question: Joseph Ashwood mentioned someone who claimed to have algorithm for factorization and had only the reduction to DLP. Anyone knows where I could find the algorithm? Or maybe name of the person, so I could search the web. Thanks O. Mikle - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Interesting bit of a quote
...from a round-table discussion on identity theft in the current Computerworld: IDGNS: What are the new threats that people aren't thinking about? CEO Dean Drako, Sana Security Inc.: There has been a market change over the last five-to-six years, primarily due to Sarbanes-Oxley. It used to be that you actually trusted your employees. What's changed -- and which is really kind of morally and socially depressing -- is that now, the way the auditors approach the problem, the way Sarbanes-Oxley approaches the problem, is you actually put in systems assuming that you can't trust anyone. Everything has to be double-signoff or a double-check in the process of how you organize all of the financials of the company -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
switching from SHA-1 to Tiger ?
Hal: Thanks for the news about the planned NIST-sponsored hash function competition. I'm glad to hear that it is in the works. Yesterday I profiled my on-line data backup application [1] and discovered that for certain operations one third of the time is spent in SHA-1. For that reason, I've been musing about the possibility of switching away from SHA-1. Not to SHA-256 or SHA-512, but to Tiger. The implementation of Tiger in Crypto++ on Opteron is more than twice as fast as SHA-1 and almost four times as fast as SHA-256 [2]. I hope that the hash function designers will be aware that hash functions are being used in more and more contexts outside of the traditional digital signatures and MACs. These new contexts include filesystems like ZFS [3], decentralized revision control systems like Monotone [4], git [5], mercurial [6] and bazaar-ng [7], and peer-to-peer file-sharing systems such as Direct Connect, Gnutella, and Bitzi [6]. The AES competition resulted in a block cipher that was faster as well as safer than the previous standards. I hope that the next generation of hash functions achieve something similar, because for my use cases speed in a hash function is more important than speed in encryption. By the way, the traditional practice of using a hash function as a component of a MAC should, in my humble opinion, be retired in favor of the Carter-Wegman alternative such as Poly-1305 AES [7]. Regards, Zooko [1] http://allmydata.com/ [2] http://www.eskimo.com/~weidai/amd64-benchmarks.html [3] http://www.opensolaris.org/os/community/zfs/ ZFS offers the option of performing a SHA-256 on every block of data on every access. The default setting is to use a non-cryptographic 256-bit checksum instead. [4] http://www.venge.net/monotone/ [5] http://git.or.cz/ [6] http://en.wikipedia.org/wiki/Tiger_(hash) [7] http://cr.yp.to/mac.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Phishers Defeat 2-Factor Auth
Lance James wrote: Full article at http: // blog.washingtonpost.com / securityfix / happen to mention more than a year ago ... that it would be subject to mitm-attacks ... recent comment on the subject http://www.garlic.com/~lynn/aadsm24.htm#33 Threatwatch - 2-factor tokens attacked by phishers. in thread in this mailing list more than year ago http://www.garlic.com/~lynn/aadsm19.htm#20 Citibank discloses private information to improve security http://www.garlic.com/~lynn/aadsm19.htm#21 Citibank discloses private information to improve security http://www.garlic.com/~lynn/aadsm19.htm#22 Citibank discloses private information to improve security http://www.garlic.com/~lynn/aadsm19.htm#23 Citibank discloses private information to improve security http://www.garlic.com/~lynn/aadsm19.htm#24 Citibank discloses private information to improve security ... and so on - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Phishers Defeat 2-Factor Auth
Yep, the phishers finally started doing it. If it becomes a threat to them, they will adapt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anne Lynn Wheeler Sent: Tuesday, July 11, 2006 10:39 AM To: cryptography@metzdowd.com Subject: Re: Phishers Defeat 2-Factor Auth Lance James wrote: Full article at http: // blog.washingtonpost.com / securityfix / happen to mention more than a year ago ... that it would be subject to mitm-attacks ... recent comment on the subject http://www.garlic.com/~lynn/aadsm24.htm#33 Threatwatch - 2-factor tokens attacked by phishers. in thread in this mailing list more than year ago http://www.garlic.com/~lynn/aadsm19.htm#20 Citibank discloses private information to improve security http://www.garlic.com/~lynn/aadsm19.htm#21 Citibank discloses private information to improve security http://www.garlic.com/~lynn/aadsm19.htm#22 Citibank discloses private information to improve security http://www.garlic.com/~lynn/aadsm19.htm#23 Citibank discloses private information to improve security http://www.garlic.com/~lynn/aadsm19.htm#24 Citibank discloses private information to improve security ... and so on - 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: Interesting bit of a quote
On Tue, Jul 11, 2006 at 01:02:27PM -0400, Leichter, Jerry wrote: [...] Business ultimately depends on trust. There's some study out there - I don't recall a reference - that basically finds that the level of trust is directly related to the level of economic success of an economy. There are costs associated with verification, some of them easily quantifiable, some of them much harder to pin down. The difficulty is in making the tradeoffs. We're now pushing way over on the verification side, in a natural reaction to a series of major frauds and scandals. Trust is not quite the opposite of security (in the sense of an action, not as a state of being), but certainly they're mutually exclusive. If you have trust, you have no need for security. Personally, given the choice, I'd rather have trust. I think that this is a distinction that could be made more often when deciding on how to implement a security system. -- - Adam ** Expert Technical Project and Business Management System Performance Analysis and Architecture ** [ http://www.adamfields.com ] [ http://www.aquick.org/blog ] Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.aquicki.com/wiki ].Wiki - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Interesting bit of a quote
Jerrold,
I can corroborate the quote in that much of SarbOx and
other recent regs very nearly have a guilty unless proven
innocent quality, that banks (especially) and others are
called upon to prove a negative: X {could,did} not happen.
California SB1386 roughly says the same thing: If you cannot
prove that personal information was not spilled, then you
have to act as if it was. About twenty states have followed
California's lead. The surveillance requirements of both
SEC imposed-regulation and NYSE self-regulation seem always
to expand. One of my (Verdasys) own customers failed a
SarbOx audit (by a big four accounting firm) because it
could not, in advance, *prove* that those who could change
the software (sysadmins) were unable in any way to change
the financial numbers and, in parallel, *prove* those who
could change the financial numbers (CFO reports) were
unable to change the software environment.
Jeffrey Ritter, partner in the electronic practice at
(big-name) D.C. law firm Kirkpatrick Lockhart gave the
major address at the annual meeting of the Cyber Security
Industry Alliance recently. In it he said that what he
and his firm tell their (big-name) clients is this:
* That which was not recorded did not happen.
* That which is not documented does not exist.
* That which has not been audited is vulnerable.
and he did not mean this in the paths to invisibility
sense but rather that you have liability unless you can
prove that you don't.
While one can say that this has always been true or that
the insider has always been the real threat, or whatever
variation you like, as a consultant for nearly two decades
the burgeoning prove a negative focus feels unprecedented
to me. And it is not just our field -- today's Boston
newspaper has the State of Massachusetts' building inspectors
being suspended en masse' for refusing en masse' to accept
GPS position tracking as a newly imposed job requirement.
By next summer, every animal in the country is supposed to
be chipped and the owner's home address recorded in GPS
form (google for NAIS) with a requirement to file with
USDA any off premises transportation (taking the kids'
heifer to the the 4H show included).
--dan
===
The great distinction:
A conservative is a socialist who worships order.
A liberal is a socialist who worships safety.
-- Victor Milan', 1999
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: switching from SHA-1 to Tiger ?
Zooko writes: By the way, the traditional practice of using a hash function as a component of a MAC should, in my humble opinion, be retired in favor of the Carter-Wegman alternative such as Poly-1305 AES [7]. This is a great topic where there are lots of pros and cons. The CW MACs like UMAC and Poly1305-AES have advantages including speed and provable security. However the recent result Perry cited by Bellare, http://eprint.iacr.org/2006/043, argues that HMAC relies only on the compression function being a PRF, and the CW MACs also need a PRF. So perhaps their security properties will not turn out to be so different. From the security implementor's POV, the speed of the CW MACs must be balanced against potentially greater difficulty in using them. They are not black-box drop-in replacements for HMAC. CW MACs rely on the presence of a unique nonce per message (and per key). This can be as simple as a sequence number, or perhaps a random string. But either one may require adding state and/or environmental access to what is a simple stateless function with HMAC. CW MACs also have the property that they may allow single brute-force forgeries to be easily extended to multiple forgeries. The ease or difficulty of this extension will depend on details of the MAC design, but in principle, the CW security properties allow for it. This means that MACs of moderate length, like 64 bits or less, need to be evaluated much more critically with a CW MAC implementation. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NIST hash function design competition
James Donald writes: My understanding is that no actual vulnerabilities have been found in Rijndael. What has been found are reasons to suspect that vulnerabilities will be found. Yes, I think that's correct on the theoretical side. I was also thinking of some of the implementation issues which have shown up, particularly timing and cache attacks. AES is proving to be difficult to immunize against these problems. A good discussion by Bernstein is presented in http://cr.yp.to/antiforgery/cachetiming-20050414.pdf, where he asks, regarding this AES issue, How did this happen?: : Was the National Institute of Standards and Technology unaware of : timing attacks during the development of AES? No. In its âReport on the : development of the Advanced Encryption Standard, NIST spent several pages : discussing side-channel attacks, specifically timing attacks and power : attacks. It explicitly considered the difficulty of defending various : operations against these attacks. For example, NIST stated in [19, : Section 5.1.5] that MARS was âdifficult to defend against these attacks. : : Did NIST decide, after evaluating timing attacks, that those attacks : were unimportant? No. Exactly the opposite occurred, as discussed below. : : So what went wrong? Answer: NIST failed to recognize that table lookups : do not take constant time. âTable lookup: not vulnerable to timing : attacks, NIST stated in [19, Section 3.6.2]. NIST's statement was, : and is, incorrect. : : NIST went on to consider the slowness of AES implementations designed : to protect against side-channel attacks. For example, NIST stated : that providing âsome defense for MARS meant âsevere performance : degradation. NIST stated in [19, Section 5.3.5] that Rijndael gained a : major speed advantage over its competitors when such protections are : considered. This statement was based directly on the incorrect notion : that table lookups take constant time. NIST made the same comment in : its summary assessments of the finalists, and again in its concluding : paragraph explaining the selection of Rijndael as AES. See [19, Section : 6.5] and [19, Section 7]. This is an example of a case where there doesn't seem to have been enough time during the AES process for people to notice this oversight. It probably didn't help that analysts had to spread their effort over five main candidates. Maybe it would be a good idea for NIST to add an extra phase where they announce their proposed finalist, and ask everyone to focus all their attention on potential weaknesses in this one function. Since this is exactly what will happen anyway immediately after the selection is made, it might make sense to build a buffer period into the process to let people take their final shots. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
