unique password everytime on click of button

  • Thread starter Thread starter Abhishek
  • Start date Start date
A

Abhishek

Hi!

I need to create a unique password everytime i click a button .
what technique/Algo should i follow.

Abhishek
 
I forgaot to add that I do not want to use any third party tools or any
external program
Abhishek
 
Abhishek said:
Hi!

I need to create a unique password everytime i click a button .
what technique/Algo should i follow.
Click to expand...

I'd start with System.Guid.NewGuid(), which generates a new Guid each time,
presumably intended to be unique. (Though given the random appearance of
the results, I'm not sure how unique it really is. For example, it doesn't
appear to use the MAC address, the natural way to ensure that two different
machines won't generate duplicate Guids.)
 
Mike Schilling said:
I'd start with System.Guid.NewGuid(), which generates a new Guid each time,
presumably intended to be unique. (Though given the random appearance of
the results, I'm not sure how unique it really is. For example, it doesn't
appear to use the MAC address, the natural way to ensure that two different
machines won't generate duplicate Guids.)
Click to expand...
Thanks I knew i could use GUID's but did not know how to generate them thru
C#
Thanks a lot

Abhishek
 
I believe they used to use the MAC address but stopped because a GUID could
be traced back to the computer that originated it and that created some
privacy concerns. They apparently use some other technique to ensure
randomness and no collisions between GUIDs.

- JW
 
Jonathan Woodbury said:
I believe they used to use the MAC address but stopped because a GUID could
be traced back to the computer that originated it and that created some
privacy concerns. They apparently use some other technique to ensure
randomness and no collisions between GUIDs.
Click to expand...

I suspect they don't actually *ensure* that there aren't any
collisions. From a theoretical point of view, they can't - Guids have a
finite size (128 bits). While in a practical sense you can't call
NewGuid that many times, there's nothing to stop it from being done
theoretically.

Like hashes, I suspect it's just very, very unlikely that you'll get
two identical Guids.
 
Jon Skeet said:
I suspect they don't actually *ensure* that there aren't any
collisions. From a theoretical point of view, they can't - Guids have a
finite size (128 bits). While in a practical sense you can't call
NewGuid that many times, there's nothing to stop it from being done
theoretically.
Click to expand...

Actually, you can ensure it, and the original spec for UUIDs shows how. I
don't recall all the details, but it's basically:

There are 6 bits of UUID version and type information.

The last 48 bits are the MAC address. All are guaranteed unique by the
manufacturer, so the problem of uniqueness is now restricted to a single
machine.

There are 14 bits called the "clock sequence". IIRC, it's intended that
each process (or thread) on the machine that produces UUIDs gets a unique
clock sequence number either from the OS or from a piece of specialized
hardware.

This leaves 60 bits for the time, which represent the absolute time of UUID
creation in 100s of nanoseconds. That's good for about 3500 years. (You're
right that the algorithm breaks down after that. Sue me :-)

If a thread is asked to generate more than 1 UUID every 100 nanoseconds, it
can either ask for a new clock sequence, or just wait.

I've written UUID generators that follow this algorithm (more or less
closely), and they work well enough. Clearly .NET doesn't, though I suppose
it could be doing so and then doing a reversible encryption of the result.
 
Mike Schilling said:
Actually, you can ensure it, and the original spec for UUIDs shows how. I
don't recall all the details, but it's basically:

There are 6 bits of UUID version and type information.

The last 48 bits are the MAC address. All are guaranteed unique by the
manufacturer, so the problem of uniqueness is now restricted to a single
machine.
Click to expand...

Except they're not, because these days many devices allow you to set
MAC addresses. As Jonathan said, using the MAC address also introduces
privacy concerns. As far as I know, there's nothing which can
definitively be used in all processors that Windows runs under and
which will guarantee to give a number which is unique to that computer
forever.
There are 14 bits called the "clock sequence". IIRC, it's intended that
each process (or thread) on the machine that produces UUIDs gets a unique
clock sequence number either from the OS or from a piece of specialized
hardware.
Click to expand...

Again though, how can that be unique? 14 bits only gets 16384
possibilities. If I run a hundred processes, each with 10 threads, then
set the clock back and do it again and again, you soon end up with
there having been one point in time (as far as the computer is
concerned) which has had more than 16384 threads running at the same
time. They can't all have different numbers.
This leaves 60 bits for the time, which represent the absolute time of UUID
creation in 100s of nanoseconds. That's good for about 3500 years. (You're
right that the algorithm breaks down after that. Sue me :-)

If a thread is asked to generate more than 1 UUID every 100 nanoseconds, it
can either ask for a new clock sequence, or just wait.
Click to expand...

And what happens if the user adjusts the clock back in time? Again, the
*guarantee* of uniqueness is gone.
I've written UUID generators that follow this algorithm (more or less
closely), and they work well enough. Clearly .NET doesn't, though I suppose
it could be doing so and then doing a reversible encryption of the result.
Click to expand...

As I said, "works well enough" is one thing - but to guarantee
uniqueness is a different matter.
 
Mike said:
Actually, you can ensure it, and the original spec for UUIDs shows how. I
don't recall all the details, but it's basically:

There are 6 bits of UUID version and type information.

The last 48 bits are the MAC address. All are guaranteed unique by the
manufacturer, so the problem of uniqueness is now restricted to a single
machine.

There are 14 bits called the "clock sequence". IIRC, it's intended that
each process (or thread) on the machine that produces UUIDs gets a unique
clock sequence number either from the OS or from a piece of specialized
hardware.

This leaves 60 bits for the time, which represent the absolute time of UUID
creation in 100s of nanoseconds. That's good for about 3500 years. (You're
right that the algorithm breaks down after that. Sue me :-)

If a thread is asked to generate more than 1 UUID every 100 nanoseconds, it
can either ask for a new clock sequence, or just wait.

I've written UUID generators that follow this algorithm (more or less
closely), and they work well enough. Clearly .NET doesn't, though I suppose
it could be doing so and then doing a reversible encryption of the result.
Click to expand...
A while back, in my network support days, I ran into two 3com cards with
identical MAC addresses. The DHCP server ran upstairs and threw itself
from the roof in dispair! Nothing generated is "guaranteed" unigue in
the same sense that there is no true random number generator, and that
no system is 100% secure. the idea is to come close enough.

--

____________________________________________
Scott C. Reynolds - Tales From the SharpSide
http://www.scottcreynolds.com
(e-mail address removed)

*****Get your SharpSide Swag!******
http://www.cafepress.com/sharpside/
***********************************
 
A while back, in my network support days, I ran into two 3com cards with
identical MAC addresses. The DHCP server ran upstairs and threw itself
from the roof in dispair! Nothing generated is "guaranteed" unigue in the
same sense that there is no true random number generator, and that no
system is 100% secure. the idea is to come close enough.
Click to expand...

Each manufacturer is assigned a range of MAC addreseses; what you're
describing is a failure in 3COM's processes (or quality control.)
 
Back
Top