Thank you Maxim!
I don't see DVLS 2026.1.15 available yet - I'll test later when it's published.
Meanwhile I tried the Entry security analyzer in RDM 2025.3.32 and RDM 2026.1.15: I see the calls to api.pwnedpasswords.com are now made in the background in both versions, so you can use the GUI while it's doing that. That's great!
I noticed another issue though: In RDM 2025.3 it creates a single TCP/TLS session to check all passwords. It takes about 20 Seconds to load 500 entries here. In RDM 2026.1 it creates a new TCP/TLS session for each password in sequence and it takes about 60 seconds to load 500 entries, so the new implementation has worse performance. Looking at packets in Wireshark, they don't seem to be parallel connections, but in Process Monitor I see "TCP Connect" and "TCP Disconnect" events in parallel batches of around 10 to 15 connections, so I don't know exactly what's happening, but it is definitely slower.
Also, a few more suggestions (partially repeating my original post):
While loading, you just see a progress indicator with no percentage or message, so you don't know what's happening or how long it's going to take. You could add a status message, like "Checking compromised passwords... 68/500".
Right now, the "Is compromised" column shows nothing (empty string) or "Compromised (pwned)". But there's no value to indicate when it's not checked yet, or if it's not compromised.
You could make it update the list in real time. Right now the whole list shows an empty "Is compromised" column until all entries have been checked.
The result still isn't cached, so each time you refresh or change the filter, it loads the whole list again. Once a password is found to be pwned, it will never be un-pwned again, so you could store the state of that entry locally in a cache file. Then check the local cache file first, before sending the request to the API again. Also for entries that returned an uncompromised status, you could write them to the cache file too including a timestamp. Then only query the API again if the last check has been more than an hour or even a day ago.
For security, the local cache file probably should not contain the password hashed themselves, to avoid password cracking attacks. For the purpose of caching, you could create a separate hash from other data, like the entry ID, last password change time, or even a partial password hash (like the one that's used to query the API in the first place).
Thank you!
Best regards,
Daniel
