unique password everytime on click of button

[Abhishek]

Hi!

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

Abhishek

[Abhishek]

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

[Mike Schilling]

"Abhishek" <ab******@alwayshelpful.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

Hi!

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

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.)

[Abhishek]

"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:eU*************@TK2MSFTNGP11.phx.gbl...

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.)

Thanks I knew i could use GUID's but did not know how to generate them thru
C#
Thanks a lot

Abhishek

[Jonathan Woodbury]

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

"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:eU*************@TK2MSFTNGP11.phx.gbl...

"Abhishek" <ab******@alwayshelpful.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

Hi!

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

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.)

[Jon Skeet [C# MVP]]

Jonathan Woodbury <[e-mail]> wrote:

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.

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 - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Mike Schilling]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Jonathan Woodbury <[e-mail]> wrote:

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.

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.

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.

[Jon Skeet [C# MVP]]

Mike Schilling <ms*************@hotmail.com> wrote:

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.
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.

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.
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.
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.

As I said, "works well enough" is one thing - but to guarantee
uniqueness is a different matter.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Mike Schilling]

"Scott C. Reynolds" <sr*********@noemail.nospam> wrote in message
news:OI**************@TK2MSFTNGP09.phx.gbl...

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.

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