Patent buster for a method that increases password security

Discussion in 'Computer Security' started by Juuso Hukkanen, Dec 4, 2006.

  1. 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/art...ERNET-IDENTITIES-DC.XML&WTmodLoc=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, Dec 4, 2006
    #1
    1. Advertising

  2. That's both prior art and non-working. Hint: What happens when the URL
    changes?
     
    Sebastian Gottschalk, Dec 4, 2006
    #2
    1. Advertising

  3. Juuso Hukkanen <> 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
     
    Anne & Lynn Wheeler, Dec 4, 2006
    #3
  4. On Mon, 4 Dec 2006 17:50:46 +0100, Sebastian Gottschalk
    <> 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, Dec 4, 2006
    #4
  5. Juuso Hukkanen

    Unruh Guest

    Juuso Hukkanen <> writes:

    >On Mon, 4 Dec 2006 17:50:46 +0100, Sebastian Gottschalk
    ><> 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
     
    Unruh, Dec 4, 2006
    #5
  6. On Mon, 04 Dec 2006 10:02:33 -0700, Anne & Lynn Wheeler
    <> 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, Dec 4, 2006
    #6
  7. Juuso Hukkanen

    Unruh Guest

    Juuso Hukkanen <> writes:

    >On Mon, 04 Dec 2006 10:02:33 -0700, Anne & Lynn Wheeler
    ><> 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
     
    Unruh, Dec 4, 2006
    #7
  8. On 4 Dec 2006 18:29:46 GMT, Unruh <> wrote:

    >Juuso Hukkanen <> writes:
    >
    >>On Mon, 4 Dec 2006 17:50:46 +0100, Sebastian Gottschalk
    >><> 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
    463e9793bece1797243d3f36d97b353f547d6381a63dd10ae4db529f46c8ae8a4debe91e488bf98b
    15d7528cc9dada960f83951d746687a12483cafb94e403da

    2. "secret_reused_pass:hotmail.com" SHA-512 hash for hotmail.com
    d95eb347dff09350433b75e2bb254f0b3dc73589052ff0a200fe1ee2d49f41d73dda8605cc3262cd
    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, Dec 4, 2006
    #8
  9. Juuso Hukkanen wrote:

    >>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.


    No, because the server can't authenticate the user or his new password. And
    well, if he could, the entire scheme is superfluos...

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


    Ok, and how do you securely transmit and especially authenticate the new
    value after creation?

    > 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.


    Thank the Flying Spaghetti Monster that there's no such non-sense like
    software patents in good'ol Europe (yet).
     
    Sebastian Gottschalk, Dec 4, 2006
    #9
  10. Juuso Hukkanen

    Unruh Guest

    Juuso Hukkanen <> writes:

    >On 4 Dec 2006 18:29:46 GMT, Unruh <> wrote:


    >>Juuso Hukkanen <> writes:
    >>
    >>>On Mon, 4 Dec 2006 17:50:46 +0100, Sebastian Gottschalk
    >>><> 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
    >463e9793bece1797243d3f36d97b353f547d6381a63dd10ae4db529f46c8ae8a4debe91e488bf98b
    >15d7528cc9dada960f83951d746687a12483cafb94e403da


    >2. "secret_reused_pass:hotmail.com" SHA-512 hash for hotmail.com
    >d95eb347dff09350433b75e2bb254f0b3dc73589052ff0a200fe1ee2d49f41d73dda8605cc3262cd
    >55543fdf14daa667bf6ce02aa74c3e5c091b44c1efab41bb


    ><--> 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
     
    Unruh, Dec 4, 2006
    #10
  11. On 4 Dec 2006 19:12:36 GMT, Unruh <> 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 .
    </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, Dec 4, 2006
    #11
  12. Juuso Hukkanen <> 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>
     
    Anne & Lynn Wheeler, Dec 4, 2006
    #12
  13. On 4 Dec 2006 20:51:35 GMT, Unruh <> 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
     
    Juuso Hukkanen, Dec 4, 2006
    #13
  14. Juuso Hukkanen wrote:

    > 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 now you're handwaving about exactly where the problem is.
     
    Sebastian Gottschalk, Dec 4, 2006
    #14
  15. On Mon, 04 Dec 2006 14:33:30 -0700, Anne & Lynn Wheeler
    <> 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, Dec 5, 2006
    #15
  16. Juuso Hukkanen <> 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, Dec 5, 2006
    #16
  17. Anne & Lynn Wheeler <> 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, Dec 5, 2006
    #17
  18. Anne & Lynn Wheeler <> 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.php?op=modload&name=News&file=article&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-b...nt-to-reveal-full-extent-of-online-fraud.html
    Newspaper Says UK Banks Fail to Report Online Fraud
    http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1165410908213202145191&block=

    Smart Card Alliance slams RFID use in US passport card program
    http://www.cbronline.com/article_news.asp?guid=88914D85-0D0F-47D2-AEC2-45B457496214
    Industry group urges caution on U.S. plan for RFID-enabled ID cards
    http://www.computerworld.com/action...ArticleBasic&articleId=9005675&intsrc=hm_list
    RFID Sabotages Privacy, Says Government Watchdog
    http://www.rfidnews.org/weblog/2006/12/05/rfid-sabotages-privacy-says-government-watchdog/
    US government warned off RFID passports
    http://www.techworld.com/security/news/index.cfm?newsID=7513&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/article.html?id=20061206O8ZLO98Q
    Would You Trust RFID-Enabled ATM Cards?
    http://ask.slashdot.org/askslashdot/06/12/06/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/2139235.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, Dec 6, 2006
    #18
  19. Anne & Lynn Wheeler <> 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.
     
    Anne & Lynn Wheeler, Dec 7, 2006
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ida Young
    Replies:
    8
    Views:
    457
  2. Rich

    The effect of pixel increases on images

    Rich, Mar 5, 2006, in forum: Digital Photography
    Replies:
    8
    Views:
    385
  3. Giuen
    Replies:
    0
    Views:
    1,259
    Giuen
    Sep 12, 2008
  4. Lawrence D'Oliveiro
    Replies:
    1
    Views:
    386
    victor
    Aug 31, 2010
  5. Lawrence D'Oliveiro

    If A Patent Is A Monopoly, Then A Patent Pool Is A Cartel

    Lawrence D'Oliveiro, Oct 29, 2010, in forum: NZ Computing
    Replies:
    1
    Views:
    529
    Gordon
    Oct 31, 2010
Loading...

Share This Page