Zu anfang hat sich der Nitrokey verabschiedet und war nicht mehr erreichbar. Mit Chkdsk konnte ich das korrigieren.
Nun aber das nächste. Ich habe meine KeePass Datenbank dadrauf. KeePass 2.37 neu geladen und alle Plugins installiert. Nun gebe ich die 4 Tokens ein und fehler.
Was soll ich im Recovery Mode machen? Den Zufälligen Zahlengenerator eingeben? Den habe ich ja nun geändert. Eine Erklärung wäre da echt gold wert
If I understand correctly (just to summarize): you have used Nitrokey Storage to backup on encrypted volume your KeePass database and left unattended for a time. Now with a fresh KeePass installation you would like to open it and in the meantime you have used CHDSK on this partition.
Assuming the Keepass database was not corrupted (due to CHKDSK or some OS write malfunction), my guess of the cause is a desynchronization between device’s HOTP counter and the KeePass’es one.
HOTP counter value is increased on each use of HOTP slot (on both sides). This authentication method requires same counter values all the time. If the counter is increased or reset on only one of the sides, it will stop working. Thus whole solution consists of making HOTP counters’ values on both sides to be the same.
Please (this might be useful later; just in case):
- write down how many times have you tried to unlock the database using HOTP,
- export your Storage firmware and write it in safe, encrypted place.
Have you reinstalled the OS or removed the old KeePass configuration? Perhaps the counter for KeePass side is kept there and therefore could be restored. It would be good to confirm that on KeePass forums.
If the counter is written back to database on each opening (hence you have the updated counter on KeePass side) I would guess the desynchronization is caused by unintentional HOTP code generation, either by special-key inserter functionality or by miss-clicking in the Application’s passwords list.
Either way, if you would know which counter value the KeePass wants, you could easily set such on the device and have the database unlockable.
It is possible to see the current HOTP counter value in
Configuration -> OTP Slot Configuration (labeled
Moving factor seed in Nitrokey App v1.1). Could you check is it divisible by
4 (since 4 OTP code fields were used to unlock each time)? If it is not, perhaps it was executed unintentionally.
Configuration window, OTP General tab there is a keyboard-inserter function configuration for HOTP codes by double pressing special key (NumLock/CapsLock/ScrollLock). Make sure your HOTP slot number is not set there to avoid spurious HOTP codes generations/insertions and in effect HOTP counter increase.
If you would like to change the counter without overwriting the whole HOTP slot (please export firmware earlier for a backup), you can do so by simply setting desired value in
Moving factor seed field and then pressing
Save. Please make sure you are using Nitrokey App v1.1 or newer.
What version of:
- Storage firmware,
- Nitrokey App
do you use?
I have just checked this plugin and saved the test database with OtpKeyProv plugin enabled.
With the database in same directory there should be a file with same name but with extension
.otp.xml. There is written the counter value: XML key
<Counter> - set the same on the device on the proper HOTP slot and it should work. Other way around should work too.
sorry this is a lot at once.
Okay step by step.
I have a copy of an unattended database.
Also the same error. Okay lets go on.
A few hours ago I saw the wrong counter and correct them manual. Maybe this was a misstake. My old and first counter (from an old backup of the config file) has 172. Today I changed to 143. And this is not divisable by 4.
Now what should I do? I could reset the Moving factor seed back to null/0 or random fill.
After done, I could write this seed back to the config file. Is that the way?
Counter and move seed factor now both at 4. Still error
I see. Could you answer the other questions please?
NitroKey Storage with 16GB
App Version 1.1
Firmware Version 0.46
Have you tried setting both config’s and device’s counters to 172 and then testing?
What was the counter value on the device?
And, just a sanity check, are you using the same HOTP slot on the device as during the setting the database protection?
If this would not help, here is KeePass support forum - they might know more about this. Please make a topic there too.
Counter is the same. The counter is in sync. Because after each try the counter increments with 4.
The HOTP Slot is the same. Passwordstore on nitrokey was never corrupted.
I have also changed the secret. And I pasted the new secret on recovery. Maybe this is the problem?
I see. You need exactly the same HOTP secret you have generated back then and saved on the slot. Unfortunately, if you have not done any backups of the HOTP secret string or firmware export before overwriting the HOTP slot on the device, you might have lost the chance to recover the database.
That sounds not so good.
I hope with the recover way I could correct that. Okay. For my understanding. If I lost my key but I have anywhere a firmware backup I could this backup use to recover the los Nitrokey with a new one?
Unfortunately I have not tested re-flashing the device with firmware export myself as a backup measure, I do think though it might be possible. Perhaps @nitroalex would know the answer - please wait for his comment and keep the firmware export file in safe place until then.
I did not test if firmware export does include TOTP or HOTP secrets yet, too. But I would find this rather strange
Why not testing it right away? If I understood you right, your HTOP secret is overwritten anyway and this is your last thing you can try? Or do you have more data on the Storage you don’t want to potentially overwrite too? If this is the case, then we should have a closer look what is happening at firmware export before trying such things or bying a second device for backup purposes.
I have just checked this and in exported firmware there is no OTP data and this is by design. I have probably confused some internal debugging firmware with production one. Sorry for giving false hope regarding that matter.
Now that the HOTP secret is overwritten on the device I am afraid there is nothing we could do further from this side.