4 ms·

>We made the session IDs sufficiently hard to guess... We believe we made the session IDs sufficiently hard to guess... FTFY

by natch 10y ago

nardi 10y ago
It's not hard to make things hard to guess.
mburns 10y ago
> We believe we made the session IDs sufficiently hard to guess... Couldn't you say that about most any secret? (I believe my ssh key is sufficiently hard to guess...)
zokier 10y ago
Its just a 20 byte random token, not exactly rocket science. Cursory glance on the code shows that its generated using crypto/rand which is exactly how it should be done. Some degree of skepticism is always good especially regarding security, but when verifying something takes like 2 minutes or something, maybe do that before posting disparaging comments on HN
- natch 10y ago
  Verifying randomness is not a 2 minute task.
  - heavenlyhash 10y ago
    It... really is sometimes. GP did so. I just verified. Here is the where the session ID is picked: https://github.com/gravitational/teleconsole/blob/54c8bddb477e84f63a5bf092f95853b485ede0f0/clt/api_client.go#L121 https://github.com/gravitational/teleconsole/blob/54c8bddb47... Here is the source of that helper function: https://github.com/gravitational/teleport/blob/9bde8462f272e22ced32999afea349881ec0f45a/lib/utils/rand.go#L32 https://github.com/gravitational/teleport/blob/9bde8462f272e... And at this depth, we can stop; https://golang.org/pkg/crypto/rand/ https://golang.org/pkg/crypto/rand/ is documented as "a cryptographically secure pseudorandom number generator". If you would like to audit that, I commend you, but would also attest that the Go standard library, when it declares cryptographically secure, is about as reliable as it gets. Total time to verify: about two minutes. I would understand if it's slightly slower for someone not previously experienced with golang and thus not knowing to grep for "crypto" in "crypto/rand", and I do not wish to make light of your (valid) desire that we all take these matters seriously. But sometimes things are simply correct. This, joyously, is one of those times.
    - natch 10y ago
      This is faith-based verification. You'd need to get down into the math, and even then, we're talking about stuff where it's not clear where the bleeding edge research ends and the real randomness begins. Worse, library methods can be stubbed out. Did you verify that this one is not stubbed out at this time, on your platform, in your particular jurisdiction? No? I didn't think so. Note my only complaint is they don't identify their assertion as a belief.
      - heavenlyhash 10y ago
        I don't know what to say. I could write you an entire dissertation on the math, my previous formal education in cryptography and randomness, my reading of that code inside the golang standard library, and so forth. But you seem to be stating that you're literally unsatisfiable by any series of words from any other humans on the planet at any level of transitivity at all, even one hop. So it begs the question of why engage in communication at all, when the endgame you're interested in seems be defeat in detail. > Did you verify that this one is not stubbed out at this time, on your platform, in your particular jurisdiction? No? I did, in fact. I've performed full diverse double compilation on the golang compiler and standard library using different toolchains and different versions of the toolchains and verified the binary results. I am indeed quite confident that this random method is not stubbed out in any place on earth you or I are likely to find it. Reconsider your presumptuous dismissal. The layer below this in the golang standard library is documented as follows: // On Linux, Reader uses getrandom(2) if available, /dev/urandom otherwise. // On OpenBSD, Reader uses getentropy(2). // On other Unix-like systems, Reader reads from /dev/urandom. // On Windows systems, Reader uses the CryptGenRandom API. If you find those APIs to be insufficient on those operating systems... go you. You have some security papers to publish. I also believe the universe is made of four dimensions, one of which is time and moves almost entirely forwards, if you'd like to carry out any more attacks on things that are "faith-based" because they're insufficiently sussed out here. Might be a little out-of-scope on whether or not Teleconsole got their session IDs right, though.
        natch 10y ago

>We made the session IDs sufficiently hard to guess... We believe we made the session IDs sufficiently hard to guess... FTFY

by natch 10y ago

>We made the session IDs sufficiently hard to guess... We believe we made the session IDs sufficiently hard to guess... FTFY

nardi 10y ago

It's not hard to make things hard to guess.

mburns 10y ago

> We believe we made the session IDs sufficiently hard to guess... Couldn't you say that about most any secret? (I believe my ssh key is sufficiently hard to guess...)

zokier 10y ago

Its just a 20 byte random token, not exactly rocket science. Cursory glance on the code shows that its generated using crypto/rand which is exactly how it should be done. Some degree of skepticism is always good especially regarding security, but when verifying something takes like 2 minutes or something, maybe do that before posting disparaging comments on HN

natch 10y ago
Verifying randomness is not a 2 minute task.
- heavenlyhash 10y ago
  It... really is sometimes. GP did so. I just verified. Here is the where the session ID is picked: https://github.com/gravitational/teleconsole/blob/54c8bddb477e84f63a5bf092f95853b485ede0f0/clt/api_client.go#L121 https://github.com/gravitational/teleconsole/blob/54c8bddb47... Here is the source of that helper function: https://github.com/gravitational/teleport/blob/9bde8462f272e22ced32999afea349881ec0f45a/lib/utils/rand.go#L32 https://github.com/gravitational/teleport/blob/9bde8462f272e... And at this depth, we can stop; https://golang.org/pkg/crypto/rand/ https://golang.org/pkg/crypto/rand/ is documented as "a cryptographically secure pseudorandom number generator". If you would like to audit that, I commend you, but would also attest that the Go standard library, when it declares cryptographically secure, is about as reliable as it gets. Total time to verify: about two minutes. I would understand if it's slightly slower for someone not previously experienced with golang and thus not knowing to grep for "crypto" in "crypto/rand", and I do not wish to make light of your (valid) desire that we all take these matters seriously. But sometimes things are simply correct. This, joyously, is one of those times.
  - natch 10y ago
    This is faith-based verification. You'd need to get down into the math, and even then, we're talking about stuff where it's not clear where the bleeding edge research ends and the real randomness begins. Worse, library methods can be stubbed out. Did you verify that this one is not stubbed out at this time, on your platform, in your particular jurisdiction? No? I didn't think so. Note my only complaint is they don't identify their assertion as a belief.
    - heavenlyhash 10y ago
      I don't know what to say. I could write you an entire dissertation on the math, my previous formal education in cryptography and randomness, my reading of that code inside the golang standard library, and so forth. But you seem to be stating that you're literally unsatisfiable by any series of words from any other humans on the planet at any level of transitivity at all, even one hop. So it begs the question of why engage in communication at all, when the endgame you're interested in seems be defeat in detail. > Did you verify that this one is not stubbed out at this time, on your platform, in your particular jurisdiction? No? I did, in fact. I've performed full diverse double compilation on the golang compiler and standard library using different toolchains and different versions of the toolchains and verified the binary results. I am indeed quite confident that this random method is not stubbed out in any place on earth you or I are likely to find it. Reconsider your presumptuous dismissal. The layer below this in the golang standard library is documented as follows: // On Linux, Reader uses getrandom(2) if available, /dev/urandom otherwise. // On OpenBSD, Reader uses getentropy(2). // On other Unix-like systems, Reader reads from /dev/urandom. // On Windows systems, Reader uses the CryptGenRandom API. If you find those APIs to be insufficient on those operating systems... go you. You have some security papers to publish. I also believe the universe is made of four dimensions, one of which is time and moves almost entirely forwards, if you'd like to carry out any more attacks on things that are "faith-based" because they're insufficiently sussed out here. Might be a little out-of-scope on whether or not Teleconsole got their session IDs right, though.
      - natch 10y ago