Authorizekey allows too few characters

[baldur4464]

Hello, I am currently working on a project that automatically checks incoming messages for plausibility. During development, I came across a problem.

My project emulates a Central System (CS) and I first tested it with a Chargepoint (CP) simulation (Open-OCPP). The CP was always able to connect to the CS.

When we then tried to test my project on a real charge point, no connection was established. This always resulted in a 404 Websocket Upgrade Failure. Since we had no further debug information, I used Wireshark to check the incoming and outgoing messages.

I noticed that the CP's AuthorizeKey contains more than 20 characters. I then checked in your code how this key is checked and there I noticed that the length must be between 16 - 20 characters long and if this condition is not met, the websocket cannot be established.

Now the question arises, is there a reason why the characters are limited to 20 characters? Otherwise, I would like to suggest increasing the number of characters, as I do not see a security problem in this case.

[TVolden]

Hi @baldur4464,

Thanks for reaching out. I would argue that all limits are defined by the official specification, but I would have to look it up. Does anyone know if the limit is defined by the OCA specification?

A quick fix is to fork the project and remove the limit.

[jmluy]

This is the description for AuthorizationKey.

The basic authentication password is used for HTTP Basic Authentication, minimal length: 16 bytes.
It is strongly advised to be randomly generated binary to get maximal entropy. Hexadecimal represented (20 bytes maximum, represented as a string of up to 40 hexadecimal digits).
This configuration key is write-only, so that it cannot be accidentally stored in plaintext by the Central System when it reads out all configuration keys.
This configuration key is required unless only "security profile 3 - TLS with client side certificates" is implemented.

[robert-s-ubi]

Unfortunately, this is all wrong! The OCPP 1.6 AuthorizationKey is only represented as 32-40 hexadecimal characters when configured using the ChangeConfigurationRequest (because that only allows strings to be sent as values).

But when the AuthorizationKey is to be used for HTTP Basic Authentication, it MUST BE DECODED and sent as a byte array of 16 to 20 BYTES. The limit of 20 was totally correct.

[rpseng]

In this PR it was also changed from bytearray to a String. That is why the length had to be adjusted. In the original code it was not functional, as the decoding was wrong. There was a mixup between the string representation and the bytearray.

[robert-s-ubi]

The password IS a byte array of 16 to 20 bytes, as per the OCPP 1.6 specification. Where do you see a mixup with the string representation? The only string representation is the BASE64 encoding, and that is correctly decoded to a byte array.

[rpseng]

Hello, the problem I experienced (and only worked with that fix) was when I try to connect to a custom server (using the present library) using a password. I'm using https://github.com/matth-x/MicroOcppSimulator for testing. Unless that simulator is not conforming.

The only physical charger I have is an EVlink, but it does not support a password at all to test.

[robert-s-ubi]

From what I see, MicroOcppSimulator does not support HTTP Basic Authentication at all, and even gets the security profile wrong (HTTP Basic Authentication is Security Profile 1). From src/net_wasm.c:

    if (!auth_key.empty()) {
        MO_DBG_WARN("WASM app does not support Securiy Profile 2 yet");

So that is definitely not a reference for compliant OCPP 1.6 HTTP Basic Authentication handling.

[ev-adias]

I'm late to the discussion, but I've just encountered an issue in the field related to this. Looking at the latest specification documente, i do not see where it states that the password must be between 16 and 20 bytes, only that it is 20-byte key.
Version 1.6, Section 6.2.2 Charge point authentication, states:

When using HTTP Basic authentication, the client, i.e. the Charge Point, has to provide a username and password with its request. The username is equal to the charge point identity, which is the identifying string of the charge point as it uses it in the OCPP-J connection URL. The password is a 20-byte key that is stored on the charge point

So the range 16-20 bytes is incorrect, it should be 20 bytes fixed?

For OCPP 2.x it states a minimum of 16 and max of 40 characters ("alpha-numeric characters and the special characters allowed by passwordString") not bytes, so maybe we should not mix version 1.6 and version 2.x??