Patent buster for a method that increases password security

Dear all reading professional (as described in patent regulations),

This time, I write to you to in order to make sure that you aware of a
simple method that can be used in increasing the password security
within networked computer environment. This method is so simple that
you probably have already read about it, but let's just make sure that
third party instances will not be granted patents for this obvious and
only slightly innovative method.

Field of invention:
^^^^^^^^^^^^^^
Telecommunication systems, where a user is required to insert a
password in order to be able to use, one or more, access restricted
resources.

Problem with existing technologies:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
According to Reuters 2006-12-02 news: United Nations IT branch ITU
requested a technological solution for a problems caused by repeated
use of a same password.
<Snip>
The International Telecommunication Union, a Geneva-based U.N.
branch, said businesses and regulators need to find a solution to the
spread of personal information on the Internet, possibly by developing
more streamlined identification methods.

At the moment, the ITU said the sheer number of identifiers and
passwords required from computer users made it nearly inevitable that
they repeat codes.

"This may cause security breaches, and leave them vulnerable to the
machinations of identity thieves ever increasing in number and
inventiveness," it said in its 2006 Internet report, released ahead of
a major meeting of governments and industry officials in Hong Kong.

"The lack of coordination in identification systems is a source of
growing inconvenience to users and needs to be addressed rapidly," it
said.
</snip>
http://today.reuters.co.uk/news/arti...c=HP-C7-Tech-3
(Short-cut address): http://tinyurl.com/yfngcl

Solution that is provided by this Patent Buster:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Many of the problems associated with the repeated usage of same
passwords can be circumvented by manufacturing, (in practical terms)
unique versions of user-inserted password for each target online
reseurce or location. Ultimately user's computer system will not send
the original (raw) user inserted password to target online location,
but rather sends a (raw-)password derived (hash-)password to each
online location. Alternatively, user's computer system could send to
the online location a password string, which would be derived from a
mixture of portions of original (raw) and derived (hash) passwords.
Manufacturing of the unique (hash-)passwords could be achieved,
for example, by combining into a single text-string:
a) the user inserted (raw-)password and
b) the target resource's URL or domain name

A cryptographically secure (one way) - hash algorithm could then be
used in calculating a unique (hash-)password for the password+address
combination string. Alternatively a unique (hash-) password could be
made using by encrypting a password+address combination string with a
symmetric encryption algorithm. For example, Internet browser software
could automatically convert the user inserted (raw-)passwords into
(hash-)passwords, and send those generated (hash-)passwords to online
resource when the user presses submit-buton

Benefits of shown technology:
^^^^^^^^^^^^^^^^^^^^^^^^
According to described invention the user's computer system would
not send to original user inserted (raw-) password to online
locations, but would send a (hash-) password string that would differ
uniquely, at least, based on the online address of target location.
Thus, the ones who could obtain user's (hash-) password from a certain
online location, could not misuse the password on other online
resources where the user might be using a same (raw-) password; e.g.
accounts like e-mail, ebay, Skype, banks, Paypal etc.


Kind regards,
Juuso Hukkanen

Juuso Hukkanen <juuso_12_2003@tele3d.net> writes:
> A cryptographically secure (one way) - hash algorithm could then be
> used in calculating a unique (hash-)password for the password+address
> combination string. Alternatively a unique (hash-) password could be
> made using by encrypting a password+address combination string with a
> symmetric encryption algorithm. For example, Internet browser software
> could automatically convert the user inserted (raw-)passwords into
> (hash-)passwords, and send those generated (hash-)passwords to online
> resource when the user presses submit-buton

similar hash strategies in OTP, RFC 2289 ... post discussing rfc 2289
http://www.garlic.com/~lynn/2006u.html#4 ssh - password control or key control?

RFC 2289 includes a server specific salt/value ... so that the same
password could be used with multiple different servers.

note however that in RFC 2289 ... it also includes countermeasure to
static data replay attack ... i.e. if the "same" hash value is always
used to connect to the same system ... then in effect the hash value
becomes the (static data) password, can be evesdropped and replayed.

the server doesn't know whether the user entered a password which was
hash and then transmitted ... or that an attacker evesdropped an
transmitted hash ... and replayed the (evesdropped) hash.

note that in the above referenced post, RFC 2289 claims to be
countermeasure to purely passive, evesdropping attacks (as well a
end-user to utilize a static value password across multiple different
servers) ... but is not resistant to active and/or man-in-the-middle
attacks.

recent posts about shared secret authentication, static data
authentication vulnerabilities, etc.
http://www.garlic.com/~lynn/2006v.html#29 User Authentication
http://www.garlic.com/~lynn/2006v.html#33 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#39 On sci.crypt: New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#42 On sci.crypt: New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#44 User Authentication
http://www.garlic.com/~lynn/2006v.html#45 On sci.crypt: New attacks on the financial PIN processing

On Mon, 4 Dec 2006 17:50:46 +0100, Sebastian Gottschalk
<seppi@seppig.de> wrote:

>That's both prior art and non-working. Hint: What happens when the URL
>changes?

Address changes can be managed:
a) If the hash-password uses a site name (major sites rarely abandon
their domain names; ebay.com, hotmail.com, google.com are forever)
-->But if e.g., two companies merge and change name they could
continue somehow maintain their login- forms at those 'old' domains OR
--> They could gradually ask users to change passwords and store &use
both old and new site passwords during the transition, no-collisions
will occur with hashes anyway.

b) If the exact resource URL is to be used as the password's
determinator and it suddenly need to be changed,
-->The site could still simulate the older location e.g. by
downloading the login screen into a web-page's frame from the usual
location
--> Site can gradually ask users to change passwords and store & use
both old and new site URLs during the transition

Juuso

Juuso Hukkanen <juuso_12_2003@tele3d.net> writes:

>On Mon, 4 Dec 2006 17:50:46 +0100, Sebastian Gottschalk
><seppi@seppig.de> wrote:

>>That's both prior art and non-working. Hint: What happens when the URL
>>changes?

>Address changes can be managed:
> a) If the hash-password uses a site name (major sites rarely abandon
>their domain names; ebay.com, hotmail.com, google.com are forever)
>-->But if e.g., two companies merge and change name they could
>continue somehow maintain their login- forms at those 'old' domains OR
>--> They could gradually ask users to change passwords and store &use
>both old and new site passwords during the transition, no-collisions
>will occur with hashes anyway.

Bad idea. Passwords are NOT stored on the receiving end. Passwords should
NOT be known by anyone but the user. It should not be possible to attack
the server and discover the passwords -- this has been known for at least
30 years now. Thus it is impossible for the server to "use both" They have
no idea what the old password was, just its hash and they certainly better
not have any way of using that information to find the hash of the new
password.



> b) If the exact resource URL is to be used as the password's
>determinator and it suddenly need to be changed,
>-->The site could still simulate the older location e.g. by
>downloading the login screen into a web-page's frame from the usual
>location

No it could not-- that is not how passwords work-- or urls.

The more usual way of handling your requirements is a challenge response
system. The server sends a challenge, the user responds with the challenge
plus the password. One problem is that this in the most naive cases
requires the server to store the plaintext password, a bad idea.

But see SRP for a challenge response system which both provides secure
identification, does not allow an attacker either of the traffic or of the
server to discover the password.

Note that your scheme does absolutely nothing for an attacker who discovers
the user's password on one system ( eg by setting up a fake system onto
which he asks users to insert a password and then uses that password on
other systems the user users) and reuses it on others. YOur concern was
reuse of passwords. Your scheme does nothing to actually solve that
concern since the additions to the password used by each site are
deterministic (ie determined by the site), and thus are not secret in any
sense. A known thing plus a secret thing is no more secure than the secret
itself.



>--> Site can gradually ask users to change passwords and store & use
>both old and new site URLs during the transition


>Juuso

On Mon, 04 Dec 2006 10:02:33 -0700, Anne & Lynn Wheeler
<lynn@garlic.com> wrote:

>RFC 2289 claims to be
>countermeasure to purely passive, evesdropping attacks (as well a
>end-user to utilize a static value password across multiple different
>servers) ... but is not resistant to active and/or man-in-the-middle
>attacks.

Offcause that my brief 'patent buster' leaves all possibilities for
snooping etc. and much advanced methods SSH, https & co. should be
used instead. However lots of site logins still travel embedded as
plaintext into URL requests and such logins are used by automated
scripts. Ok, all such are bad... but real and practical.
About the only two advantage's with shown simple single-shot
logins, are that such a) allow a single-shot login b) doesn't tell
(potentially multiused) password to the to target site.
Ok, it appears possible to use the target address as part of
manipulating the password, perhaps in combination with other
techniques. Anyway I dont want someone to block that route with one of
those obvious patents.
I didn't know about the RFC, and maybe the ITU didn't either since
they asked technological solutions for problems caused by repeated
misuse of the same password. So, not it is up to M$ & firefox people
to put the RFC in action and almost all online password worries become
distant history :)

Juuso

Juuso Hukkanen <juuso_12_2003@tele3d.net> writes:

>On Mon, 04 Dec 2006 10:02:33 -0700, Anne & Lynn Wheeler
><lynn@garlic.com> wrote:

>>RFC 2289 claims to be
>>countermeasure to purely passive, evesdropping attacks (as well a
>>end-user to utilize a static value password across multiple different
>>servers) ... but is not resistant to active and/or man-in-the-middle
>>attacks.

>Offcause that my brief 'patent buster' leaves all possibilities for
>snooping etc. and much advanced methods SSH, https & co. should be
>used instead. However lots of site logins still travel embedded as
>plaintext into URL requests and such logins are used by automated
>scripts. Ok, all such are bad... but real and practical.

You are saying "Change your broken system and use my system instead". But
if they are changing already why not change to a system that is not broken
at all and gives strong authentication? Ie, your system falls between two
stools. It means that the people using it have to change anyway, but it
gives a system which is weak as a reward for all that work.


> About the only two advantage's with shown simple single-shot
>logins, are that such a) allow a single-shot login b) doesn't tell
>(potentially multiused) password to the to target site.
>Ok, it appears possible to use the target address as part of
>manipulating the password, perhaps in combination with other
>techniques. Anyway I dont want someone to block that route with one of
>those obvious patents.

Your posting will not stop that. If the patent office grants a patent for
such an obvious system, the fact that you have published it on newsnet will
not stop them.


> I didn't know about the RFC, and maybe the ITU didn't either since
>they asked technological solutions for problems caused by repeated
>misuse of the same password. So, not it is up to M$ & firefox people
>to put the RFC in action and almost all online password worries become
>distant history :)

It is not up to firefox. They have nothing to do with it. It may well be up
to MS, but then then are not know for caring about security of anything. If
they did there are loads of solutions out there already.


>Juuso

On 4 Dec 2006 18:29:46 GMT, Unruh <unruh-spam@physics.ubc.ca> wrote:

>Juuso Hukkanen <juuso_12_2003@tele3d.net> writes:
>
>>On Mon, 4 Dec 2006 17:50:46 +0100, Sebastian Gottschalk
>><seppi@seppig.de> wrote:
>
>>>That's both prior art and non-working. Hint: What happens when the URL
>>>changes?
>
>>Address changes can be managed:
>> a) If the hash-password uses a site name (major sites rarely abandon
>>their domain names; ebay.com, hotmail.com, google.com are forever)
>>-->But if e.g., two companies merge and change name they could
>>continue somehow maintain their login- forms at those 'old' domains OR
>>--> They could gradually ask users to change passwords and store &use
>>both old and new site passwords during the transition, no-collisions
>>will occur with hashes anyway.
>
>Bad idea. Passwords are NOT stored on the receiving end. Passwords should
>NOT be known by anyone but the user.

I am saying the same! see the part: "If the hash-password... "

so. I suggest a simple extra routine for encrypting the passwords
uniquely for each site; By automatically making a hash of a (site-name
& user-inserted password). Of cause that alone is vulnerable to all
forms of eavesdropping, in combination with other things could be
beneficial.

>the server and discover the passwords -- this has been known for at least
>30 years now. Thus it is impossible for the server to "use both" They have
>no idea what the old password was, just its hash and they certainly better
>not have any way of using that information to find the hash of the new
>password.

Almost there Dr. Unruh, I am NOT saying the site should know the
passwords, but as an answer to Sebastian's challenge, I provided a
working solution i.e. username and storing two hashes temporarely
1) USERNAME
2) an old SHA string made by combining a string of REAL
password&siteaddress => the site does not get the REAL password)
3) an new SHA string made by combining a string of REAL
password&siteaddress => the site does not get the REAL password

So, with the (rare) site name change event, they could use a database
like
"UNRUH","45b34545b2344",35a2d243453cv";

thus, If the first (old) pass-hass would not work the second (new)
could be tested

> YOur concern was reuse of passwords.

RIGHT!

>Your scheme does nothing to actually solve that
>concern since the additions to the password used by each site are
>deterministic (ie determined by the site),

NOT, ARGH! be my quest and find the secret_reused_pass from SHA512
strings:

1. "secret_reused_pass:google.com" SHA-512 hash for google com
463e9793bece1797243d3f36d97b353f547d6381a63dd10ae4 db529f46c8ae8a4debe91e488bf98b
15d7528cc9dada960f83951d746687a12483cafb94e403da

2. "secret_reused_pass:hotmail.com" SHA-512 hash for hotmail.com
d95eb347dff09350433b75e2bb254f0b3dc73589052ff0a200 fe1ee2d49f41d73dda8605cc3262cd
55543fdf14daa667bf6ce02aa74c3e5c091b44c1efab41bb

<--> site will never get real passes, nor the hackers that attack site

Scheme, what scheme, the patent buster is a fragment that could be
made a part of some scheme. I even used as abstracts terms as possible
to make it better serve its purpose as a 'patent buster' for partially
solving a problem that ITU asked for a technical solution.

Juuso

Juuso Hukkanen <juuso_12_2003@tele3d.net> writes:

>On 4 Dec 2006 18:29:46 GMT, Unruh <unruh-spam@physics.ubc.ca> wrote:

>>Juuso Hukkanen <juuso_12_2003@tele3d.net> writes:
>>
>>>On Mon, 4 Dec 2006 17:50:46 +0100, Sebastian Gottschalk
>>><seppi@seppig.de> wrote:
>>
>>>>That's both prior art and non-working. Hint: What happens when the URL
>>>>changes?
>>
>>>Address changes can be managed:
>>> a) If the hash-password uses a site name (major sites rarely abandon
>>>their domain names; ebay.com, hotmail.com, google.com are forever)
>>>-->But if e.g., two companies merge and change name they could
>>>continue somehow maintain their login- forms at those 'old' domains OR
>>>--> They could gradually ask users to change passwords and store &use
>>>both old and new site passwords during the transition, no-collisions
>>>will occur with hashes anyway.
>>
>>Bad idea. Passwords are NOT stored on the receiving end. Passwords should
>>NOT be known by anyone but the user.

>I am saying the same! see the part: "If the hash-password... "

>so. I suggest a simple extra routine for encrypting the passwords
>uniquely for each site; By automatically making a hash of a (site-name
>& user-inserted password). Of cause that alone is vulnerable to all
>forms of eavesdropping, in combination with other things could be
>beneficial.

>>the server and discover the passwords -- this has been known for at least
>>30 years now. Thus it is impossible for the server to "use both" They have
>>no idea what the old password was, just its hash and they certainly better
>>not have any way of using that information to find the hash of the new
>>password.

>Almost there Dr. Unruh, I am NOT saying the site should know the
>passwords, but as an answer to Sebastian's challenge, I provided a
>working solution i.e. username and storing two hashes temporarely
>1) USERNAME
>2) an old SHA string made by combining a string of REAL
>password&siteaddress => the site does not get the REAL password)
>3) an new SHA string made by combining a string of REAL
>password&siteaddress => the site does not get the REAL password

But they do NOT know the password and thus do not know how to create the
new string from the old one. If they have enough information on their
system to create the new hash from the old one then they are vulnerable to
a server attack. And furthermore, if the attacker finds the password on one
system, he can by exactly that same process create the password for any
other system.

Ie, this procedure does not get around the problem that if the user's
password on one system gets discovered, then the attacker can use that same
password on any other system. The only hidden data the user has is his
password. Once that hidden data is known the attaker can fake the user on
any other system where the user uses the same password.
The attack you were trying toprotect against is the user reusing his
password on many systems. This does not solve that problem because the
password on any system is an algorithmic combination of that secret plus
known material about the system being logged onto.



>So, with the (rare) site name change event, they could use a database
>like
>"UNRUH","45b34545b2344",35a2d243453cv";

>thus, If the first (old) pass-hass would not work the second (new)
>could be tested

>> YOur concern was reuse of passwords.

>RIGHT!

>>Your scheme does nothing to actually solve that
>>concern since the additions to the password used by each site are
>>deterministic (ie determined by the site),

>NOT, ARGH! be my quest and find the secret_reused_pass from SHA512
>strings:

That is NOT the problem. The problem is that the system must create that
hash from the user's data, which includes the secret.



>1. "secret_reused_pass:google.com" SHA-512 hash for google com
>463e9793bece1797243d3f36d97b353f547d6381a63dd10ae 4db529f46c8ae8a4debe91e488bf98b
>15d7528cc9dada960f83951d746687a12483cafb94e403d a

>2. "secret_reused_pass:hotmail.com" SHA-512 hash for hotmail.com
>d95eb347dff09350433b75e2bb254f0b3dc73589052ff0a20 0fe1ee2d49f41d73dda8605cc3262cd
>55543fdf14daa667bf6ce02aa74c3e5c091b44c1efab41b b

><--> site will never get real passes, nor the hackers that attack site

Then how can a site store the hash for the new and for the old names in the
database? How can they figure out what the new one should be?



>Scheme, what scheme, the patent buster is a fragment that could be
>made a part of some scheme. I even used as abstracts terms as possible
>to make it better serve its purpose as a 'patent buster' for partially
>solving a problem that ITU asked for a technical solution.

Use SRP instead.



>Juuso

On 4 Dec 2006 19:12:36 GMT, Unruh <unruh-spam@physics.ubc.ca> wrote:


>>Offcause that my brief 'patent buster' leaves all possibilities for
>>snooping etc. and much advanced methods SSH, https & co. should be
>>used instead. However lots of site logins still travel embedded as
>>plaintext into URL requests and such logins are used by automated
>>scripts. Ok, all such are bad... but real and practical.
>
>You are saying "Change your broken system and use my system instead".

No, but some future standard could contain a small fragment that uses
a 'target-URL as part of forcing uniqueness to the passwords', then go
ahead use it freely.

The reason for this Patent Buster is that there are known cases where
too simple character trix have been patented and are causing REAL
harm.

e.g.
<snip>
The suit accuses Network Solutions and Register.com of selling rights
to Web URLs and e-mail addresses that infringe on a patent that was
granted to Javaher and Weyer on Dec. 30, 2003. The patent covers the
method of assigning URLs and e-mail addresses of members of a group
such that the "@" sign is the dot in the URL. For example, if a group
used a so-called third-level URL, www.john.smith.com, the e-mail
address would be john@smith.com.
</snip>

http://news.com.com/2100-1038-5141810.html

Currently espacenet patent database had 528 patents with an URL in
their title of which most are likely somehow too obvious. A couple of
years age there were writings of a case where a character encoding
patent unabled simulating scandinavian letters (åäöÅÄÖ) in of browsers
URL address-line or something equally intelligent.

>if they are changing already why not change to a system that is not broken
>at all and gives strong authentication? Ie, your system falls between two
>stools. It means that the people using it have to change anyway, but it
>gives a system which is weak as a reward for all that work.

Yes, and all mail should be encrypted by now with PKI and there should
not be un-canned spam because all receiving mail-servers should be
requiring a small postage payment or forcing the sender to perform
some time-consuming calculation. Yes, in ideal world things always
happen completely and rapidly.

>>techniques. Anyway I dont want someone to block that route with one of
>>those obvious patents.

>Your posting will not stop that. If the patent office grants a patent for
>such an obvious system, the fact that you have published it on newsnet will
>not stop them.

Perhaps not, but if they would be suing anyone, the 'offer' would
guite likely be Googling for something like:

password hash url "domain-name" patent

well, first answer to that query in google groups is this patent
buster thread. And this thread certainly can be used as prior art.

<very OT>
Because patents exists for creating technological monopolies, I think
those who do not like unwarranted monopolies (especially these stupid
software patents) should fight the patents with a massive prior-art
database. Where people could write technological descriptions (perhaps
using their native languages), which would create a situation where
there would be a maybe millions of IT- solutions listed and nobody
would be able to check (understand all languages) if a certain system
is there listed. So when a certain patent would start to cause
problems ( like JPG,RSA,MPEG4,GIF,MP3, Amazon one-click shopping),
then suddenly the pad patents could go away. And since the value of
stupid software-patens would be lower, there might be less than 528
patents with word URL in their title. But offcause the political
limitation (e.g. max time to 5 years) of software patents would be
much more effective.
</very OT>

Juuso

Juuso Hukkanen <juuso_12_2003@tele3d.net> writes:
> Yes, and all mail should be encrypted by now with PKI and there should
> not be un-canned spam because all receiving mail-servers should be
> requiring a small postage payment or forcing the sender to perform
> some time-consuming calculation. Yes, in ideal world things always
> happen completely and rapidly.

ref:
http://www.garlic.com/~lynn/2006v.html#46 Patent buster for a method that increases password security

<very old topic>

part of the issue with certification authorities and PKI is that they
tended to want money for what they did. another part was that they
wanted to demonstrate some value in the digital certificate they
produced. some of this from the early 90s was overloading x.509
identity certificates with personal information. by the mid-90s, it
was starting to be realized that x.509 identity certificates, heavily
overloaded with personal information represented significant liability
and privacy issues. as a result, in the mid-90s you started to see
some number of relying-party-only digital certificates ... just
containing a public key and some account/record indicator ... lots
of past posts mentioning relying-party-only digital certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

however, if you are doing real-time lookup in a repository for either
information that previously and been in a digital certificate and/or
any permission and/or authorization information ... then it was
trivial to demonstrate that the digital certificate was redundant and
superfluous.

the situation was then there was a big expensive (redundant and
superfluous) PKI and digital certificate infrastructure that provided
no added value.

an example was the original pk-init extension to Kerberos called for
just replacing registration of a password with a public key. lots of
past posts mentioning kerberos and/or pk-init
http://www.garlic.com/~lynn/subpubkey.html#kerberos

where the onfile public key was used to validate the digital
signature (in lieu of comparing passwords). lots of past posts
mentioning certificateless mode of operation
http://www.garlic.com/~lynn/subpubkey.html#certless

however, there was a lot of pressure to also added PKI mode of
operation to the pk-init specification.

now, might be able to justify the cost of a big expensive PKI
operation if you could eliminate any repository lookup as part of
authentication ... i.e. all information (all identification along with
all persmissions and all real time authorization) was carried in the
stale, static digital certificate. However, if you need to have both a
digital certificate AND a real-time respository access ... then,
again, it is trivial to show that the PKI part is redundant and
superfluous ... just carry the registered public key in the repository
(along with all the other account/individual information).

possibly the two dominant authentication infrastructures in the
internet world are kerberos and radius. a similar change to radius can
be done with registering public keys (in lieu of passwords) and
performing digital signature verification with onfile public keys
w/o needed to deploy a separate, expensive, redundant and superfluous
PKI infrastructure. misc. past posts mentioning radius public key
operation
http://www.garlic.com/~lynn/subpubkey.html#radius

</very old topic>

part of the previous refs talk about dangers of session authentication
vis-a-vis transaction authentication
http://www.garlic.com/~lynn/2006v.html#45 User Authentication
http://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions

<very old topic>

we were called into consult with this small client/server startup
that wanted to do financial transaction transactions on their server
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

they had this technology called SSL that was targeted at "protecting"
the financial transaction. Basically SSL was targeted at
1) countermeasure to man-in-the-middle attacks and
2) hiding the account number.

however, at the time this was starting ... one of the major vulnerabilities
was account number harvesting by insiders

and "insiders" threats:
http://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing

and more "insider" threats:

Study: ID theft usually an inside job
http://www.garlic.com/~lynn/aadsm17.htm#38
Leading Cause of Data Security breaches Are Due to Insiders
http://www.garlic.com/~lynn/aadsm18.htm#49
Bank workers biggest ID theft threat
http://www.garlic.com/~lynn/2005l.html#35
other insider threat
http://www.garlic.com/~lynn/2006p.html#9

now SSL #2 didn't affect this class of harvesting threats. lots of
past posts about skimming/harvesting static data for replay attacks
http://www.garlic.com/~lynn/subintegrity.html#harvest

modulo that the resulting e-commerce created a large number of new
transaction logs that had additional vulnerabilities ... in part
it drastically reduced the cost of setting up a business ... and this
business possibly had less money to spend on transaction log security
.... old post about security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

as to SSL #1, the countermeasure to man-in-the-middle attack was
predicated on the user typing in a URL ... the browser contacts the
server, the server returns a ssl domain name certificate ... which the
browser verifies and then matches the typed in URL against the domain
name in the server provided ssl domain name certificate.

however, most merchant websites quickly found that using SSL for the
whole shopping experience, cut their thruput by 80-90 percent. as a
result the industry shifted to just using SSL for the
check-out/payment part of the operation.

Now the merchant supplies a check-out/payment button that provides the
URL to checkout. Now instead of browser checking the domain name
certificate against the URL information provided by the user ... the
browser is checking the server supplied domain name certificate
against the server provided URL (and it probably takes a pretty dumb
man-in-the-middle attack to supply a URL that is different than the
domain name certificate that it was supplying).

lots of past posts about ssl domain name certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

</very old topic>

part of the issue is it doesn't do much good to have a huge,
complicated expensive additional business processes that actually
provides little or no added value.

<very old topic>

so the x9a10 financial standard working group was given the requirement to
preserve the integrity of the financial infrastructure for all retail
payments. the result was x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

now from security PAIN acronym

P ... privacy (sometimes CAIN ... confidentiality)
A ... authentication
I ... integrity
N ... non-repudiation

SSL was being used to hide the account number, achieving security via
privacy/confidentiality.

however, there is quite opposing requirements. since knowledge of the
account number can be sufficient to perform a fraudulent transaction,
the account number has to be kept hidden and never divulged. at the
same time, the account number is required for a large number of
different business processes ... and as a result has to be readily
available. this led to my frequently repeated observation that the
planet could be buried under miles of encryption and still not prevent
account number leakage.

so what x9.59 financial standard did was require strong authentication
and integrity for every transaction ... and a business rule that
account numbers used in x9.59 could not be used in non-authenticated
transactions. basically just knowing an account number was no longer
sufficient to perform a fraudulent transaction ... and so it was no
longer necessary to constantly keep the account number hidden; i.e.
authentication and integrity replaced privacy to achieve security.
x9.59 did nothing to prevent skimming/harvesting transactions ... but
eliminated the risk/fraud associated with attacker (or insider)
skimming/harvesting.

</ver old topic>

On 4 Dec 2006 20:51:35 GMT, Unruh <unruh-spam@physics.ubc.ca> wrote:


>>Almost there Dr. Unruh, I am NOT saying the site should know the
>>passwords, but as an answer to Sebastian's challenge, I provided a
>>working solution i.e. username and storing two hashes temporarely
>>1) USERNAME
>>2) an old SHA string made by combining a string of REAL
>>password&siteaddress => the site does not get the REAL password)
>>3) an new SHA string made by combining a string of REAL
>>password&siteaddress => the site does not get the REAL password

>But they do NOT know the password and thus do not know how to create the
>new string from the old one.

C'mon, I don't have the details how it would happen in all practical
steps, but one thing is certain _ he target server would not 'create
new string from the old one.' _ Therefore some kind of interactivity
would be needed, e.g. when user is logged in with old pass-hash using
the old familiar pass-hash, then the server could just ask to
re-insert the password due to recent "server system changes". That
re-login when already inside a system could be targeted to occur for
that 'new' login URL. --> the system gets the new pass-hash from the
user.
And later when a user would come to new login-URL, the site
database could contain both of those pass-hashes and could allow login
using that address. If the username would be regognized right but
password wrong the user could be directed to that previous login
address there the site has a working pass-hash.

Ofcause it would be better not to send pass-hashes at all, but
rather to use teh pass-hass only locally for making the answer for
server required (hash-on-hash-pass) tasks. If true securit is required
ofcause all those real systems are much better, but the reality is
that people are using same passwords to access unencrypted access to
porn sites as to their company e-mail systems. Using this method the
porn site admin would get a (unwrappable) login pass-hash that would
be unusable as a password e.g. for truing to access that users
SSH-protected e-mail system.

>If they have enough information on their
>system to create the new hash from the old one then they are vulnerable to
>a server attack. And furthermore, if the attacker finds the password on one
>system, he can by exactly that same process create the password for any
>other system.

The method alone would not be secure (against any evesdropping derived
methods) but it could create _on user's_ side unbrakable one-way hash
(for secret_pass&URL- string) from a single multiused password.
and the receiving sites would never see the REAL(qwerty) password or
they could never quess the REAL (qwerty) password based on the
hash(es) they have. And that pass-hash that would be on the site's
database would be useless for hackers, since the client would make a
different hash for every single URL where login occurs.

In order to make a sceme which would be resistent for evesdropping
derived methods, more server-client interactivity would be needed to
be inserted. In such cases the SHA(pass+URL) would just be used in
encrypting / responding the server send challenge-task.


>Ie, this procedure does not get around the problem that if the user's
>password on one system gets discovered, then the attacker can use that same
>password on any other system. The only hidden data the user has is his
>password. Once that hidden data is known the attaker can fake the user on
>any other system where the user uses the same password.
>The attack you were trying toprotect against is the user reusing his
>password on many systems. This does not solve that problem because the
>password on any system is an algorithmic combination of that secret plus
>known material about the system being logged onto.

Please, I am sure you are not suggesting that One-way hash could be
somehow unwrapped if you know the half of the plaintext that was
hashed e.g.

hash-pass= SHA512(QWERTY_MY_SECRETPASS:www.hotmail.com)

so if I send hash-pass over the internet it can be used as a login on
just one URL i.e. www.hotmail.com


If the pass-URL was part of a schema that could resist eavesdropping,
some kind of PKI would be needed. like in SRP

>Use SRP instead.

Well, rather the purpose of this thread was to allow e.g. the makers
of SPR to use passwords that are unique to target URL.

Juuso

On Mon, 04 Dec 2006 14:33:30 -0700, Anne & Lynn Wheeler
<lynn@garlic.com> wrote:

Thank you; there was a lot of interesting background and practical
information for online authentication. You know, Google might any time
soon be making an offer of you for their soon to be released service:
Google ComputerSecuritySence. It would work like AdSence but when ever
a Googler could be sensed to have a computer security related
problem,... no broblem, Google's box would fetch relevant articles
from your archives.

I am hopeful that Bill Unruh & Sebastian will wake up in the middle of
the night and suddenly see the light and say "wow that transparent,
simple browser driven method actually works... and it would not
require any changes to online sites... and it would prevent users from
submitting their important passwords to any porn/forum - sites" :)

Kind Regards
Juuso

Juuso Hukkanen <juuso_12_2003@tele3d.net> writes:
> Thank you; there was a lot of interesting background and practical
> information for online authentication. You know, Google might any time
> soon be making an offer of you for their soon to be released service:
> Google ComputerSecuritySence. It would work like AdSence but when ever
> a Googler could be sensed to have a computer security related
> problem,... no broblem, Google's box would fetch relevant articles
> from your archives.

re:
http://www.garlic.com/~lynn/2006v.html#46 Patent buster for a method that increases password security
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security

<lots of topic drift>

as i've mentioned a number of times before ... the top 8-10 search
engine web crawlers appear to use my pages as a regression test based
on their high number of hits everyday. i've assumed it is because
the extremely high ratio of hrefs per file ... especially in the
ietf rfc index
http://www.garlic.com/~lynn/rfcietff.htm

and the merged taxonomy and glossaries
http://www.garlic.com/~lynn/index.html#glosnote

the merged security taxonomy and glossary has significant
ratio of hrefs per mbytes ... but the merged financial
taxonomy and glossary has over 35000 hrefs in about 3.5mbytes
(avg. 10,000 hrefs per mbyte).

recent reference about some of the work
http://www.garlic.com/~lynn/2006v.html#47 why so little parallelism
http://www.garlic.com/~lynn/2006v.html#48 why so little parallelism

some other computer trivia ... gml markup langauge (precursor
to sgml, html, xml, etc)
http://www.garlic.com/~lynn/subtopic.html#sgml

was invented by "g", "m", and "l" at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

in 1969. shortly after that, gml processing was added to the
cms script document processor.

</lots of topic drift>

Anne & Lynn Wheeler <lynn@garlic.com> writes:
> <lots of topic drift>
> some other computer trivia ... gml markup langauge (precursor
> to sgml, html, xml, etc)
> http://www.garlic.com/~lynn/subtopic.html#sgml
>
> was invented by "g", "m", and "l" at the science center
> http://www.garlic.com/~lynn/subtopic.html#545tech
>
> in 1969. shortly after that, gml processing was added to the
> cms script document processor.
>
> </lots of topic drift>

and for even more topic drift about the latest, new, 40yr old thing

i built a lot of systems in the 60s (as an undergraduate) and 70s
.... and it never occured to build something that wasn't secure. it
wasn't until much later that i found a lot of it to be prevailing use
in certain quarters. minor ref:
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm

in the mid-70s the company got a new CSO ... these were the days when
CSOs for major corporations frequently had backgrounds like retired
secret service (or something similar). they tended to have a lot of
physical security experience. for what ever reason, i got asked to run
around with him for several months to help him learn about computer
security.

minor security reference
http://www.garlic.com/~lynn/2006.html#11

somewhat akin to the "yes card" vulnerability
http://www.garlic.com/~lynn/subintegrity.html#yescard

which appeared shortly after some chipcard deployments in the 90s
.... but the above referenced scenario was approx. 25 years earlier
i.e. compromise the system so that anything/everything is taken as
valid pin/password

other somewhat related posts
http://www.garlic.com/~lynn/2006h.html#14
http://www.garlic.com/~lynn/2006n.html#2
http://www.garlic.com/~lynn/2006n.html#52
http://www.garlic.com/~lynn/2006t.html#38

Anne & Lynn Wheeler <lynn@garlic.com> writes:
> so what x9.59 financial standard did was require strong authentication
> and integrity for every transaction ... and a business rule that
> account numbers used in x9.59 could not be used in non-authenticated
> transactions. basically just knowing an account number was no longer
> sufficient to perform a fraudulent transaction ... and so it was no
> longer necessary to constantly keep the account number hidden; i.e.
> authentication and integrity replaced privacy to achieve security.
> x9.59 did nothing to prevent skimming/harvesting transactions ... but
> eliminated the risk/fraud associated with attacker (or insider)
> skimming/harvesting.

re:
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security

even more drift related to static authentication data being vulnerable to
various kinds of skimming/harvesting attacks

Fast Payments creates strong case for two-factor authentication, says
Thales
http://www.finextra.com/fullstory.asp?id=16240
Banks lobby govt on smartcard
http://www.hackinthebox.org/modules....icle&sid=21919

British Banks keep a secret..
http://www.zone-h.org/content/view/14404/31/
Banks reluctant to reveal full extent of online fraud
http://www.e-consultancy.com/news-bl...ine-fraud.html
Newspaper Says UK Banks Fail to Report Online Fraud
http://www.epaynews.com/index.cgi?su...2145191&block=

Smart Card Alliance slams RFID use in US passport card program
http://www.cbronline.com/article_new...2-45B457496214
Industry group urges caution on U.S. plan for RFID-enabled ID cards
http://www.computerworld.com/action/...intsrc=hm_list
RFID Sabotages Privacy, Says Government Watchdog
http://www.rfidnews.org/weblog/2006/...ment-watchdog/
US government warned off RFID passports
http://www.techworld.com/security/ne...13&pagtype=all
Smart Card Alliance Cautions Feds on RFID Cards
http://www2.csoonline.com/blog_view.html?CID=27237

Flaw exploited in RFID-enabled passports
http://www.garlic.com/~lynn/aadsm25.htm#46
Flaw in RFID-enabled passports (part 2?)
http://www.garlic.com/~lynn/aadsm26.htm#0

Note one of the issues related to "yes card" bank chipcard exploits
http://www.garlic.com/~lynn/subintegrity.html#yescard

was that it used static data for authentication. this made it
vulnerable to harvest/skimming and replay attacks (not too different
from magstripe harvest/skimming with replay attacks using counterfeit
cards).

however, the big additional vulnerability introduced with the bank
chipcard exploits, was that the terminal, after initially verifying
the chips (static) authentication data ... would then "obey" the
cards' instructions ... which gave rise to the "yes card" label.

When the terminal asked if the entered PIN was correct, a counterfeit
"yes card" would always answer "YES", minor digression
http://www.garlic.com/~lynn/2006w.html#0 Patent buster for a method that increases password security

And when the terminal asked if the transaction should be offline, the
counterfeit "yes card" would always answer "YES", and when the
terminal then asked if the transaction was within the account credit
limit, the counterfeit "yes card" would again answer "YES".

In some of the bank chipcard deployments ... after the appearance of
some of the counterfeit "yes cards" (in earlier deployments in the
90s), some made the decision to only issue valid cards that only did
online transactions (and never opted for offline operation, perceiving
it to be a countermeasure to "yes card" attack).

However, these were highly card-centric operations ... and didn't
understand that the counterfeit "yes card" attacks weren't attacks on
the card ... but attacks on the terminal. It was still possible to
skim that static authentication data from such cards, load it into a
counterfeit "yes card", and program the counterfeit "yes card" to tell
the terminal that the correct pin was enter and to do offline
transaction.

The problem is that the standard countermeasure for skimmed
counterfeit cards is to disable the account. However, when a terminal
does an offline transaction, there is no communication to find out
that the acocunt has been disabled until way after the fraud has
occured. The appropriate countermeasure to the "yes card" exploits
wasn't to program valid cards to only do online transactions, the
appropriate countermeasure to the "yes card" exploits was to program
terminals to never do offline transactions (i.e. it was an attack on
terminals not attacks on cards).

Sen. Schumer Decries Dangers of 'No-Swipe' Credit Cards
http://www.foxnews.com/story/0,2933,234586,00.html
Sen. Schumer Calls For Better Contactless Payment Security
http://www.cardtechnology.com/articl...061206O8ZLO98Q
Would You Trust RFID-Enabled ATM Cards?
http://ask.slashdot.org/askslashdot/.../0532242.shtml
Would You Trust RFID-Enabled ATM Cards?
http://ask.slashdot.org/article.pl?sid=06/12/06/0532242
Possible Serious Security Flaw In ATMs
http://it.slashdot.org/it/06/11/30/2....shtml?tid=187

So if bank cards continue to use static authentication data, they
continue to be vulnerable to harvest/skimming exploits ... and
contactless/wireless communication may increase the opportunities for
attackers to record static authentication data.

Note however, there may still be other vulnerabilities even in any
upgrade from static to dynamic authentication data. This is the
scenario whether the card is being authenticated or is the transaction
being authenticated.
http://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions

the scenario with card authentication ... is that even with dynamic
authentication data, it may still be vulnerability to a "yes card"
MITM-attack where a "yes card" is paired with a lost/stolen card (or
any valid card obtained by any means).

The counterfeit "yes card" transparently passes the card
authentication messages ... but then takes over the rest of the
communication to perform the "YES" answers to the three terminal
questions 1) correct PIN, 2) offline transaction, 3) within credit
limit.

Anne & Lynn Wheeler <lynn@garlic.com> writes:
> So if bank cards continue to use static authentication data, they
> continue to be vulnerable to harvest/skimming exploits ... and
> contactless/wireless communication may increase the opportunities for
> attackers to record static authentication data.

re:
http://www.garlic.com/~lynn/2006w.html#4 Patent buster for a method that increases password security

note that the purpose of disabling the account (as a fraudulent
transaction compromise), is paradigm where the account number has
frequently been the primary method of authentication i.e. knowning the
account number as "something you know" authentication ... from
3-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor

* something you have
* something you know
* something you are

aka you frequently see fraud compromise being dealt with by issuing a
new card which also carries a new account number (the old account
number having been flagged).

in the x9.59 standard, the paradigm is changed to transaction
authentication; and therefor it is no longer necessary to disable the
account number (as a fraud compromise countermeasure) ... it is only
necessary to disable the specific compromised authentication (i.e. say
specific lost/stolen card with its corresponding "something you have"
authentication).
http://www.garlic.com/~lynn/2006v.html#26 Fighting Fraudulent Transactions

since all valid, authorized x9.59 transactions require the appropriate
authentication.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

incoming transactions are recognized as appropriately authenticated,
by the correct transaction authentication data, not by the account
number.