«

On 22 Feb, 18:57, Ertugrul Soeylemez <use...@streitmacht.eu> wrote:
> "Saul" <saul.dob...@dobney.com> (07-02-22 03:33:42):
>
> > I'm looking to build some new security features for a website which
> > will need stronger levels of password access, but I'm conscious from
> > experience that users aren't very good with passwords and keep losing
> > them or forgetting them so I don't want just bigger and better
> > passwords. What I was wondering was whether image files would be
> > better:
>
> > [...]
>
> > Note that the image is never shown on a website so it shouldn't be
> > cached anywhere.
>
> I disagree about the security of pictures. What's the probability that
> the image is not a copy taken from a web-site, an image shot by camera
> and uploaded to Imageshack, etc.?

Hmmm... Even if the image is a copy from a web-site, the server
signing by manipulation will make the image returned unique. It's
straightforward to ensure the image returned is not the same as the
original even after applying a jpeg compression - the compression will
actually mask the image manipulation. Even so how is a hacker to know
which picture to attempt to use as the key? They can't simply check
every picture on the Internet in the hope it will work. Only if the
computer/memory stick is stolen do they have a hope of narrowing the
image choice down and even then the image can be hidden among other
files - that makes it more secure than my house key.

> Take another approach. Build a CA (which is as simple as generating a
> self-signed certificate). The users need to generate certificates,
> which are transferred to the server and signed by it. Only users with a
> signed certificate will be let in. This also eliminates the need to
> authenticate explicitly, since you can save the certificate in the
> browser, so it presents it to the server automatically.

Three problems - firstly cost as I believe - and it would be useful to
find out that I'm wrong about this - the user has to pay for the
certificate and the certificate has to be supplied by a third party
(and all hardware based solutions are out on the basis of cost,
largely through the fulfilment and administration costs, being a
website users will be widely distributed and largely unknown to the
site administration). Secondly, I'm worried about the technical
expertise required to allow certificates to be used. My only
experience of them is for server administration use and we need quite
detailed installation instructions to get and implement certificates.
It may be our particular use but I worry this would be beyond people
who routinely forget anything with 8 or more characters in it. Thirdly
doesn't a certificate need a password key too?

> Probably barking up the wrong tree. Never use personal things as
> authentication secrets, because they aren't secret. On requesting an
> image, a lot of users will upload an image of themselves. Why? Because
> it's an `identification' image. Or just because the image represents
> themselves. Like authentication in real world is done by looking at the
> person. Remember: Users are dumb.

But you've still excluded external hackers because they don't have
your image and can't generate your image through dictionaries or other
forms of password cracking. The only people who can gain access are
those with access to your images and if the image is made unique by
the server it will be different from images you post elsewhere (not
only this, but many upload sites require or use image rescaling which
immediately renders the image different from the password image). It
has the benefit of being recognisable to the user (prompted recall is
hugely easier than unprompted and therefore much less likely to be
'lost') but unknown to anyone who doesn't know what to recognise.


Saul

On 23 Feb 2007 00:18:38 -0800, "Saul" <> wrote:

>the user has to pay for the certificate and the certificate
>has to be supplied by a third party

No, you can generate your own. Its no problem if its for
internal use. The reason for using a certificate authority
is because theirs are tracable back to them and they take
care in who they issue to, and they are implemented in
your browser by default.
--
Jim Watt
http://www.gibnet.com

"Saul" <> writes:

>On 22 Feb, 18:57, Ertugrul Soeylemez <use...@streitmacht.eu> wrote:
>> "Saul" <saul.dob...@dobney.com> (07-02-22 03:33:42):
>>
>> > I'm looking to build some new security features for a website which
>> > will need stronger levels of password access, but I'm conscious from
>> > experience that users aren't very good with passwords and keep losing
>> > them or forgetting them so I don't want just bigger and better
>> > passwords. What I was wondering was whether image files would be
>> > better:
>>
>> > [...]
>>
>> > Note that the image is never shown on a website so it shouldn't be
>> > cached anywhere.
>>
>> I disagree about the security of pictures. What's the probability that
>> the image is not a copy taken from a web-site, an image shot by camera
>> and uploaded to Imageshack, etc.?

>Hmmm... Even if the image is a copy from a web-site, the server
>signing by manipulation will make the image returned unique. It's
>straightforward to ensure the image returned is not the same as the
>original even after applying a jpeg compression - the compression will
>actually mask the image manipulation. Even so how is a hacker to know

And every compressor is different-- different levels, etc. Ie, it is no
longer an image it is simply some file.

So what your proposal is that the server sends the person a file, and that
person has to send that file back as a passphrase. It is stored on that
person's computer, not in his memory, so a theft of the computer or its
contents gives the person the passphrase. The length of the passphrase
rules out almost all of the files on that computer, leaving the attacker
with just a few to try.



And the attacker will discover which file by say sniffing the line and
seeing the size of the file sent-- which will eliminate 99% of the images
on the hard disk. And if the connection is cleartext, then the attacker
need just store the image and use it.

What you need first of all is the whole range of attack scenarios you are
trying to guard against and then design a system which will work against
all of them.



>which picture to attempt to use as the key? They can't simply check
>every picture on the Internet in the hope it will work. Only if the
>computer/memory stick is stolen do they have a hope of narrowing the
>image choice down and even then the image can be hidden among other
>files - that makes it more secure than my house key.

>> Take another approach. Build a CA (which is as simple as generating a
>> self-signed certificate). The users need to generate certificates,
>> which are transferred to the server and signed by it. Only users with a
>> signed certificate will be let in. This also eliminates the need to
>> authenticate explicitly, since you can save the certificate in the
>> browser, so it presents it to the server automatically.

>Three problems - firstly cost as I believe - and it would be useful to
>find out that I'm wrong about this - the user has to pay for the
>certificate and the certificate has to be supplied by a third party
>(and all hardware based solutions are out on the basis of cost,

What cost? Is the mentioned $5 really out on the basis of cost?


>largely through the fulfilment and administration costs, being a
>website users will be widely distributed and largely unknown to the
>site administration). Secondly, I'm worried about the technical
>expertise required to allow certificates to be used. My only
>experience of them is for server administration use and we need quite
>detailed installation instructions to get and implement certificates.
>It may be our particular use but I worry this would be beyond people
>who routinely forget anything with 8 or more characters in it. Thirdly
>doesn't a certificate need a password key too?

But your file is a "certificate".



>> Probably barking up the wrong tree. Never use personal things as
>> authentication secrets, because they aren't secret. On requesting an
>> image, a lot of users will upload an image of themselves. Why? Because
>> it's an `identification' image. Or just because the image represents
>> themselves. Like authentication in real world is done by looking at the
>> person. Remember: Users are dumb.

>But you've still excluded external hackers because they don't have
>your image and can't generate your image through dictionaries or other
>forms of password cracking. The only people who can gain access are

They attack the computer, copy all the files and then they have all the
info they need. By your own admission, these are users who cannot remember
and 8 character password. They sure cannot figure out how to harden their
computers against attacks so you have to assume that their computers are an
open book to any attacker.


>those with access to your images and if the image is made unique by
>the server it will be different from images you post elsewhere (not
>only this, but many upload sites require or use image rescaling which
>immediately renders the image different from the password image). It
>has the benefit of being recognisable to the user (prompted recall is
>hugely easier than unprompted and therefore much less likely to be
>'lost') but unknown to anyone who doesn't know what to recognise.

Uh, you postulate that the user has 10's of thousands of images on his
comptuter. You really expect them to leaf through them all to find that one
image, even if it is "recognizeable"? Your assumptions contradict each
other. So the user labels the image "password" so he can remember which it
is.




>Saul

On 23 Feb, 18:07, Unruh <unruh-s...@physics.ubc.ca> wrote:
> Uh, you postulate that the user has 10's of thousands of images on his
> comptuter. You really expect them to leaf through them all to find that one
> image, even if it is "recognizeable"? Your assumptions contradict each
> other. So the user labels the image "password" so he can remember which it
> is.

Thanks for the thoughts. You've convinced me it's worth trying as the
objections are mainly: 1. if they had access to the computer and 2. if
they could sniff the filelength (the file would never be sent in
cleartext BTW). Otherwise they don't know what file to use - file
length would be difficult to ascertain if the file is sent securely
with other data.

A 'guess' or 'automated' remote attack would be impossible from
someone without the right file. A remote attack on the users computer
could compromise the file - but which would be difficult to ascertain
remotely - and would be no worse than someone compromising the
computer on which the passwords are held in the MyPasswords folder
(yes I've seen them too), or stealing another certificate. The image
can be protected as the certificate can be protected on the users
machine.

By the way as someone who has done a lot of professional market
research work on measuring recall and recognition in different
situations, I think you are confusing unprompted and prompted recall.
The benefit of having a recognisable image as the certificate is huge
compared to spontaneous recall of a semi-random text string, the
memory includes both image and position recognition which is why we
want an image prompt.

I will produce a proof of concept in the next few weeks.


Saul

"Saul" <> writes:

>On 23 Feb, 18:07, Unruh <unruh-s...@physics.ubc.ca> wrote:
>> Uh, you postulate that the user has 10's of thousands of images on his
>> comptuter. You really expect them to leaf through them all to find that one
>> image, even if it is "recognizeable"? Your assumptions contradict each
>> other. So the user labels the image "password" so he can remember which it
>> is.

>Thanks for the thoughts. You've convinced me it's worth trying as the
>objections are mainly: 1. if they had access to the computer and 2. if
>they could sniff the filelength (the file would never be sent in
>cleartext BTW). Otherwise they don't know what file to use - file
>length would be difficult to ascertain if the file is sent securely
>with other data.

>A 'guess' or 'automated' remote attack would be impossible from
>someone without the right file. A remote attack on the users computer
>could compromise the file - but which would be difficult to ascertain
>remotely - and would be no worse than someone compromising the
>computer on which the passwords are held in the MyPasswords folder
>(yes I've seen them too), or stealing another certificate. The image
>can be protected as the certificate can be protected on the users
>machine.

>By the way as someone who has done a lot of professional market
>research work on measuring recall and recognition in different
>situations, I think you are confusing unprompted and prompted recall.
>The benefit of having a recognisable image as the certificate is huge
>compared to spontaneous recall of a semi-random text string, the
>memory includes both image and position recognition which is why we
>want an image prompt.

>I will produce a proof of concept in the next few weeks.


"We"? Now there are a bunch of you. You are now going to use this in a
context where it means something? I shudder.
You are wanting this to be distributed to people who have no idea or
discipline about crypto. You can assume that their comuter is cracked--
that it is owned by nefarious people out there ( What is the figure-- 30%
of computers are broken into and usable by outsiders?). And I would also
still insist that the very conditions you are aducing as security--- many
image files on the computer-- are also what makes the nemonic value of the
image useless. The more usefull it is ( which of these four image files is
the right one) the less security it offers. (This guy only has four image
files. Lets try them all).

Saul wrote:
> I'm looking to build some new security features for a website which
> will need stronger levels of password access, but I'm conscious from
> experience that users aren't very good with passwords and keep losing
> them or forgetting them so I don't want just bigger and better
> passwords. What I was wondering was whether image files would be
> better:

....
Have the site send the user an image; the user uses key encryption to
encode the image data and return it to the web site which authenticates
the result. This process would be similar to PGP.

The advantage is that an attacker sniffing at the results would find
it much more difficult to 'find' the authentication key inside the
junk of the randomly selected image, while the authenticator already
knows what the image was and what the bits should look like when
receiving it after the image is encrypted with the key.

Saul wrote:
> I'm looking to build some new security features for a website which
> will need stronger levels of password access, but I'm conscious from
> experience that users aren't very good with passwords and keep losing
> them or forgetting them so I don't want just bigger and better
> passwords. What I was wondering was whether image files would be
> better:

....
Have the site send the user an image; the user uses key encryption to
encode the image data and return it to the web site which authenticates
the result. This process would be similar to PGP.

The advantage is that an attacker sniffing at the results would find
it much more difficult to 'find' the authentication key inside the
junk of the randomly selected image, while the authenticator already
knows what the image was and what the bits should look like when
receiving it after the image is encrypted with the key.

On 24 Feb, 19:19, Unruh <unruh-s...@physics.ubc.ca> wrote:
> "Saul" <saul.dob...@dobney.com> writes:
> >On 23 Feb, 18:07, Unruh <unruh-s...@physics.ubc.ca> wrote:
> >> Uh, you postulate that the user has 10's of thousands of images on his
> >> comptuter. You really expect them to leaf through them all to find that one
> >> image, even if it is "recognizeable"? Your assumptions contradict each
> >> other. So the user labels the image "password" so he can remember which it
> >> is.
> >Thanks for the thoughts. You've convinced me it's worth trying as the
> >objections are mainly: 1. if they had access to the computer and 2. if
> >they could sniff the filelength (the file would never be sent in
> >cleartext BTW). Otherwise they don't know what file to use - file
> >length would be difficult to ascertain if the file is sent securely
> >with other data.
> >A 'guess' or 'automated' remote attack would be impossible from
> >someone without the right file. A remote attack on the users computer
> >could compromise the file - but which would be difficult to ascertain
> >remotely - and would be no worse than someone compromising the
> >computer on which the passwords are held in the MyPasswords folder
> >(yes I've seen them too), or stealing another certificate. The image
> >can be protected as the certificate can be protected on the users
> >machine.
> >By the way as someone who has done a lot of professional market
> >research work on measuring recall and recognition in different
> >situations, I think you are confusing unprompted and prompted recall.
> >The benefit of having a recognisable image as the certificate is huge
> >compared to spontaneous recall of a semi-random text string, the
> >memory includes both image and position recognition which is why we
> >want an image prompt.
> >I will produce a proof of concept in the next few weeks.
>
> "We"? Now there are a bunch of you. You are now going to use this in a
> context where it means something? I shudder.
> You are wanting this to be distributed to people who have no idea or
> discipline about crypto. You can assume that their comuter is cracked--
> that it is owned by nefarious people out there ( What is the figure-- 30%
> of computers are broken into and usable by outsiders?). And I would also
> still insist that the very conditions you are aducing as security--- many
> image files on the computer-- are also what makes the nemonic value of the
> image useless. The more usefull it is ( which of these four image files is
> the right one) the less security it offers. (This guy only has four image
> files. Lets try them all).- Hide quoted text -

If your computer is cracked and you use it for anything serious you're
buggered anyway. You add a certificate. How on earth is that any safer
if the computer is already compromised?

Your objections remain - someone else has access to the same files on
that computer. If that's the case there's no protection for the user
anywhere - a hacker can just upload a keylogger and monitor internet
traffic through any backdoor method. No amount of cryptography can
cope with this. The best you can do is limit your exposure to any
individual on the server - but that's taken for read anyway.


Saul

Rick Merrill <> writes:

>Saul wrote:
>> I'm looking to build some new security features for a website which
>> will need stronger levels of password access, but I'm conscious from
>> experience that users aren't very good with passwords and keep losing
>> them or forgetting them so I don't want just bigger and better
>> passwords. What I was wondering was whether image files would be
>> better:

>...
>Have the site send the user an image; the user uses key encryption to
>encode the image data and return it to the web site which authenticates
>the result. This process would be similar to PGP.

The user does this key encrytion how? Where does this key come from? The OP
was concerneed that his users would forget their keys, and came up with his
technique so that they could store their keys, unencrypted, on their disk.
He relied on the fact that that disk would have lots of images on it, so an
attacker would not know which image to choose.


>The advantage is that an attacker sniffing at the results would find
>it much more difficult to 'find' the authentication key inside the
>junk of the randomly selected image, while the authenticator already
>knows what the image was and what the bits should look like when
>receiving it after the image is encrypted with the key.

The attacker is assumed to know what that obfuscation technique is.