Last character of a jose.Encrypt() token can be altered without detection during jose.Decode()? about jose2go HOT 7 CLOSED

Given 6 examples, which one you concern as invalid behavior?

from jose2go.

My assumption was that ANY change whatsoever (replacement, addition, deletion, etc) of the token string should render it invalid. Am I wrong?

from jose2go.

which gives only token1 and token2 examples? As far as i can see rest are failed as expected?

from jose2go.

Correct.
Incidentally, while trying to break this I made a testbed dealing with strings, bytes, runes, etc. for length, replacement of chars in the token and so on. I'm not finished with it yet, stuck in where the error "jwt.Decode() expects token of 3 or 5 parts, but was given: 4 parts" is coming from. I'll get back to this tomorrow.

from jose2go.

Okay, let answer one by one:

1. 3 or 5 parts is simple. JWT token consists of several parts separated by comma '.', Signed tokens - 3 parts, encrypted - 5. 4 parts is not defined by spec, so it generates error.
2. I see sometimes you get panic, sometimes error. Sounds inconsistent to me. As i mentioned is other issue, i think i redo to produce error always (don't panic ;)
3. About your alter characters issue. This is base64 decoding thing. You are altering last part of token (AuthTag) Q_U_HxdpjD_PAP0Tpsqf0w. And base64 decoding produces same results for altered strings. You can convince yourself by running next sample:

package main

import (
    "fmt"
    "github.com/dvsekhvalnov/jose2go/arrays"
    "github.com/dvsekhvalnov/jose2go/base64url"
)

func main() {

    sig0 := "Q_U_HxdpjD_PAP0Tpsqf0w"
    sig1 := "Q_U_HxdpjD_PAP0Tpsqf0x"
    sig2 := "Q_U_HxdpjD_PAP0Tpsqf0y"

    fmt.Printf("len(sig0) % 4=%v\n", len(sig0)%4)

    data0, _ := base64url.Decode(sig0)
    data1, _ := base64url.Decode(sig1)
    data2, _ := base64url.Decode(sig2)

    fmt.Printf("\ndata0=%v\n", arrays.Dump(data0))
    fmt.Printf("\ndata1=%v\n", arrays.Dump(data1))
    fmt.Printf("\ndata2=%v\n", arrays.Dump(data2))
}

and for explanation see http://stackoverflow.com/questions/29941270/why-do-base64-decode-produce-same-byte-array-for-different-strings

from jose2go.

Yes, that's exactly where I was going with my own conclusion, thanks for the clarity and proof. I tried to break it at various points and with diff chars along the length of the token string, the end padding zone was the most fertile problem part. :)

As I said previously I tried to treat the generated token as base64 but that failed.

_, err := base64.StdEncoding.DecodeString(tokenString)

from jose2go.

I think it is safe to close. Fixed token parsing to return error instead of panic.

from jose2go.