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:
1. User is asked to upload an image and an access key to the website
2. The webserver takes the uploaded image, subtly modifies say 500
pixels by adjusting tone or hue a bit say so the image still looks OK
to the eye
3. The server converts the image to a jpeg and saves a random start
point from this file (away from the header) and say 500 characters on
a database, plus a hashkey for the file itself.
4. The image is packed into a zip file which is password protected
with the access key the user specified and sent to the user via email.
5. The user unpacks the image and saves it among other images (they
can rename it too, and put it in a secure directory on their system if
required).
6. When they need to authenicate themselves they upload the relevant
image
Note that the image is never shown on a website so it shouldn't be
cached anywhere.
This would have the benefit that the password image is easily
recognisable to the user so easy for the user to remember whilst being
difficult for a non-user to spot, it's also not obviously a password.
It's almost impossible to hack from outside the users computer without
a copy of the image - the data length is too big and too random for
brute force attacks. The image can also be copied on to a memory card
and used from other computers if needs be under the control of the
user (like a house key essentially).
The danger is that the computer or the memory card get stolen, or the
images get copied, but even stolen it would blend in to other images
on the system (personally I've got around 15,000 jpegs on this
computer, but I could be unusual), or could be additionally secured or
encrypted locally.
Does any such system already exist? Does the server actually need to
make modifications to the uploaded image or would a plain image do on
its own? Are there any comments or am I just barking up the wrong
tree?
"Saul" <saul.dobney@dobney.com> writes:
> 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:
They can lose the image files too, so you may as well use passwords.
If you want something better than passwords, use hardware tokens.
Paypal is selling those for $5 now, so they must have found a cheap
source of them.
On 22 Feb, 12:45, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> "Saul" <saul.dob...@dobney.com> writes:
> > 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:
>
> They can lose the image files too, so you may as well use passwords.
> If you want something better than passwords, use hardware tokens.
> Paypal is selling those for $5 now, so they must have found a cheap
> source of them.
The problem with good secure passwords is they are eminently
forgettable as our current users keep demonstrating - so they either
pick weak or simple passwords or keep chasing us for password help, so
I want something easier without losing password strength for an
application where we really do want better levels of security.
Oh and as we're just a smigeon smaller than eBay/Paypal hardware
solutions aren't really available to us.
On Feb 22, 6:33 am, "Saul" <saul.dob...@dobney.com> wrote:
> 1. User is asked to upload an image and an access key to the website
> Does any such system already exist? Does the server actually need to
> make modifications to the uploaded image or would a plain image do on
> its own?
any file can be used as a keyfile, (so any image file selected by the
user is ok)
in your setup,
the server does not need to modify the image,
(just hash it [sha-512 should be fine] )
and keep the hash to verify that the image file is unaltered)
but the users have to be cautioned to use only an image that has not
been e-mailed, posted, or otherwise 'leaked'
and to safeguard that image as if it were an actual key
"Saul" <saul.dobney@dobney.com> writes:
> The problem with good secure passwords is they are eminently
> forgettable as our current users keep demonstrating - so they either
> pick weak or simple passwords or keep chasing us for password help, so
> I want something easier without losing password strength for an
> application where we really do want better levels of security.
If they have to keep an image file around, why not just use a password.
How about giving them a card with a password printed on it.
> Oh and as we're just a smigeon smaller than eBay/Paypal hardware
> solutions aren't really available to us.
> 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.?
Like users tend to use their pets' names or their birthdays as
passwords, they will google up a cool image and use that one. But what
concerns me more about this concept: Even more likely, they will
present them to friends: "Hey look, this is my password!", just to
impress them.
The story goes further. Users go, "What? You can use images as
passwords? Cool!", so they'll do the same, which builds up a large
network of cool users using cool pictures for authentication. Cool,
ain't it?
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.
Another interesting feature of this concept is that users can prove they
are users of your service to others by presenting their certificate, if
this is of any use.
> This would have the benefit that the password image is easily
> recognisable to the user so easy for the user to remember whilst being
> difficult for a non-user to spot, it's also not obviously a password.
> It's almost impossible to hack from outside the users computer without
> a copy of the image - the data length is too big and too random for
> brute force attacks. The image can also be copied on to a memory card
> and used from other computers if needs be under the control of the
> user (like a house key essentially).
All this can be done with a certificate as well, with the additional
benefit that users don't even have the desire to share it.
> The danger is that the computer or the memory card get stolen, or the
> images get copied, but even stolen it would blend in to other images
> on the system (personally I've got around 15,000 jpegs on this
> computer, but I could be unusual), or could be additionally secured or
> encrypted locally.
No problem with certificates. The corresponding private key is
encrypted using a passphrase by default, and you can use the same
certificate to identify to different services without a security risk.
Just add additional signatures to it.
> Does any such system already exist? Does the server actually need to
> make modifications to the uploaded image or would a plain image do on
> its own? Are there any comments or am I just barking up the wrong
> tree?
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.
Jim Watt wrote:
> Not a bad idea, but you do appreciate that a JPG file uses compression
> so any altered pixels are not necessarily the same after the image is
> saved.
I think it's OK if they're different, but there would be a problem if
the compression caused the changes to be lost completely.
On 22 Feb 2007 14:57:40 EST, Mike Amling <spamonly@allspam.com> wrote:
>> Not a bad idea, but you do appreciate that a JPG file uses compression
>> so any altered pixels are not necessarily the same after the image is
>> saved.
>
> I think it's OK if they're different, but there would be a problem if
>the compression caused the changes to be lost completely.
Compression does cause total loss of some data. The only way I see to
use the file is to save it, and then use the saved file. If the file
is ever resaved as a jpg, it would most likely be different.
If you have users too stupid to remember their own chosen passwords, or
you use rules that make it nearly impossible to create human-memorable
passwords, then have the user use something like PasswordSafe. It's
free at sourceforge.net. They will, however, have to remember the
password that THEY choose to let them open PasswordSafe but they are
reduced to having to remember just one password using their own rules.
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.
>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.
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.
>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.
Rick Merrill <rick0.merrill@NOSPAM.gmail.com> 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.
Image files as passwords 
Linear Mode
