Seems like that is a Windows issue. There's lots of people commenting in the article that got around the problem, I checked those keys and looks like those values are the defaults (I'm on W10 x64 21H1, latest build).

If you don't feel confident changing them perhaps you might want to try and copy the Bitwarden CLI into %AppData%\Auto-Type directory. Why? When running executables from %ProgramFiles% security is hardened a bit, so that might be the case.

Another option is to temporarily disable security software (Anti-virus and/or Defender), if the issue is triggered by that you can safely whitelist the Bitwarden CLI executable.

from bitwarden-autotype.

Thank you for the response.

To test, I moved the bw.exe into %AppData%\Auto-Type but that had no effect, the issue remained (edited the ini to point to the new location as well with no effect). I also temporarily disabled windows defender (virus and firewall) and that too had no effect, the issue remained. I checked both of those registry entries as the linked article suggested and both were already set to "0". This from a fresh install of Windows 10 21H1 direct from Lenovo. This version of Windows is Home so I don't have access to the Group Policy Editor.

Do you have any ideas why the 1.1.1 update triggered this issue where 1.0.1 did not? Is there any way to revert to 1.0.1 instead of the latest update (installed via setup.exe) without the attempt to do so being blocked?

Again, thank you for your insight here... hope you are having a nice weekend.

from bitwarden-autotype.

At this point I'm not sure anymore if is an isolated issue or something about Bitwarden. If you take a look at #15 I referenced 2 issues in Bitwarden's own tracker plus, one I created. Looks like my timing for an update plus the bot protection clashed like champs :/

Right now I'm working on the fix for that (login via API Key), as soon as I finish I can pull the v1.0.1 tag and mod accordingly to ignore the update (that I plan to link as hotfix). Sorry for the inconvenience but this time was a weird planetary alignment :P

from bitwarden-autotype.

Thanks again for your response. Yes, it must be frustrating that the updated CLI and your release happened to fall in the same time period. Nothing you can do about that, of course!

I downloaded the 1.0.1 zip (instead of the setup.exe) and extracted it to a less protected folder to test (C:\Utils\Auto-Type). Edited the 'bw-at.ini' and copied in the new bw.exe CLI that 1.1.1 downloaded. It now loads fine: asks for password and asks to setup PIN as usual, but has the "login via API key" issue. Will track any progress there as well... thank you for your efforts to solve these issues.

from bitwarden-autotype.

Hey! just finished with the API login and I tough that maybe your issue can be a byproduct of the files being signed. I sign the executables to get a lower false-positive rate in VirusTotal.

Given the fact that this done merely as a helper I cannot afford to buy a certificate for signing, thus I use self-signed certificates and perhaps a somewhat strict configuration is getting in the way (or Windows being Home?). If you're willing to try, here's an unsigned debug version of the current develop branch. Please feel free to inspect the code on the executable and you can block network communications via firewall if you feel more comfortable.

If it fixes you issue I have prepared a commit for an updated build script that creates both signed and unsigned versions. Other than that from version 1.1.1 the final executables use BinMod (again to get less false positives from AV engines), here is a version without BinMod.

Finally, here is the most vanilla version which uses the U64 .bin base file in the AutoHotkey distribution rather than the one I modified for the project (where I have removed the unnecessary bits).

Hopefully one of them has the answer for you and most likely to others facing the sane issue. If you are able to have any of them working I'd know what to do to fix the problem.

Thanks a lot for your patience and input.

from bitwarden-autotype.

Given the fact that this done merely as a helper I cannot afford to buy a certificate for signing, thus I use self-signed certificates and perhaps a somewhat strict configuration is getting in the way (or Windows being Home?). If you're willing to try, here's an unsigned debug version of the current develop branch. Please feel free to inspect the code on the executable and you can block network communications via firewall if you feel more comfortable.

Just tried this build and the problem is now gone completely. Haven't tested the others, though.

from bitwarden-autotype.

Well, that was interesting results. I downloaded your new build setup.exe, v1.1.2 and installed it. Same issue as before: running it from its shortcut or directly from C:\Program Files]Auto-Type\bw-at.exe where it was installed results in the same "referral" issue. I then downloaded the zip of v1.1.2 and replaced the bw-at.exe in the same location, C:\Program Files\Auto-Type and it worked as normal (with the new UI you built to support API login, which works just fine thank you!). I also downloaded all three of your above debug builds and all of them work fine as well (all displaying 'Debug version' on startup).

Not sure what that means, exactly or why these results. Let me know if this helps or if there is anything else I can do to help test. Thanks again for your excellent work on this invaluable app, the new API login correctly bypasses their new Captcha requirement with username and password.

from bitwarden-autotype.

Looks like a problem of the CA chain resolution algorithm. But I cannot seem to find a solution.

Having a somewhat complete Distinguished Name in the CA (Certification Authority) might work. My problem relies in the fact that I cannot reproduce the issue.

This is literally just a Hello World message, if anyone in the thread care to run it and reply with the findings would be awesome, otherwise I have to revert and release unsigned executables resulting in higher false-positives rate in VirusTotal.

from bitwarden-autotype.

When downloading the setup.exe for 1.1.2 using Edge (temporarily using Edige to test memory usage) it does get blocked and requires unblocking to complete the download. Also, when running setup.exe I get another block from Defender and must unblock that as well to install. Once install is completed and the app is run there is no Defender issue (just the 'referral' issue unless replaced with the zip version).

When attempting to download your Hello World, it gets blocked by Defender (Severe) as Trojan:Script/Sabsik.FL.A!ml

https://i.imgur.com/dQkFumc.png

from bitwarden-autotype.

These are the VirusTotal results from the Hello World message, it's flags it.
Link

from bitwarden-autotype.

That's how dumb are AV engines nowadays... this is the source code of the Hello.exe:

MsgBox 0x40, Test, Hello World!

Yet is only flagged by Zillya which until I did this tests never heard of it, but Defender says is "Severe".

That will be the tradeoff: higher false positive rate vs random issues.

Still the setup version should work as the certificate is created by the host machine via PowerShell. So, the issue remains, why signed executables with a certificate created by the host machine gives this error? Perhaps is Windows Home or a some processor instruction set (currently I own only AMD-based PCs).

The current state of the develop branch adds a more complete DN as was the only viable fix I could think of that made sense. Most of the online information I've found is either policies too strict or wacky DN strings. This will fix the latter if that's the issue, I was previously generating the certificate via AutoHotkey itself but Windows 11 break that.

This are builds from the develop branch

• bw-at.zip
• bw-at-unsigned.zip
• setup.zip

from bitwarden-autotype.

I was barking at the wrong tree (kind of), literally blind luck help me stumble into the underlying cause.

While doing something totally unrelated I removed all of the certificates, tried to start the application and BOOM! came me across the referral alert. Turns out that if you try to start the installed application without the certificate the error pops (thanks to the manifest requesting to ignore User Interface Privilege Isolation).

Now, on your case I'm not sure why you are getting it in the first place, my best guess is an error at certificate creation. so I modified the PowerShell bits and the installer to:

• Recreate the certificate
• Sign the executable
• Trap any possible issues
  • Remove the UI Access token

If all of the above fails the installer rolls back the changes done to the system. Hopefully doesn't come to that.

from bitwarden-autotype.