"Saul" <saul.dobney@dobney.com> 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