[removed]
The next version of WinBatch adds a new function that clears text, i.e., passwords, from process memory. It may seem trivial, but it does add a layer of security to passwords in scripts.
Another possible addition would be a secure password generator function. However, that is trickier than it might seem.
It's not overly tricky. Just give people a choice between their Birthday, Anniversary, Pet Name or "password" and maybe randomly throw in 1234 for variety ;-)
Jim
We are quite familiar with the usual approaches to password generation. WinBatch already contains several bit mushers. But we are interested in something a little less cryptographically crackable. There is a substantial body of literature devoted to creating and testing secure, robust password generators. We need to do the research before cooking up an approach that best matches our requirements.
Of course, there is always "password" to fall back on...
The initial post, albeit a little silly, was not so much about how secure one could make a password, but if Win Creds secured it to the user/computer. So, if I was given a password to an exe that was preserved with Credman(), then send the exe plus my password to another user on another computer - if prompted for password when they ran the exe and entered my password - my assumption was that it wouldn't work.
How strong the password is in the first place and for what purpose, is, of course, another discussion.
Please continue on another thread
Quote from: td on September 30, 2025, 09:28:44 AMOf course, there is always "password" to fall back on...
Shhh... the password is always swordfish ....shhhh.
Quote from: spl on September 30, 2025, 11:33:39 AMThe initial post, albeit a little silly, was not so much about how secure one could make a password, but if Win Creds secured it to the user/computer. So, if I was given a password to an exe that was preserved with Credman(), then send the exe plus my password to another user on another computer - if prompted for password when they ran the exe and entered my password - my assumption was that it wouldn't work.
How strong the password is in the first place and for what purpose, is, of course, another discussion.
Please continue on another thread
Since you have deleted the script, I am not sure if your assumption is accurate. The Windows Credential Manager stores passwords in a secure fashion. But it does not prevent another user from using a password if it is already known. The benefit is that the user does not have to remember the password and is never prompted for it once it is set by CredMan. If you move an exe that uses CredMan for passwords to a new system, you would need to have a way to set the password for the new user in that system's Credential Manager. Using an install script is one approach, and the one I use.
Creating secure passwords is as much a part of the process as storing them securely. Passwords created by time seeded random number generators and other common techniques are not all that hard to reverse engineer.
Quote from: td on October 01, 2025, 08:34:33 AMI am not sure if your assumption is accurate.
Maybe not, but the question was if a password was securely tied to the user/machine, and the exe first asked for the user, then looked into either Win Creds or a Vault, checking if app:user Target existed, then checking for the password, would if the password were known to another user [w/out it already being pre-set to the machine for that user] the exe operate beyond the first check for app:user configuration, and still open the exe?
And, setting conditions to how the original vault was set for specific user ==> application, so not a one app fits all, is an additional concern.
So, not really 'breaking' a password, but protecting an app from being shared.
The stored password is cryptographically hashed using both user specific information and machine specific information. It is the same principle used in generating a "passkey" that has become all the Tech Bro rage right now. You need to login as the user with a stored password on the machine where the password is stored in order to use the app. That is assuming the application is written to check the Credential Managers' stored credentials before continuing. It would not make much sense to use it otherwise when trying to protect an application.
I don't use it to protect applications. I use it more for protecting credentials used by scripts when connecting to networked resources, such as SFTP/FTPS servers.
Thank you. Answers the original post, although that was not posited very plainly.