• (disco) 
    string guidInt = "";

    :rolleyes:

  • (disco) in reply to VinDuv

    Maybe it's a homage to Grandmaster Flash? "It's like a jungle sometimes it makes me wonder / How I keep from going under"

  • (disco)
    GUIDs aren't a good source of randomness

    Depends very much on the TYPE of Guid. Type 4 Guids are 122 bit random numbers and their "quality" as a Guid is directly correlated to the randomness of the generator.

    There are almost no implementations today which still use Type 1 Guids.

  • (disco)

    A real Rube Goldberg machine would do the actual work across at least six classes with the deepest twelve function calls deep. That's how it is in parts of our codebase!

  • (disco) in reply to Zemm
    Zemm:
    A real Rube Goldberg machine would do the actual work by **using a DB abstraction layer to call a stored procedure, which would in turn use COM to open an Excel document and run a VBA macro which would fetch the result from a REST webservice written in node.js**
    FTFY
  • (disco) in reply to VinDuv

    Challenge accepted! If I had the time, at least

  • (disco) in reply to VinDuv

    I feel shamed. Though you did forget the wooden table!

  • (disco) in reply to Zemm
    Zemm:
    Though you did forget the wooden table

    There’s probably a node.js module somewhere on GitHub which does that...

  • (disco) in reply to VinDuv

    Something like this? https://github.com/lwille/node-gphoto2

    A Node.js wrapper for libgphoto2. Useful for remote controlling of DSLRs and other digital cameras supported by gphoto2.

    Batteries, camera or wooden table not included.

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    Depends very much on the TYPE of Guid. Type 4 Guids are 122 bit random numbers and their "quality" as a Guid is directly correlated to the randomness of the generator.

    But that depends on an implementation detail. It would be just as wrong as using a Guid to figure out a computer's MAC address twenty years ago.

  • (disco) in reply to JBert
    JBert:
    Something like this?

    as someone who enjoys working with NodeJS..... there's a lot of things that people use NodeJS for that make absolutely no sense whatsoever....

  • (disco)
    TheCPUWizard:
    Depends very much on the TYPE of Guid. Type 4 Guids are 122 bit random numbers and their "quality" as a Guid is directly correlated to the randomness of the generator.

    well not quite.... they aren't pure random there's one hex digit that's fixed and another that's got some sort of odd requirement that i'm not sure what it means....

    function uuid() {
    return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g,
        function (c) {
            var r = Math.random() * 16 | 0,
                v = c === 'x' ? r : (r & 0x3 | 0x8);
            return v.toString(16);
        });
}

    Files under: http://jsperf.com/node-uuid-performance/19

  • (disco) in reply to accalia

    According to RFC4122, that y is the first four bits of the clock_seq_hi_and_reserved field; what it's used for, no idea.

  • (disco) in reply to RaceProUK

    i am enlightened. i know know what it means.... still NFC what it's used for.

    but i do know that discourse will reject a UUID that sets the bits in that place wrong (i did try without the bitwise math and if the bits got messed up for that digit discourse wouldn't talk to my bot.)

  • (disco) in reply to accalia

    It's a requirement of v4 GUIDs, so in that case, Discourse is doing it ri- *universe implodes*

  • (disco) in reply to RaceProUK

    it's more likely they're parsing it using a built in ruby UUID parser (for raisins) and that's what's blowing up.

    maybe @riking cna confirm or refute that theory?

  • (disco) in reply to accalia
    accalia:
    built in ruby UUID parser (for raisins)
    The raisin being that, if someone has provided a suitable API, why duplicate the effort? ;) Maybe some of this should be Jeffed to Meta?
  • (disco) in reply to RaceProUK
    RaceProUK:
    The raisin being that, if someone has provided a suitable API, why duplicate the effort?

    but that's doing it right!

    RaceProUK:
    Maybe some of this should be Jeffed to Meta?

    an excellent point.

    would one of our lovely local TL4 users kindly jeff these UUID posts to a new topic?

  • (disco)

    Worth mentioning is that in some random number generation libraries seeding is a no-op, because the amount of entropy they can pull out of /dev/random is much greater than any number seed a programmer could easily come up with.

    One that I think might be worth trying to generate random passwords, though, just to see what would happen:

    1. Take a page from something written in a language that doesn't use the Roman alphabet. Say, the Epic of Gilgamesh, Hebrew biblical text, the Koran, or the Art of War.
    2. Generate an image of that page (photographing it on a wooden table optional).
    3. Run a small portion of that image through English-only OCR.
  • (disco) in reply to accalia
    accalia:
    and another that's got some sort of odd requirement that i'm not sure what it means....

    http://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm

    [version 4 guids] the first two bits of 'data4' are 1 and 0 [with the rest being pseudo-random] (so the first hex digit of 'data4' is 8, 9, A, or B),

  • (disco) in reply to EatenByAGrue
    EatenByAGrue:
    Worth mentioning is that in some random number generation libraries ***seeding is a no-op***, because the amount of entropy they can pull out of /dev/random is much greater than any number seed a programmer could easily come up with.

    Even when the programmer wants a reproducible series of pseudo-random numbers every invocation?

  • (disco) in reply to PJH

    If you want a specific series of numbers, say, for testing purposes, mock out your random-number function to give you that series of numbers.

  • (disco) in reply to EatenByAGrue
    EatenByAGrue:
    Worth mentioning is that in some random number generation libraries seeding is a no-op, because the amount of entropy they can pull out of /dev/random is much greater than any number seed a programmer could easily come up with.

    Not a terribly good idea. Pseudo random numbers (the ones that require a seed) don't use any stored system entropy. If you want a pseudo-random and the system gives you a true random in its place (/dev/random[1]), then you may be harming either the security or the performance of the entire system.

    [1] The current implementation of /dev/random isn't a deterministic pseudo-random sequence on most distributions.

  • (disco)

    Genius!

    This needs to be paired with the 400+ lines of code I found in the legacy codebase I am working on, which manually hashes (and "dehashes") a password into 24 digits separated by hyphens (eight groups), in client application code (not in the DB or server) in order to store the password in a "secure" form in the DB which is on the users computer.

    Even if the developer really found value in this method of hashing (instead of using one of the built-in hashing functions which are more secure), all 400 lines of code could be replaced with about 40 lines of code, at most, to achieve the same result.

    But that would have been too easy and would not show up as many many lines of code (I swear my predecessors got paid by the lines of code they created).

  • (disco) in reply to EatenByAGrue
    EatenByAGrue:
    If you want a specific series of numbers, say, for testing purposes, mock out your random-number function to give you that series of numbers.

    Real PRNGs all support generating a seeded sequence. The system entropy source is just used (sometimes) as a seed for the PRNG, often for the default “unseeded” configuration.

  • (disco) in reply to Developer_Dude
    Developer_Dude:
    which manually hashes (and "dehashes")
    Wait, "dehashes" ?!? Are you saying it can retrieve the plaintext password?

    Because then I'd rather like to know the name of this product so I never put any passwords in it. I don't want any hobyist encryption scheme leaking out information (although I'd likely generate a unique password anyway, don't want to take any chances).

  • (disco) in reply to accalia

    That's probably it, it tries to parse the Version field and your uuid has an invalid version, so it throws.

  • (disco) in reply to riking

    good enough for me! :-D

  • (disco) in reply to EatenByAGrue
    EatenByAGrue:
    seeding is a no-op

    Which would be quite WTFy if you actually need your RNG to put out a random, but consistent sequence. Say, a game with random starting conditions - if you like the map, you can store the seed and come back to it later, and you don't have to write your own pseudo-RNG.

  • (disco) in reply to Maciejasjmj
    Maciejasjmj:
    Which would be quite WTFy if you actually need your RNG to put out a random, but consistent sequence.

    That would not be a RNG; that would be a PRNG.

    Maciejasjmj:
    write your own pseudo-RNG
    Doing It Wrong. Whatever language you're using1, it already has a PRNG library function. Use it.

    1 For reasonable values of "whatever." I'm sure languages can be found that don't have one (BIT? Brainfuck? Whitespace?) If you're using a language that doesn't have one, use a different language.

  • (disco) in reply to JBert
    JBert:
    Wait, "dehashes" ?!? Are you saying it can retrieve the plaintext password?

    Suggests to me the opposite idea: The ultimate, absolutely cannot be dehashed, password hash. Everything hashes to a half-bit; a 1. So there is absolutely, positively no way to determine the original password from the hash.

    "Security," you say? Well who cares about that?

  • (disco) 
    while (guid.Contains("-"))
guid = guid.Remove(guid.IndexOf("-"), 1);

    
Ow. Ow ow ow ow ow.
  • (disco) in reply to HardwareGeek
    HardwareGeek:
    Whatever language you're using, it already has a PRNG library function. Use it.

    What if you're writing the implementation of a language? You don't always want to just use the PRNG from the underlying language; for example, the PRNG in the standard C library is not thread-safe in a nice way (there are replacements that are better, but then you're not writing portable code and that has other headaches).

    Getting PRNGs right is remarkably difficult.

    Tangentially, getting true RNGs right is even harder, by several orders of magnitude. The real difficulty is in testing; as with anything related to security, it's easy to come up with code that you can't find problems in, but really hard to ensure that nobody else can find issues…

  • (disco) in reply to dkf
    dkf:
    What if you're writing the implementation of a language?

    That's a different beast. The context of the post to which I was replying was writing your own (P)RNG for an application. I think we can agree that would be doing it wrong, yes?

  • (disco) in reply to HardwareGeek
    HardwareGeek:
    I think we can agree that would be doing it wrong, yes?

    No. :smiley: There are three main types of (P)RNG usage.

    1. Cryptography. This needs every single bit of the random numbers generated to be as difficult to guess as possible.
    2. Monte Carlo Simulation. This needs the ability to generate the same sequence of random numbers if necessary for testing, and having good spectral properties is an advantage too. (I prefer to use random normal-distribution perturbations from a grid of points, but that's a different discussion…)
    3. Normal code. Almost anything you do is good enough, to be honest. Sometimes it can be helpful to make the PRNG use thread-local storage to reduce the need for global state (and locks) but it's not that big a deal.

    Cases #1 and #2 are the ones generally accepted as needing care. Case #3 doesn't usually (except sometimes it does, threaded programming being what it is).

  • (disco) in reply to tar
    tar:
    Ow. Ow ow ow ow ow.

    fiiiiine! i'll rewrite it.....

    guid = system("echo \"" + guid + "\"|sed -e s/-//g || die \"BAD-GUID!\"");

    why teh frack was that detected as vbscript and why does vbscript frack up the formatting so much‽‽‽‽

  • (disco) in reply to tar
    tar:
        while (guid.Contains("-"))
    guid = guid.Remove(guid.IndexOf("-"), 1);

    Ow. Ow ow ow ow ow.

    And the block after that will just ignore non-numeric characters anyway!

  • (disco) in reply to dkf
    dkf:
    Cryptography. This needs every single bit of the random numbers generated to be as difficult to guess as possible.

    I know this is a complete nitpick but that's what I do (and in some jobs it pays well).

    For every single bit of a random number, "as difficult as possible" is p=0.5. The probability of guessing a random number of n bits is simply 1/(2^n). The requirement is that the generation of every single bit be independent of the bits generated so far.

  • (disco) in reply to kupfernigk
    kupfernigk:
    For every single bit of a random number, "as difficult as possible" is p=0.5.

    Specifically, it's that the chance of you guessing a bit is 0.5 even when you've got a good history of the previously generated bits and know the algorithm. That's really difficult.

  • (disco) in reply to dkf
    dkf:
    Specifically, it's that the chance of you guessing a bit is 0.5 even when you've got a good history of the previously generated bits and know the algorithm. That's really difficult.

    Random bits are available for free on the Internet.

  • (disco) in reply to dkf
    dkf:
    **Monte Carlo Simulation.** This needs the ability to generate the same sequence of random numbers if necessary for testing, and having good spectral properties is an advantage too. (I prefer to use random normal-distribution perturbations from a grid of points, but that's a different discussion…)

    This always rings my alarm bells - if I ever see, "we performed our MCS in the Cloud for extra-specialness..." I will probably lose it completely.

  • (disco) in reply to kupfernigk
    kupfernigk:
    For every single bit of a random number, "as difficult as possible" is p=0.5.

    Which is what makes encryption so difficult. Because regardless of how it might look like p=0.5 to the attacker, every bit must really be input driven with p=1.0 to permit decryption.

  • (disco) in reply to CoyneTheDup
    CoyneTheDup:
    Which is what makes encryption so difficult. Because regardless of how it might look like p=0.5 to the attacker, every bit must really be input driven with p=1.0 to permit decryption.

    Real randomness is used to generate keys.

  • (disco) in reply to dkf
    dkf:
    Specifically, it's that the chance of you guessing a bit is 0.5 even when you've got a good history of the previously generated bits and know the algorithm. That's really difficult.

    Yup, that's one up from my "The requirement is that the generation of every single bit be independent of the bits generated so far." If I had a history of all the bits generated and knew the algorithm, would that make a difference? If I did and the next bit is equiprobable, then the algorithm must be truly random. But if I have a good but partial history, it might be that, knowing the algorithm, the answer depends on how long it would take to run the algorithm from all possible seeds and find the bit sequence in the history. It's all a bit Borges Library at this point.

    My nitpick, however, was based on the use of the word "random". Random is random. No matter how clever the algorithm, if it exists than the result must be pseudo-random.

    In the Good Old Days we used to generate random numbers using the noise of special avalanche diodes, small radioactive sources, or suitably designed electron tubes. The original British government lottery, Premium Bonds, used (I believe) an electron tube as a random generator. But they were all power hungry and have the disadvantage that they can't be made pseudorandom. [edit - corrected - @tarunik points out that a radioactive RNG can be low power nowadays. However, the Hotbits RNG linked to by @Jaime is neither particularly compact - it uses a small GM tube - nor particularly low power.]

  • (disco) in reply to kupfernigk
    kupfernigk:
    In the Good Old Days we used to generate random numbers using the noise of special avalanche diodes, small radioactive sources, or suitably designed electron tubes. The original British government lottery, Premium Bonds, used (I believe) an electron tube as a random generator. But they are all power hungry and have the disadvantage that they can't be made pseudorandom.

    And such approaches are still viable today -- I'd personally go with a noise diode, myself, as such could be integrated onto an IC easily ;)

    And last I checked, radioactive sources aren't power hungry, considering you can use a solid-state detector to pick up radioactivity.

  • (disco) in reply to tarunik
    tarunik:
    And such approaches are still viable today
    I even [linked to one][1] earlier in the conversation..
  • (disco) in reply to Jaime

    Aye -- I once floated with my college roommate a similar idea based on an Americium-241 source and mounted to an add-in card, with dedicated H/W doing the timing, and returning the inter-decay intervals directly as random numbers instead of thresholding them to generate a random bitstream.

  • (disco) in reply to tarunik

    pm;

  • (disco) in reply to VinDuv

    Or it could use a camera to take a snapshot of an old TV tuned to a channel that's not operating, collect the visual static, parse it, and keep trying until it ends up being a url to a website that generates random passwords.

  • (disco) in reply to tarunik
    tarunik:
    And last I checked, radioactive sources aren't power hungry, considering you can use a solid-state detector to pick up radioactivity.

    Fair comment, and I am about to correct to read "were" power hungry.

    tarunik:
    I'd personally go with a noise diode, myself, as such could be integrated onto an IC easily
    I wouldn't want to integrate a noise diode onto a modern digital IC myself. Different technology.

Leave a comment on “Rube Goldberg's Password Generator”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article