Generate a unique ID that identifies the client?

[stec00]

I have an javascript application that needs to generate a unique ID
that will identify the client. It doesn't really matter what this ID
is, a number, string or even set of ascii codes would be fine - as
long as it is unique or nearly unique. The ID needs to be something
that can be worked out just from the client's info. Ideally it would
be done in straight javascript but if this isn't possible I'd even
consider an AJAX request that got the info from a server. I've got a
server that's running PHP so this would be the preferred server side
language if that option is chosen.

Anyway I'm racking my brains trying to work out how to do this. In
Javascript I've been considering whether it might be possible to use
some combination of UserAgent components but UserAgent doesn't really
provide very much that would be unique and the snag is it might change
if say the user changed their add-ons or version of Firefox etc. (We
can assume the user is running Firefox here since this is for a
GreaseMonkey script). I'd hoped there might be some way to get the
user's MAC address (it only has to be unique for the computer being
used) but it seems this isn't possible to get hold of using Javascript
or PHP. In PHP I'd considered using the IP address but this isn't
necessarily going to stay the same over time, which is another
requirement.

So I'm running into quite a few dead ends and now turning to Internet-
land for help...Can anyone think of a way? Would be grateful for any
suggestions.

Cheers,
Steve

 

[Thomas 'PointedEars' Lahn]

I have an javascript application that needs to generate a unique ID
that will identify the client. [...]

This requirement begs the question: Why?


PointedEars

 

[stec00]

I have an javascript application that needs to generate a unique ID
that will identify the client. [...]

This requirement begs the question: Why?

PointedEars

Hi PointedEars,

Thought it probably best not to go into that at first - the question
was hard enough to explain without going into the details of why!
Anyway, to summarise, I'd like to generate a key for each user for
encrypting password data stored as cookies on their machine. Ideally
this would be impossible to reverse-engineer - but failing that it
should be unique for each client so a casual attempt to gain passwords
using a single key over multiple machines would fail.

OK, so there may be alternatives such as getting the client to type in
their own password but ideally it wouldn't require any user
interaction. Also the key needs to be persisted between websites on
different domains and between multiple windows opened on the browser,
which I don't think is possible with cookies or any other methods of
data persistence that I know of (well...suppose this is a separate
question really). Anyway I'm interested to know if it's possible to
generate a unique client ID, can think of other uses for it e.g.
tracking users.

Cheers
Steve

 

[Thomas 'PointedEars' Lahn]

I have an javascript application that needs to generate a unique ID
that will identify the client. [...]

This requirement begs the question: Why? [...]

[...] Thought it probably best not to go into that at first - the
question was hard enough to explain without going into the details of
why! Anyway, to summarise, I'd like to generate a key for each user for
encrypting password data stored as cookies on their machine.

At the risk of repeating myself: Why?

Ideally this would be impossible to reverse-engineer - but failing that
it should be unique for each client so a casual attempt to gain passwords
using a single key over multiple machines would fail.

One already uses PKI (RSA, DSA) for that.

OK, so there may be alternatives such as getting the client to type in
their own password but ideally it wouldn't require any user interaction.
Also the key needs to be persisted between websites on different domains
and between multiple windows opened on the browser,

which I don't think is possible with cookies or any other methods of data
persistence that I know of (well...suppose this is a separate question
really).

It is a separate question. Besides cookies, newer user agents support Storage.

Anyway I'm interested to know if it's possible to generate a unique
client ID,

Probably not. I don't know of a reliable way in an unprivileged environment.

can think of other uses for it e.g. tracking users.

That is probably why you won't receive much help here if you don't explain
the context of your request. People are trying hard not to be traceable on
the Web.


PointedEars

 

[iryndin]

I have an javascript application that needs to generate a unique ID
that will identify the client. It doesn't really matter what this ID
is, a number, string or even set of ascii codes would be fine - as
long as it is unique or nearly unique. The ID needs to be something
that can be worked out just from the client's info. Ideally it would
be done in straight javascript but if this isn't possible I'd even
consider an AJAX request that got the info from a server. I've got a
server that's running PHP so this would be the preferred server side
language if that option is chosen.

Anyway I'm racking my brains trying to work out how to do this. In
Javascript I've been considering whether it might be possible to use
some combination of UserAgent components but UserAgent doesn't really
provide very much that would be unique and the snag is it might change
if say the user changed their add-ons or version of Firefox etc. (We
can assume the user is running Firefox here since this is for a
GreaseMonkey script). I'd hoped there might be some way to get the
user's MAC address (it only has to be unique for the computer being
used) but it seems this isn't possible to get hold of using Javascript
or PHP. In PHP I'd considered using the IP address but this isn't
necessarily going to stay the same over time, which is another
requirement.

So I'm running into quite a few dead ends and now turning to Internet-
land for help...Can anyone think of a way? Would be grateful for any
suggestions.

Cheers,
Steve

Hello, Steve.

I think, you can use UUID (Universally Unique IDentifiers) for your
purposes. There isn't true implementation of UUID generation in
JavaScript due to sandbox issues (cannot get MAC-address of network
adapter from JavaScript), but some Javascript implementations provide
reasonable uniqueness.

You can try this link: http://af-design.com/services/javascript/uuid/
- JavaScript UUID generator is provided here under GPL License.

The other way is to ask server to generate UUIDs. I am specialized in
Java, and I know about java.util.UUID class, which provides such
functionality. Simple Java code example:

import java.util.UUID;

public class GenerateUUID {

public static final void main(String[] args) {
//generate random UUIDs
UUID id1 = UUID.randomUUID();
UUID id2 = UUID.randomUUID();
System.out.println(id1);
System.out.println(id2);
}
}

you should obtain something like:
deea44c7-a180-4898-9527-58db0ed34683
596befcd-fc85-487e-9dbf-9739240d0fc7

Recently I have written a note in my blog about its usage, see
http://jdevnotes.blogspot.com/2009/05/blog-post.html.
(The note is in Russian).

You can write a servlet which simply returns back generated UUIDs, and
you can use it in AJAX-calls to server, so that page will not be
reloaded.
I am sure that other server-side technologies (PHP, Python, Ruby,
etc..etc....) also provide similar functionality.

Regards,
Ivan Ryndin.
Java Dev Notes blog: http://jdevnotes.blogspot.com

 

[stec00]

I have an javascript application that needs to generate a unique ID
that will identify the client. It doesn't really matter what this ID
is, a number, string or even set of ascii codes would be fine - as
long as it is unique or nearly unique. The ID needs to be something
that can be worked out just from the client's info. Ideally it would
be done in straight javascript but if this isn't possible I'd even
consider an AJAX request that got the info from a server. I've got a
server that's running PHP so this would be the preferred server side
language if that option is chosen.

Anyway I'm racking my brains trying to work out how to do this. In
Javascript I've been considering whether it might be possible to use
some combination of UserAgent components but UserAgent doesn't really
provide very much that would be unique and the snag is it might change
if say the user changed their add-ons or version of Firefox etc. (We
can assume the user is running Firefox here since this is for a
GreaseMonkey script). I'd hoped there might be some way to get the
user's MAC address (it only has to be unique for the computer being
used) but it seems this isn't possible to get hold of using Javascript
or PHP. In PHP I'd considered using the IP address but this isn't
necessarily going to stay the same over time, which is another
requirement.

So I'm running into quite a few dead ends and now turning to Internet-
land for help...Can anyone think of a way? Would be grateful for any
suggestions.

Cheers,
Steve

Hello, Steve.

I think, you can use UUID (Universally Unique IDentifiers) for your
purposes. There isn't true implementation of UUID generation in
JavaScript due to sandbox issues (cannot get MAC-address of network
adapter from JavaScript), but some Javascript implementations provide
reasonable uniqueness.

You can try this link:http://af-design.com/services/javascript/uuid/
- JavaScript UUID generator is provided here under GPL License.

The other way is to ask server to generate UUIDs. I am specialized in
Java, and I know about java.util.UUID class, which provides such
functionality. Simple Java code example:

import java.util.UUID;

public class GenerateUUID {

    public static final void main(String[] args) {
        //generate random UUIDs
        UUID id1 = UUID.randomUUID();
        UUID id2 = UUID.randomUUID();
        System.out.println(id1);
        System.out.println(id2);
    }

}

you should obtain something like:
deea44c7-a180-4898-9527-58db0ed34683
596befcd-fc85-487e-9dbf-9739240d0fc7

Recently I have written a note in my blog about its usage, seehttp://jdevnotes.blogspot.com/2009/05/blog-post.html.
(The note is in Russian).

You can write a servlet which simply returns back generated UUIDs, and
you can use it in AJAX-calls to server, so that page will not be
reloaded.
I am sure that other server-side technologies (PHP, Python, Ruby,
etc..etc....) also provide similar functionality.

Regards,
Ivan Ryndin.
Java Dev Notes blog:http://jdevnotes.blogspot.com

Hi Ivan,

Thanks for taking the time to reply and your efforts. Unfortunately
from what I've seen it doesn't seem to provide what I'm looking for. I
need more than just the ability to generate unique IDs, it has to be a
unique *identifier* for a particular client that can be repeatedly
determined at any time. So I think based on that, the function that
produced it would have to know something about the client, whether it
be an IP address, MAC address, or just perhaps some combination of
things that may be unique for the client (OS, timezone etc.) But
unfortunately I haven't been able to find such a thing so far -
generating unique IDs e.g. calculated from the time or some other
randomisation method is fine but getting an identifier for a client
seems to be nigh on impossible. Perhaps it's for good reasons of
security (as PointedEars alluded to) but if so I'd like to know why,
when you look at a webpage that webpage can know and record your IP
address, which is "nearly" unique for each user - were it not for such
things as dynamic IPs, proxies etc. So this is just one step further
and wouldn't have to actually convey any sensitive information.

Cheers
Steve

 

[Thomas 'PointedEars' Lahn]

[...] So I think based on that, the function that
produced it would have to know something about the client, whether it
be an IP address, MAC address, or just perhaps some combination of
things that may be unique for the client (OS, timezone etc.) But
unfortunately I haven't been able to find such a thing so far -
generating unique IDs e.g. calculated from the time or some other
randomisation method is fine but getting an identifier for a client
seems to be nigh on impossible. Perhaps it's for good reasons of
security (as PointedEars alluded to) but if so I'd like to know why,
when you look at a webpage that webpage can know and record your IP
address, which is "nearly" unique for each user - were it not for such
things as dynamic IPs, proxies etc.

You clearly don't know what you are talking about. Given the not so
uncommon case of a corporate LAN behind a router behind a WAN gateway, and
thousands of private households using any number of wireless devices behind
a wireless router, and hundreds of such networks interconnected to each
other over the Internet, an IP adress can not even remotely associated with
any specific user. Not to mention that any number of users may use the same
device, and even the same user agent, and _not_ yet considering dynamic IP
addresses and Web proxies.

So this is just one step further and wouldn't have to actually convey
any sensitive information.

Yes, it would. However, as I said, it is possible to compute a UUID based
on the MAC address of a client's NIC even in JavaScript in a privileged
environment. Examples for such an environment include a Firefox extension,
or a JavaScript script that requested the required privileges from the
Netscape privilege manager to access the required XPCOM component, and being
granted these by the user.

You have also not said what you need this for.


PointedEars

 

[SAM]

Le 6/16/09 10:31 PM, stec00 a écrit :

Thanks for taking the time to reply and your efforts. Unfortunately
from what I've seen it doesn't seem to provide what I'm looking for. I
need more than just the ability to generate unique IDs, it has to be a
unique *identifier* for a particular client that can be repeatedly

Usually the visitor must to log-in, at least the first time.
Submitting name and password to the server, this last-one will generate
the particular unique ID for this person.
Then a cooky is set and send in response to the form with this ID and
automatically saved in the user's navigator files.
On his next visit the server will receive this cooky and will know who
is coming.
Of course if the visitor use another browser the cooky is not yet
available and he will have to login. The server would have then to know
him and what is his ID and send a new cooky for this navigator.
The problem is that anybody using the user's navigator(s) will be seen
as the right owner ...

 

[JR]

I have an javascript application that needs to generate a unique ID
that will identify the client. It doesn't really matter what this ID
is, a number, string or even set of ascii codes would be fine - as
long as it is unique or nearly unique. The ID needs to be something
that can be worked out just from the client's info. Ideally it would
be done in straight javascript but if this isn't possible I'd even
consider an AJAX request that got the info from a server. I've got a
server that's running PHP so this would be the preferred server side
language if that option is chosen.

If you Google for "guid" +comp.lang.javascript, you'll find many
topics where people discuss the pros and cons in generating unique IDs
in the client-side using Javascript. For instance, if your application
have dozens of users and some of them utilize the same computers, then
it seems impossible to guarantee that the generated ID is truly
unique. Therefore I suggest PHP + MySQL to generate these IDs and
store them in a table for later use.

Cheers,
Joao Rodrigues

 

[stec00]

Thanks to everyone who has replied. Some interesting comments - but
unfortunately it seems no one wins the prize for coming up with
something usable... yet.

Just to clarify a few things:

It doesn't matter if the ID isn't quite unique - all that's needed is
for it not to be guessable by a robot. So if it's something that more
than one computer in the world share that isn't a problem. I'd
wondered about things like the way random numbers are generated - in
some languages you can provide a seed so the random numbers always
appear in a predictable way. Unfortunately this seems to be yet
another dead end as in Javascript it seems there is a seed number but
not one that makes the number sequence predictable.

As for the concerns about security, believe it or not (and it's
completely up to you what you believe, I can't prove anything here)
I'm actually trying to make things more secure, not less. I'm trying
to encrypt passwords using a key that can't easily be guessed by
robots. Unfortunately to have to enter a password each time would
defeat the object of the script as its aim is to save user effort of
logging in and minimise the number of keystrokes. Possibly I'd
consider requiring the user to login once and have the password expire
after a defined period e.g. 2 hours. But this would still require the
key being somehow saved between different websites and different
windows in any version of Firefox (well say from 1.5 upwards).

And as for the comment about IP addresses, yes I'm aware they don't
necessarily identify a user (the clue was in the word "etc.") My point
was that these convey more information than the type of ID I'm looking
for. What I'm after is just a single unique piece of information from
the client - it doesn't have to mean anything. IP addresses are more
than this e.g. they can be used to track locations, ISPs ...again in
some cases - and yes I'm also aware that the IP location information
isn't accurate in many cases.

And finally MAC address, thanks for the pointer Malcolm. I was vaguely
aware these could be spoofed but it's really not a problem - they are
sufficiently nearly unique to be perfectly usable if only they could
be got hold of. Interesting that they can be obtained using a Firefox
Extension - still I think this particular app has to be a GreaseMonkey
script - for now at least.

So what have we got so far - well nothing really usable I don't think.
Perhaps the best option at the moment is to use something like the
text from the add-ons from the UserAgent, perhaps combined with the
user's operating system and timezone. Obviously this wouldn't be an
unchanging key so not ideal but maybe when the key changes the
information has to be updated. As I say, not ideal. But unless
something turns up soon it's looking like it's going to have to be
some kind of compromise...

 

[Jorge]

(...)
The problem is that anybody using the user's navigator(s) will be seen
as the right owner ...

That's why the session cookie must expire (at the server-side) after a
certain time (of inactivity), and why there's usually a "disconnect"
button that -among other things- deletes the session cookie...

But, as you say, even if the server could tell apart the exact machine
(say, by its MAC address), that would not mean that the *current user*
is still the same person that the one that authenticated two hours
ago... so, most sites will request a re-authentication before allowing
you to touch important data, e.g. before a password change or a money
transfer...

 

[iryndin]

Thanks to everyone who has replied. Some interesting comments - but
unfortunately it seems no one wins the prize for coming up with
something usable... yet.

Just to clarify a few things:

It doesn't matter if the ID isn't quite unique - all that's needed is
for it not to be guessable by a robot. So if it's something that more
than one computer in the world share that isn't a problem. I'd
wondered about things like the way random numbers are generated - in
some languages you can provide a seed so the random numbers always
appear in a predictable way. Unfortunately this seems to be yet
another dead end as in Javascript it seems there is a seed number but
not one that makes the number sequence predictable.

As for the concerns about security, believe it or not (and it's
completely up to you what you believe, I can't prove anything here)
I'm actually trying to make things more secure, not less. I'm trying
to encrypt passwords using a key that can't easily be guessed by
robots. Unfortunately to have to enter a password each time would
defeat the object of the script as its aim is to save user effort of
logging in and minimise the number of keystrokes. Possibly I'd
consider requiring the user to login once and have the password expire
after a defined period e.g. 2 hours. But this would still require the
key being somehow saved between different websites and different
windows in any version of Firefox (well say from 1.5 upwards).

And as for the comment about IP addresses, yes I'm aware they don't
necessarily identify a user (the clue was in the word "etc.") My point
was that these convey more information than the type of ID I'm looking
for. What I'm after is just a single unique piece of information from
the client - it doesn't have to mean anything. IP addresses are more
than this e.g. they can be used to track locations, ISPs ...again in
some cases - and yes I'm also aware that the IP location information
isn't accurate in many cases.

And finally MAC address, thanks for the pointer Malcolm. I was vaguely
aware these could be spoofed but it's really not a problem - they are
sufficiently nearly unique to be perfectly usable if only they could
be got hold of. Interesting that they can be obtained using a Firefox
Extension - still I think this particular app has to be a GreaseMonkey
script - for now at least.

So what have we got so far - well nothing really usable I don't think.
Perhaps the best option at the moment is to use something like the
text from the add-ons from the UserAgent, perhaps combined with the
user's operating system and timezone. Obviously this wouldn't be an
unchanging key so not ideal but maybe when the key changes the
information has to be updated. As I say, not ideal. But unless
something turns up soon it's looking like it's going to have to be
some kind of compromise...

Steve,

it seems to me that your overestimate ;-) your needs in secure IDs.
You can quietly rely on other systems implementations, for example,
this can be MySQL UUID function (see
http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_uuid).
What kind of applications do you develop with such high requirements
to secure IDs? Are these requirements _really_ so high that usual
UUIDs generators aren't enough for it? This sounds pretty interesting,
can you highlight why you requirements are so high?

Best regards,
Ivan Ryndin.
Java Dev Notes http://jdevnotes.blogspot.com

 

[Michael J. Ryan]

I have an javascript application that needs to generate a unique ID
that will identify the client. It doesn't really matter what this ID
is, a number, string or even set of ascii codes would be fine - as
long as it is unique or nearly unique. The ID needs to be something
that can be worked out just from the client's info. Ideally it would
be done in straight javascript but if this isn't possible I'd even
consider an AJAX request that got the info from a server. I've got a
server that's running PHP so this would be the preferred server side
language if that option is chosen.

function genUID() {
var ret = (new Date()).valueOf().toString(16);
while (ret.length < 32)
ret += Mat.floor(Math.random() << 0xFFFFFFF).toString(16);
return ret.substr(0,32);
}

this gives you effectively a hex CombGuid/UUID value minus the dashes, easily
converted to a binary value for db storage.

--
Michael J. Ryan - http://tracker1.info/

.... B5: The bitch of it is that you probably did the right thing. But you did
it in the wrong way. In the inconvenient way. Now you have to pay the penalty
for that. I know it stinks, but that's the way it is.

 

[Dr J R Stockton]

In comp.lang.javascript message <5c917eb1-6b85-47b9-8f23-035b879d2d7e@a3
6g2000yqc.googlegroups.com>, Wed, 17 Jun 2009 15:12:40, stec00

It doesn't matter if the ID isn't quite unique - all that's needed is
for it not to be guessable by a robot. So if it's something that more
than one computer in the world share that isn't a problem. I'd
wondered about things like the way random numbers are generated - in
some languages you can provide a seed so the random numbers always
appear in a predictable way. Unfortunately this seems to be yet
another dead end as in Javascript it seems there is a seed number but
not one that makes the number sequence predictable.

That applies to the built-in generator (which varies from browser to
browser. One can write one's own, seedable, generator; it will probably
be slower, but not too slow.

See <URL:http://www.merlyn.demon.co.uk/js-randm.htm>.

It's a good idea to read the newsgroup c.l.j and its FAQ. See below.

 

[stec00]

Thanks for the further replies. All good comments but some are still
unfortunately just slightly missing the point I feel. The key thing
here is I'm looking for something that is:-

(a) unique (or "nearly unique") for a particular client *and*
(b) derivable for that client at any point in time *and*
(c) ideally never changes for a particular client

So anything that just involves calculating a unique ID (e.g. based on
time) won't cut it here I'm afraid - the time or anything calculated
from it, however complex won't tell me I'm using this laptop! Whereas
if Firefox say stores some ID that is unique for each installation
then bingo!

The frustration here is I feel I'm nearly there with a lot of ideas
but none of them quite work. Here's a few examples:

(1) Use navigator.userAgent (or part of it)? Not really unique enough,
a determined robot could trawl through a list of possible userAgents
and guess the key. Also, this will change over time e.g. if the
browser version is updated.
(2) Use navigator.mimeTypes and/or navigator.plugins, perhaps all
serialised / concatenated into a big string? Probably more unique but
suffers from changing (e.g. if the user installs another plugin).
(3) Make an AJAX call to a server, which performs a function on the IP
address (e.g. encrypts it using a key only known to the server) and
possibly also takes in part of the userAgent string as a parameter for
further distinguishing between multiple users at a single IP. This is
perhaps the best option so far but I'd prefer not to use AJAX if I can
help it as there's no guarantee of how long it takes (and it makes the
code more complicated!) And it isn't perfect, will never completely
identify the client - but is probably "good enough" in that sense.

(4) The above ideas are all based on limited current knowledge...was
hoping someone might know of a better way to insert here. Any more
suggestions gratefully received but please try to understand the
question before posting.

Thanks again,
Steve

 

[stec00]

Have you explained why you want to do this in order for people to

understand the question.

Richard.

Hi Richard,

Thanks for the reply.

The reason is I'm developing a GreaseMonkey "universal autologin"
script that will automatically log a user into any website they have
chosen to save login details for - without *any* key presses. The
details would be encrypted and stored in globalStorage for each site.
Hadn't fully described this before as I don't want everyone to come
down like a ton of bricks on the security implications of doing this!
Of course there are *big* security implications here and they require
considerable thought! And lots of other issues about it that could be
discussed. But would prefer these were subjects for a different thread
and we just focus on the orginal question...

Think the solution is maybe going to have to be a bit basic/techie in
that each user will be forced to modify the key directly in the
script. The key value would initially be something like "changeme" and
a message would popup if they'd neglected to change it. The overall
effect would then be that login details were encrypted under a key
that could easily be found out by someone who stole the computer - but
the important thing is it wouldn't be derivable by a clever hacker in
Internet-land.

It's probably yet another topic but I was also wondering whether it
would be possible to store a single key for all sites that was entered
by the user rather than hard-coded. Had first considered the
possibility of storing this in a cookie. But a cookie is specific to a
particular domain and so is globalStorage - doesn't work with TLDs in
later versions of Firefox. So I was thinking, would it be possible for
GreaseMonkey to create some kind of hidden iFrame within the page for
a known particular domain where the key value was saved as a cookie?
Clunky and possibly pretty slow, especially if it had to be done in
all pages but just as a theoretical question really, would it work??
If not, is there an alternative way of storing a single value across
multiple sites and multiple windows?

Cheers
Steve

 

[Thomas 'PointedEars' Lahn]

The reason is I'm developing a GreaseMonkey "universal autologin"
script that will automatically log a user into any website they have
chosen to save login details for - without *any* key presses. The
details would be encrypted and stored in globalStorage for each site.

Why, oh why, have you not said that in the first place? :-(

The login information is already stored encrypted per-site if the user
wishes it, in the user profile folder, and restored from there via form
auto-complete. AFAICS, the only thing you need to do is to check onload if
the fields are already filled and if yes, submit the corresponding form.

The accessibility of globalStorage does not extend beyond a single
Gecko-based user agent anyway, so the question of how to generate a
client-unique ID is moot.

Good luck.

Hadn't fully described this before as I don't want everyone to come
down like a ton of bricks on the security implications of doing this!

Well, nice work ...

<http://jibbering.com/faq/#posting> (How many times ...?)


PointedEars

 

[Jeremy J Starcher]

Hi Richard,

Thanks for the reply.

The reason is I'm developing a GreaseMonkey "universal autologin" script
that will automatically log a user into any website they have chosen to
save login details for - without *any* key presses. The details would be
encrypted and stored in globalStorage for each site.

Under Grease Monkey, there are better options that globalStorage. I'd
recommend using GM_setValue and GM_getValue. (See below)

As for encryption -- don't bother. It would only slow a hacker down by a
few seconds and gives the user a false sense of security.

Hadn't fully
described this before as I don't want everyone to come down like a ton
of bricks on the security implications of doing this! Of course there
are *big* security implications here and they require considerable
thought! And lots of other issues about it that could be discussed. But
would prefer these were subjects for a different thread and we just
focus on the orginal question...

The latest versions of GreaseMonkey are very secure... I'm not away of
any security limitations in them. They run under their own window (with
the actual document window being called "unsafe_window" for a good
reason). Things are heavily sandboxed so you can only use a small subset
of the DOM methods, but they will do everything you need.

Think the solution is maybe going to have to be a bit basic/techie in
that each user will be forced to modify the key directly in the script.
The key value would initially be something like "changeme" and a message
would popup if they'd neglected to change it. The overall effect would
then be that login details were encrypted under a key that could easily
be found out by someone who stole the computer - but the important thing
is it wouldn't be derivable by a clever hacker in Internet-land.

No need to have them modify it in the script. Its a little more work,
but GreaseMonkey scripts -can- pop up a floating DIV and request
information. Its also a far cleaner method.

It's probably yet another topic but I was also wondering whether it
would be possible to store a single key for all sites that was entered
by the user rather than hard-coded. Had first considered the possibility
of storing this in a cookie. But a cookie is specific to a particular
domain and so is globalStorage - doesn't work with TLDs in later
versions of Firefox. So I was thinking, would it be possible for
GreaseMonkey to create some kind of hidden iFrame within the page for a
known particular domain where the key value was saved as a cookie?
Clunky and possibly pretty slow, especially if it had to be done in all
pages but just as a theoretical question really, would it work?? If not,
is there an alternative way of storing a single value across multiple
sites and multiple windows?

Again, GM_setValue and GM_getValue. Save your data in an object and use
GM_setValue("passwords", mydata.toSource())

and mydata = eval( "(" + GM_getValue("passwords") + ")" )



For this kind of script, I would ONLY support GreaseMonkey and not any of
the other user-script engines like IE7PRO (for IE). Opera nor Konq have
any form of set_Value or getValue, so they are they don't matter.

GreaseMonkey has been worked over by security forces and is nice. The
others are cheap knock-offs.

 

[Thomas 'PointedEars' Lahn]

Correct me if I'm wrong, but hasn't JavaScript access to these values
been disabled because it was a (major) security risk?

Obviously it has not.

There was a time when any script on the page could read pre-filled
login fields in Firefox (v1.x or earlier, I believe). This has been fixed,

Maybe you are referring to cross-frame or cross-domain scripting?

but I don't know if the restrictions would also apply to a Greasemonkey
script.

Well, you could have cared to test it (within almost two hours). I did in
Firefox/Iceweasel 3.0.11. Firebug 1.4X.a1 can read .value and .value.length
of an input[type="password"], a bookmarklet can read them, an inserted
script can read them, and a in-document script can read them, even on a
secured (HTTPS) site, so I see no good reason why a Greasemonkey script
couldn't read them.

In this case, checking against .value.length should suffice. That is,
if there is only one password stored for that profile and site.


PointedEars

 

[stec00]

Some interesting further comments, especially Jeremy - hadn't seen
GM_setValue/GM_getValue & am pretty excited about these! On first
glance these look to be *exactly* what I need - look forward to trying
them out soon...unfortunately no time to do so right now. Forgive the
ignorance but a couple of q's spring to mind: How does GreaseMonkey
store these values - presumably must be stored on the local drive
somewhere - and if so, do you know if GM does its own encryption out
of the box? Take your point about encryption, I'm sure it wouldn't
pose any kind of obstacle to a hacker but might just be useful in
stopping a casual non-hacking observer from seeing passwords etc.
Anyway, if it is possible to do all this through these new methods
rather than in-build storage I probably won't have this problem.

As far as using the built-in password store, a good suggestion but
would prefer not to use this as have plans to allow selection of
different logins as an option in future versions of the script. (And
it would be nice if the script worked for anyone who just installed it
without having to modify Firefox settings.) Don't worry, I've no plans
to extend this to other browsers / the "GM-like" wrappers mentioned -
think it'll be hard enough to get it working properly on Firefox in
the little spare time available!

Cheers
Steve