password limit

[GVRHUB]

Hello, Is it possible to remove the limit on the password length? Best regard Glenn

[huwylphi]

From the spec, the password length should be limited to 65535 bytes. I can check the source code how this limit is handled and let you know.

[huwylphi]

It seems we currently defined a limit of 80 bytes for both user and password lengths. If you need this limit to be higher, I can try to see what I can do, but most probably not before next week.

[GVRHUB]

Can you increase the limit to 1000 bytes? Thank you in advance.

[chillymattster]

Hi, I see a potential problem here when the limit is generally increased to 1000 bytes. Regardless of how many of the 1000 bytes are actually used or needed, the compiler will always assign and reserve 1000 bytes statically. To my knowledge there is no dynamic memory allocation involved because dynamic memory allocation is risky in terms of deterministic behaviour. This means by just increasing the string length to 1000 bytes, there will almost 2kB of memory continously be blocked or used. In my opinion this seems to be a lot especially as Codesys 2 PLCs are not known for having large amounts of memory available. Such large username and password, especially as the lib doesn't support transport encryption, seem to be a very special and rare case. Therefore I doubt that increasing the two variables to 1000 bytes is a good idea.

Solution proposal: You can download and import the EXP-file in your Codesys 2 project and change the definition of the two variables according to your needs.

If I'm missing something or missunderstood the request, I'm happy to learn more about it 😄

[huwylphi]

Hi, I agree with @chillymattster that generally allocating such amount of memory might cause some issue for some PLC and since we provide the mqtt.exp export file, his proposition should work for such use case described by @GVRHUB.

However, I might have an other proposition that would allow the library to support up to 65535 password length (as defined by the MQTT 3.1.1 CONNECT payload Password field specifications 3.1.3.5):

• instead of passing a STRING to the FB_MQTTClient() as input variable, we could pass an address of a STRING, actually a POINTER TO STRING, skipping the currently statically allocated 80 bytes and consuming only 2 bytes (or 4 depending if the target PLC is 32 bit or 64 bit based) to store the address integer
• and additionally pass the length of that STRING (as new input argument)
• that way the function block could handle "any" length since it would only fill up the MQTT CONNECT payload buffer starting by the first byte at given string address and up to the given string length.
• we could apply that principle for both username and password
• the STRING variable would not be declared within the function block anymore but on the consumer side
• this would allow one to declare a password variable of type STRING of e.g. 1000 bytes if wished (if the target PLC has enough memory), initialize it with the string value and pass its address and length (e.g. ADR(myLongPassword), LEN(myLongPassword)) to the FB_MQTTClient() function block.
• that way the FB_MQTTClient() function block would be more generic and support such use case.

[chillymattster]

Hi, Before spending time to implement a solution, I still would like to understand the use case of @GVRHUB for such a large username / password in combination with missing transport encryption. In my opinion there is no reasonable increase from a security perspective as unencrypted credentials are insecure by design anyway. So this must not be used for a WAN-connection at all and a basic level of security must be created by network separation and e.g. use of VLANs or VPN to prevent simple packet sniffing and credential disclosure.

However, from my point of view your idea, @huwylphi, is a possible solution on implementation level. I would like to add two points to your list:

• There is at least the internal in memory buffer used for creating the messages before sending them which needs to be externalized or at least be made configurable in size externally as well. That's because currently the size of abOutBuffer is defined by internal constant BUFFER_SIZE : INT := 535; which is calculated based on biggest possible CONNECT-Message with username and password having a maximum of 80 characters. @GVRHUB, this buffer must be increased also when using the EXP-file. I doubt that it would be reasonable to completely rework the library to something like stream-based sending of messages to avoid generating them in memory. This would require a significant implementation effort, if at all technically possible.
• To my knowledge Codesys 2 has no limit of string-size. But all standard string-functions are limited to strings with a max length of 255 characters. This means that e.g. LEN-function won't work with a string-size of 1000. The code base needs to be carefully cross-checked, if there is no use of any string-function to ensure there are no other side effects.

[huwylphi]

Hi, thanks @chillymattster for these very good remarks!
So let's await on @GVRHUB to add some detail about his use case and especially the reason why he would need to setup such a long password?
If we will let the username/password length limited to 80 bytes, then we could document it in the readme.md file.