Hmm, I hadn't considered the 2025 to be a key, but I guess it is acting as one. Walks like a duck, talks like a duck, must be a duck.
The security lay more in using Rnd as a mangling function that doesn't look like it'd have anything to do with passwords. And keeping the password unassembled until it's needed. And the password is (near-)impossible to derive from a decompiled listing, which was the original goal.
I used 2025 as the RNG seed because I figured it could be pulled out of the copyright date or similar. But you could just as easily use any piece of information, like a tag from a layout. Actually, that'd be kinda good, because it doesn't show up in the decompiled code listing. Or use the width of a particular field of the layout. Any value will do, as long as the program has access to it when it needs to regenerate the password.
I realised on the drive home that the Rnd function could probably easily generate up to three characters per round, instead of just 1.
You could use encryption, with a key hidden in a layout, spread across fields to better disguise it. But that has the downside of: the call to the decryption routine is obvious in a decompiled listing, whereas generating random characters littered throughout the code, not so much.