The PIN plus alternate channel process (e.g. cell phone text message) needs
to require a valid PIN _before_ generating the text message with the second
PIN for authentication. Otherwise, text spamming is possible. While this can
be limited to one spam per user, that could still add up to a lot of spam.
On 12/13/06, Wade Millican <WMillican at hutchison.com.au> wrote:
>> I agree with what Mark's said below.
>> I think complexity is being added from a user point of view, for little
> gained security. What are these new measures trying to secure against? As
> Mark as said, details are being added that a potential hacker can use to
> hijack an account (he's got account code, last name, dates, times, and
> memorable dates now).
>> Shoulder surfing is still at the same level of risk. The PIN protection
> from randomising the order and only use 3/4, would not combat
> spyware/trojan/rootkits. It may slow it down, but only for a max of 3 login
> attempts.
>> I'd like to comment on the previous logon date/time. I've seen this used
> a few times before, where it was actually effective. This should NOT be
> presented until AFTER a validated login.
>> I'm very happy to see the banks are actively working on their websites and
> security, but I do not think this is the answer.
>> I'd like to see more banks using one time passwords sent to the mobile
> number of the user on their DB(below)
>> 1)User hits login
> 2)Types in Acct number
> 3)user hits generate OTP (mobile number is linked to account details)
> 4)User gets SMS with OTP
> 5)User enters PIN + OTP
> 6) User logs in.
>> From a user PoV, it's 1 extra step, and adds 2+ layers of security. The
> only issues I can see with this is delayed messages, mobile roaming (a
> backup for of OTP is required). Anyone want to tear apart that? :P
>> Cheers,
> Wade
>> >>> "Mark Mcdonald" <mmcdonald at staff.iinet.net.au> 13/12/2006 6:28 pm >>>
> Where do we start...
>> Inputting the PIN digits and the 'significant date' gives potential
> phishers even more information about the victim they could use to phone the
> bank and go to town with.
>> Using randomly placed digits on a keypad prevents only a JS mouse-movement
> replay attack and allows anyone in the room to see what's being entered.
>> The last three digits & the date of last login sound like information you
> need when you call up the bank and can't provide your password. Putting
> them on a web page exposes a little too much information I think,
> particularly when you only need a (potentially cached) login number and the
> persons surname, although it may make phishing slightly harder.
>> It looks like they're trying to close one door but inadvertently opening
> more. I'd like to see commentary from the experts around here though...
>> Cheers
> Mark
>> > -----Original Message-----
> > From: Gervase Markham
> > Subject: [WEB SECURITY] New two-stage login procedure
> >
> > A financial institution with which I have connections has just come up
> > with this:
> > http://www.ingdirect.co.uk/email/capig2/animate.gif> >
> > Leaving aside the inaccessibility of their chosen method of demoing,
> > what do people think?
> >
> > Gerv
> >
> >
> --------------------------------------------------------------------------
> > --
> > The Web Security Mailing List:
> > http://www.webappsec.org/lists/websecurity/> >
> > The Web Security Mailing List Archives:
> > http://www.webappsec.org/lists/websecurity/archive/> > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>> This e-mail message (including any attachment) is intended only for the
> personal use of the recipient(s) named above. This message is confidential
> and may be legally privileged. Any review, retransmission, dissemination or
> other use of, or taking any action in reliance on, this communication by
> persons or entities other than the intended recipient is prohibited. If you
> have received this communication in error, please notify us immediately by
> e-mail and delete the original message.
>> Neither Hutchison 3G Australia Pty Limited (H3GA) nor Hutchison
> Telecommunications (Australia) Limited (HTAL) make any express or implied
> representation or warranty that this electronic communication or any
> attachment is free from computer viruses or other defects or conditions
> which could damage or interfere with the recipient's data, hardware or
> software. This communication and any attachment may have been modified or
> otherwise interfered with in the course of transmission.
>> The message represents the views and opinions of the author and under no
> circumstances represent those of H3GA, HTAL or its Group Companies. The
> shareholders, directors and management of H3GA and HTAL and its Group
> Companies accept no responsibility and accordingly shall have no liability
> to any party whatsoever in respect to the contents of this message.
>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20061213/298ac4b7/attachment.html>