Support for Yubichallenge with KeepassXC DB about keepass2android HOT 84 CLOSED

@PhilippC go to yubi.co/support, let us know what YubiKey model(s) you require, and we'll send them to you :)

from keepass2android.

@Bassetts yes, I have received a Yubikey. I am pretty busy with a few other things during the next weeks so this might still take a bit of time, but I will definitely try to bring it into the 1.05 release.

from keepass2android.

I just released the first implementation of this to the beta channel (https://play.google.com/apps/testing/keepass2android.keepass2android).
Please consider the feature experimental and always have a backup of your database!
Please let me know if everything works as expected.

Note that your database must have the KDBX4 format for this to work. (KDBX3 databases have another Challenge-Response-Implementation in KeepassXC which cannot be integrated into KP2A).

from keepass2android.

unfortunately there are some issues in the current implementation leading to data corruption depending on where in the app a change is made (i.e. the save is triggered). Will have to investigate this closer.

from keepass2android.

Awesome, been waiting for this to happen for a long time so I can migrate from not-so-nice KeePass to a-lot-more-nice KeePassXC while still using my YubiKey. :) Not to stress you but do you have any estimate when 1.05 can be in beta? @PhilippC

If there is any testing etc one can help out with, please shout!

Thanks for your awesome app!

from keepass2android.

Challenge Response fix would be fantastic! If you need any early testers let me know. I use a Yubikey 4(no NFC) and would love to eventually have support for that. I'm in the beta group for KP2A also.

from keepass2android.

unfortunately I did not find a quick fix for the issues noted above. I have thus moved this to the "1.05b" milestone. I will first publish 1.05 to stable channel and then work on 1.05b.

from keepass2android.

thanks for the feedback. I have just published an update to beta channel which requires ykDroid. I have removed the built-in NFC Challenge-Response handling to get rid of the NFC permission. Also ykDroid has a better implementation.

from keepass2android.

No you don't. That is a - unfortunately - very common misconception. You don't have to press the "button" on the NEO while using NFC.

The NEO does not get enough power through NFC to power the button.

from keepass2android.

@PhilippC I will help pay for a YubiKey 4 NEO. If you give me your info or donate linked or whatnot, I can send (money) over. I'm very interested in seeing this implemented.

from keepass2android.

@wbedard, apologies in advance if this is a stupid question. However: when you say "swipe," do you mean "swipe," or are you holding the YubiKey in place for at least 4-6 seconds? I ask only because, if you haven't used the NEO's NFC functionality before on Android, you may not be aware that it can take some time for the NFC transaction to finish.

I use the Yubico Authenticator for Android regularly, and that requires about 4-5 seconds to complete its transaction. Despite the "success" notification sound I get almost immediately from Android, moving the YubiKey away from the phone right away causes Yubico Authenticator to fail to finish its transaction(s), and Authenticator throws an error.

I'm also using a Nexus 6; originally with the stock Google 6.0.1 - 7.1.x firmware; then the 7.1.2 - 8.1.0 (ROM 14.1, 15.1) releases from the LineageOS project.

from keepass2android.

closing this as the implementation seems to be accepted

from keepass2android.

from keepass2android.

TOTP ist not for unlocking the database. It is only a TOTP generator.

from keepass2android.

are there any security drawbacks using AES-KDF vs. Argon2?

Kind of, but it mostly depends on your threat model. For most of us, the difference in security does not really matter.

Cracking processor intensive cryptos like AES can be sped up significantly (I'm guessing something like 1000x) by having dedicated hardware (ASIC) for the task instead of running the computations on general purpose hardware like a regular CPU/GPU. Memory intensive cryptos, on the other hand, is not very easy to speed up via dedicated hardware. I don't know if it's impossible, or just too hard to be worth the trouble.

But creating dedicated ASICs is hella' expensive, so unless you're up against state-sponsored actors, I'd say you're fine off with AES-KDF. A slight disadvantage of Argon2 is that it is not as old, so it has not been attacked for as long. So while we have no reason to believe it has any huge flaws, the risk is slightly higher compared to AES. Especially when considering the implementations, and not just the algorithms.

from keepass2android.

ASICs can compute AES much faster than a general-purpose CPU, whereas Argon2 is a memory-hard KDF. That means you cannot arbitrarily trade memory for processing speed. Since memory access is as fast or slow on an ASIC as it is on a normal CPU and Argon2 guarantees a specific memory cost, an attacker cannot get these immense speed-ups anymore. It's also a lot slower in general with only few iterations compared to AES, which was never intended to be slow in the first place.

from keepass2android.

@whereisaaron nope, fully able to use on screen keyboard with a USB yubikey inserted here, and that's on a note 8

from keepass2android.

@PhilippC I might be able to help with testing if you tell me how.

from keepass2android.

thanks for the offer, but I'll need a physical device for testing on my own. I'll search, search and search...

from keepass2android.

Interesting commits! Thanks a lot! :) Do you have a time plan when this functionality will be included in an google play beta/release?

from keepass2android.

Hi, I tried it 3 times with my Yubikey neo, but I failed every single time. After each try this error code occurred.

"wrongly composed key!"

from keepass2android.

I was able to open/modify a database created by keepassxc (converted to format KDBX4) but I was not able to create a new database on the phone using the beta version.

from keepass2android.

@rmenessec As a quick follow-up, your mention of the Yubico Authenticator app got me looking into whether I could get that app to work with my NEO. As it happens, I kept getting a msg about an error communicating with the YubiKey. For now, I've filed a support ticket with Yubico and will let you know if anything noteworthy comes from it.

from keepass2android.

I've been trying to get my Password + Challenge-Response (HMAC-SHA1) KeePassXC database open in Keepass2Android 1.06f using NFC (why I'm here). It started working once I changed the Key Derivation Function from "AES-KDF (KBDX 3.1)" (default) to "AES-KDF (KBDX 4)". I'm guessing this is unrelated to the use of NFC, but I'm too lazy to verify that.

from keepass2android.

@burkemw3 There are already multiple issues about this. One is assigned to the 1.08 milestone.
#306 #283 #106

from keepass2android.

This stopped working for me and I'm not sure why. I haven't changed anything. Using kp2a, ykdroid and a yubikey4 over USB. My USB keys work fine in Windows but on my phone I'm getting a toast that says "The challenge response is incorrect." then just sits at "Working..." indefinitely. I usually use Nextcloud but also tried copying the database straight to my phone and both give the same results. I figured this should be here but let me know if I should open a new issue.

from keepass2android.

Add me to the list of people who have a yubikey 4 and would like USB-OTG support. keepass2android is the only reason I'm not using my yubikey for keepass at the moment.

from keepass2android.

Also very interested in giving this a shot. How will we know when/if this is implemented? I'm eager to protect my KeepassXC database with challenge-response.

from keepass2android.

@JRussell @RinnosukeETQW doesn't inserting a non-NFC yubikey suppress the Android on-screen keyboard? Or are you using Android as a desktop and don't care about that?

from keepass2android.

I really want this too.

from keepass2android.

the KeepassXC implementation has been updated so it should now be possible to implement this. Current obstacle is that I simply don't find my Yubikey anymore :-(

from keepass2android.

If you can't find it, I'm sure there's plenty of people who recently replaced their 4 thanks to the infineon bug that will have an old one. I mean it was a free replacement so why not? The issue with those yubikeys was PGP so yubichallenge should work just the same.

from keepass2android.

@RinnosukeETQW

If you can't find it, I'm sure there's plenty of people who recently replaced their 4 thanks to the infineon bug that will have an old one.

And there was a flaw before that that affected the NEOs, too. I have several older YubiKeys about the place.

from keepass2android.

@PhilippC @andmib me too

from keepass2android.

thanks for your comment, @yubichris . I tried this a while ago but without answer. Hope it will work this time!

from keepass2android.

@PhilippC did you get anywhere with Yubico? If not I am happy to donate either Yubikey(s) or to give a monetary donation towards the model(s) you would require.

from keepass2android.

+1

from keepass2android.

it looks like this feature is now supported in the newest beta but i still can't open the database with my Yubikey NEO via NFC. there's a button "load OTP auxiliary file" there, perhaps it shouldn't be since i choose "password + challenge response" option?
i'm on android 8.0. tnx!

from keepass2android.

Quick question: will the finalized code support KDBX v4 files? Once I realized that KeePassXC had (or added?) v4 support, I replaced all copies of my older databases with new files using KDBX v4, AES-256, with Argon2 (Argon2id?) hashing and 8 or more transform rounds.

At present, I'm only using KeePass2Android to save credentials for a few non-critical sites; and I'm relying on encrypted, cross-platform clipboard functionality or QR codes as necessary to get credentials from KeePassXC on desktop platforms into login forms on Android.

from keepass2android.

@rmenessec, not sure if it's final code or not but I've been using a KDBX v4 (AES-256, Argon2 KDF) database as my day-to-day password store with no issues at all since the code was originally committed months ago. So long as it's protected with just a password, it's fully compatible with both keepass2android and KeePassXC.

from keepass2android.

that commit seems to only use the neo's NFC like before, any word on adding USB support?

from keepass2android.

Okay. My fault. It was an ID-10-T Error. (had to update the database)

Now it works like expected! Thanks for all your awsome work! 👍

from keepass2android.

I was unable to open a database I created for the purpose of testing this workflow. The KeePass2Android log file can be found here (https://pastebin.com/LLedVcet) and the test conditions are as follows:

Database creation platform: KeePassXC 2.3.3 on Windows 7 (64-bit)
Database properties: encryption - AES-256; KDF - AES-KDF (KDBX4); ~500K transform rounds; master key - password + Yubikey Challenge-Response

Android testing platform: Nexus 6 running Android 8.1 (custom ROM)
YubiKey device: YubiKey NEO (NFC) running firmware v3.0.2
Application version: KeePass2Android v1.06-pre1

Let me know if I can provide any add'l useful details. Thanks for all your continued efforts to develop this app!

from keepass2android.

the error you are seeing is "YubiChallenge cancelled". Does this happen when you swipe the Yubikey or do you press the back button?

from keepass2android.

I swipe the YubiKey when I get prompted. Once NFC registers, it returns to the app with the toast messages showing.

from keepass2android.

@rmenessec Thank you very much for the tips on NFC. When I used the term "swipe", I was mainly referring to the action of moving the YubiKey around until NFC registers it. While I don't have tons of experience working with NFC devices, I've never heard of one taking as long as you mentioned to return a response. However, what you describe would certainty explain the error that KP2A reported in it's log. I will certainly give it another shot taking your advice into account.

from keepass2android.

@rmenessec Unfortunately, I still wasn't able to open my test DB. In my experience, it took less than 2 seconds from the time I got the YubiKey in position (little to no "swiping" in this latest test...) to getting back to the app with an error toast. If you have the time, I would welcome you sharing the details of your end-to-end setup that is working for you. Thanks again for sharing your input.

from keepass2android.

from keepass2android.

@wbedard, that's good to know.

That is—I'm sorry that it sounds like the NEO might be having issues, but, selfishly, it's good to hear that the problem likely isn't KP2A.

Do you have some other NFC devices you can use to test the NFC interface on your Nexus 6, just to rule out an issue on that end? Some smartcards—like the NEO—are dual-interface units with both the surface contacts and NFC circuitry. (I just tested a couple of my credit cards; they aren't NFC-capable, sadly.)

If you don't have any other NFC devices or tags to test with, I'd recommend getting a few cheap programmable NFC tags; I was able to find a small assortment of NXP Semi NTAG216 stickers a couple of years ago on Amazon for a fairly reasonable price, and I would guess NFC tag prices have only come down since then. (The NTAG216 has 888 bytes user-writable memory; the 213 and 215 have 180 and 540 bytes, respectively.)

I use the tags in combination with NFC Tools / NFC Tasks to automate some simple tasks when my Nexus 6 has the screen locked, and I don't feel like entering my password just to toggle WiFi on/off or similar.

Only NFC Tools is necessary for reading / writing tags, and I don't believe the free version is limited in a way that would make testing difficult. (I only have Tasks installed right now, but I can reinstall Tools and find out.)

There are other NFC read / write apps on the Play Store; some free, but I haven't personally tried them. I also see one F/OSS NFC reading app with NDEF Push supported for phone-to-phone communication, available on F-Droid. I'm also just now seeing Smart Card Emulator and Smart Card Reader, which look fascinating, and might also be useful for testing.

from keepass2android.

@wbedard, one last thing that occurred to me: I have a fairly thin, non-metallic case on my Nexus 6, but it's still thick enough to prevent the NEO from working unless it's positioned very carefully, just above the NFC transceiver. If you have a case—any material, even plastic—on your phone, it could be just thick enough to prevent a good connection between the NEO and your Nexus' NFC transceiver.

from keepass2android.

@rmenessec Thanks for the add'l insights. My Nexus 6 doesn't have a case and I've had no problem using smart cards or RFID tags in the past. I also didn't have a problem pulling a full scan on my YubiKey using the NXP TagInfo app, which is a desired step in submitting a trouble ticket with Yubico. I imagine that the issue I am seeing is due to some aspect of the software side of my YubiKey but we'll see what Yubico says.

from keepass2android.

@wbedard, well, shoot. I'm sorry. That does sound like some issue with the NEO. Could be just configuration, though. If there's a hardware issue, I've gotten great support from Yubico in the past; they seem to have excellent warranty coverage. In addition to getting several affected YubiKeys replaced for free in the past when security flaws were revealed in the NEO, they've also replaced one of my 4 Nanos for free when I experienced an apparent hardware issue.

(You're aware of the past security bulletins for the YubiKeys, right? If not, best contact Yubico and get your keys replaced—if affected—in any case. Their security bulletins... all four so far... are listed here.)

from keepass2android.

@rmenessec Well, we're starting to make some progress. Yubico got back to me and identified that my NEO was an early "developers" version that didn't have all the JavaCard apps that are now standard on the production versions. They gave me instructions on how to install the OATH app and that allowed me to use my NEO with the Yubico Authenticator app for Android. However, I still am unable to open a test DB in KP2A that requires Chall-Resp. I'm not sure if there's another app that I'm missing or, however unlikely, an residual issue in the KP2A app. Unfortunately, I'm doubtful that I would get as quick and productive a reply from Yubico if I filed another ticket referencing this pre-release 3rd-party app. I'm going to take a break on this for now but I may re-engage once the KeePassXC compatibility has gotten a bit more exposure and testing.

Oh BTW, I am aware of the security vulns which almost certainly apply to my device. I've had my eye on their just-released FIPS 140-2 line of devices and will almost certainly pick one up, which may also solve my issue in this thread.

from keepass2android.

@wbedard, the problem with the YubiKeys is that it's not possible to upgrade the firmware, due to the tamper-resistant design; you can install smart card-compliant apps, yes, but not upgrade the actual firmware. If they somehow got you pre-release hardware by mistake, I'd just ask them to fix the problem by replacing the NEO with a production model.

Just for reference, FIPS 140-2 doesn't guarantee that something will be secure; only that it passed 140-2 testing and certification. Many 140-2 products have later been demonstrated to have quite shocking security flaws. 140-2 itself isn't a feature, nor is it a protocol. It doesn't have any inherent benefits; it merely describes a testing and certification process.

I'm looking at the 140-2 product page now, and all the specifications for the 140-2 keys appear to be identical to the existing 4-series YubiKeys. The only difference I can find is the FIPS certification. If you don't work for a government agency or other entity that requires FIPS compliance, I don't think the FIPS-labeled keys will have any special value to you beyond a regular 4-series.

... Also, I don't see a "YubiKey NEO FIPS."

If you're planning to wait for a new product release, I would give the 140-certified keys a miss and wait for the first YubiKeys that support FIDO2, other than the new FIDO2 "Security Key." Support for FIDO2 is—or will be—a genuine feature and benefit.

... In the meantime, though, I would go ahead and get the existing NEO(s?) replaced; especially if you qualify for no-hassle replacement under their security flaw remediation.

from keepass2android.

@wbedard, one question, to clarify: I saw you mentioned that you have the YubiKey NEO working with KeePassXC, using a KDBX4 database and HMAC-SHA1—is that using the same NEO as the one you're testing against the Nexus 6?

from keepass2android.

@rmenessec Yes, I use the same NEO to encrypt my test DB in KeePassXC that I'm trying to use to decrypt it on the Nexus 6. That seems like an odd question...please clarify if I may have missed something subtle.

BTW, yeah, I did notice that the FIPS line doesn't include an NFC model. I'm still interested in that line for use at work but I definitely agree that the FIDO2 certification is far more useful to me in day-to-day use.

from keepass2android.

@wbedard, sorry for the late response. I was toying with the possibility that you might have used different NEOs and thus (possibly) different SHA-1 seeds on the two test platforms, either on purpose or by accident. I was also considering the possibility of getting different results with different firmware revisions on more than one NEO.

(Correct me if I'm wrong, but I don't think that Yubico provide a firmware changelog, so we can't see what might have been fixed... or broken.)

from keepass2android.

Hi,
I just installed KP2A 1.06-pre1without the
caf42d4 commit and ykDroid 1.0 (I cannot install the debug version due to an problem while parsing the package) on my Nexus 5 (hammerhead) with Official LOS 14.1 (14.1-20180628-NIGHTLY-hammerhead) installed.

@pp3345

I might have an idea what's going on, but I am not sure. Can you please try the following APK: https://dev.pp3345.net/ykdroid-debug-signed-3f38214+.apk

It adds some debug output and a small change to NFC handling which might or might not help. In any case, please attach the logcat output from ykDroid after testing.

My database has been created using KeePassXC 2.3.3 under Fedora 28 and uses ChaCha20 and Argon2 (KDBX4) with compression enabled. Its master key is Challenge Response (YubiKey NEO Solt 2 Firmware 3.3.0) only.

In the KP2A app I've choosen "Password + Challenge-Response for Keepass XC" and did not enter any password before hitting the "UNLOCK" button. ykDroid shows up with Slot2 preselected but cannot find my YubiKey. After about 30 seconds I clicked on the back button.
LOGCAT yubikey.txt

The same behaviour occurs if I use a database with password + Challenge Response and enter the password before I hit the "UNLOCK" button.
LOGCAT yubikey2.txt

With ykDroid uninstalled the behaviour is again the same as in the first and second attempt.
LOGCAT yubikey3.txt

NOTE (!) that my YubiKeys NFC might be broken because Yubico Authenticator nor YubiClip are working. Unlock via USB ony my PC with KeePassXC is working though.

If I connect my YubiKey NEO via an OTG cable, Yubico Authenticator and ykDroid recognizes the insertion. Entering the master key password is not possible with the YubiKey conncted because the on-screen keyboard does not open. If I enter the password first, hit "UNLOCK" and then connect the YubiKey it does not work either. One time a button press on the YubiKey tried to switch between Slot 1 and 2.
LOGCAT yubikey4.txt

I hope my logs help rather than confuse..

from keepass2android.

Thank you for your tests, @mabachel.

Your NFC logs don't show any hint of ykDroid or Android detecting the YubiKey at all. You may test whether NFC is working at all by turning up the (ringtone or media, not sure) volume of your device and swiping the YubiKey over the NFC sensor on the home screen without any apps open. Android should play a sound and nothing else should happen (or a yubico.com page showing the serial number of your YubiKey might open in the browser). You can try the same procedure with any other Android device that supports NFC to test whether the issue is caused by the YubiKey or your Nexus 5, this shouldn't impose any security risks.

Entering the master key password is not possible with the YubiKey conncted because the on-screen keyboard does not open.

This is expected behavior. When no user mode driver (like ykDroid) is attached to the YubiKey, Android (precisely, the Linux kernel) will attach its own default USB-HID driver to which the YubiKey presents itself as a USB keyboard. Thus, Android thinks that there is a hardware keyboard attached and therefore doesn't show the on-screen keyboard.

Note that there is still an issue with the integration of ykDroid in Keepass2Android which causes problems when using USB. This will be fixed when #449 is merged. Nevertheless, the transaction within ykDroid itself should work fine, but your logs (yubikey4.txt) show that the response retrieved from the YubiKey is malformed. This could be caused by a bug in the ykDroid USB driver.

I cannot install the debug version due to an problem while parsing the package

Not sure why that happens, but can you please try this build: https://dev.pp3345.net/ykdroid-3f38214++-debug.apk
This build isn't signed, so you'll need to uninstall ykDroid before installing this one. It contains additional debug output both for NFC and USB that should help diagnose the issue. Please attach the logcat output again. Please note that the logcat output from this build will contain both the challenge and possibly the response, so you'll probably want to use an empty database for testing if you don't want to leak the response value.

from keepass2android.

@pp3345:

This is expected behavior. When no user mode driver (like ykDroid) is attached to the YubiKey, Android (precisely, the Linux kernel) will attach its own default USB-HID driver to which the YubiKey presents itself as a USB keyboard. Thus, Android thinks that there is a hardware keyboard attached and therefore doesn't show the on-screen keyboard.

That would depend entirely on what firmware you have installed, and what options are available in the Settings app. My Nexus 6 firmware keeps the OSK visible by default whether or not a physical keyboard is connected, although this option can be switched off.

Settings ⇒ System ⇒ Languages & input ⇒ Physical keyboard ⇒ Show virtual keyboard

Since regular user apps can also exercise a degree of control over whether or not the OSK is shown, this is something that could likely be worked around in KP2A for users who don't have a setting like this.

from keepass2android.

@rmenessec That's indeed correct, though I believe that most Android ROMs have this option turned off by default. It might also be possible to implement a better workaround in ykDroid by using a background service that keeps attached to the YubiKey, though that could cause issues when other USB drivers want to use the YubiKey (e. g. Yubico Authenticator). I'll look into that.

from keepass2android.

@pp3345, wouldn't it be a lot easier to just add a non-default option to KP2A to force displaying the OSK during credential input? 😊

PS: I'm afraid I've had some trouble following the course of the development of support for the new challenge-response mechanism in KP2A. I can't find documentation outside this issue. I'd like to test this out and add my own results.

... So, is ykDroid a prerequisite for KP2A's challenge-response mechanism to work?

from keepass2android.

@rmenessec Well, maybe it is, let's see what @PhilippC thinks ;-)

The current beta of KP2A has a port of YubiChallenge included, but additionally also supports ykDroid if it's installed. Generally, ykDroid will be necessary if you want to use USB instead of NFC, though ykDroid supports both. I'd appreciate some more testing for ykDroid as it seems that it doesn't yet work flawlessly for everyone.

from keepass2android.

@pp3345, seems to work flawlessly with the latest published KP2A beta on my Nexus 6 (LineageOS 15.1) via NFC, with ykDroid installed via the Play Store. No clear indication whether ykDroid was participating—I assume that's expected.

I used a tiny stub KDBXv4 AES256-Argon2 database created for the test, containing a single fake entry.

from keepass2android.

@rmenessec Thank you! You may distinguish ykDroid from the integrated YubiChallenge port in the current KP2A build by checking whether it looks like the screenshots on Google Play. ;-)

from keepass2android.

@rmenessec, et al.
I just wanted to post a quick update after the run of troubleshooting I posted a couple of weeks ago.

First of all, I want to publicly thank whoever contacted Yubico on my behalf. After I suggested that they would not likely provide support to an issue involving a pre-release 3rd-party app, I was surprised when they contacted me to assist me with the issues described in this thread and to let me know about their recall campaign on my early "developers edition" YubiKey NEO. They basically arranged to send me a replacement device and the whole experience was a great example of the amazing support provided by Yubico.

As soon as I received the new device, I programmed it with the same Challenge-Response codes I was using for testing in KP2A. However, this new device still would not unlock my test database. At that point, I just set it aside and continued to follow this thread for future developments.

Most recently, I saw mention of the ykDroid app, which I was previously unaware of. My previous testing was performed with and without the YubiChallenge app. After reading up on what ykDroid does, I replaced YubiChallenge with ykDroid on my Nexus 6. In this configuration, I was finally able to open my test database, using both the old and new NEO devices. I repeated the same process on my Nexus 5 and it also works on that device. Suffice it to say that I am thrilled to finally have this working.

I hope this feedback helps @PhilippC as he continues to develop this app. I also hope it provides some much deserved praise both to Yubico for their amazing level of support to their customers and to @pp3345 for his useful "driver app" that finally made this whole process work for me. Thanks again for everyone's continued effort to make KP2A such an amazing app!

R/
wbedard

from keepass2android.

@PhilippC, has anyone reported crashes in the new 1.06 release of KP2A? I looked here and in the Google+ Beta community but I didn't see any mention of it. When testing against the same workflows discussed in this thread, the new release crashes after reading the NEO (you can read the toasts about processing the master key...) and does so on both my Nexus devices. Rolling back to the previous beta release still works as previously reported. I'll post some logs over on Pastbin in a little bit but I wanted to give you a heads-up.

(Update: Link to logcat from my Nexus 6: https://pastebin.com/UDRn5Tf8)

from keepass2android.

@wbedard you are seeing #474

from keepass2android.

@PhilippC sorry to bother you here, but I'm not sure if cross-project mentions work. Could you please follow the linked ykDroid PR and add some thoughts too? :)

from keepass2android.

@PhilippC Will users be able to use PW+Keyfile+ChallengeResponse with the new implementation? If not, is it possible to support the option to do so?

from keepass2android.

@grenzor please see #456 for this
@IPv777 TOTP support is already there, KP2A is compatible to TrayTOP, KeeOTP and KeeWeb TOTP style.

from keepass2android.

@gamdow, the requirement for KBDX 4.x is right there in the release notes for K2A 1.06. You were literally forced to see it when you launched the new release for the first time.

from keepass2android.

@gamdow see keepassxreboot/keepassxc#1060 for the decision making process in KeepassX for this. Their old implementation was in general incompatible to most other Keepass implementation, they decided to keep the old way for backward compatibility and use the new way for KDBX4 databases.

from keepass2android.

Thanks for responding to my comment. My main reason for posting was in case anyone had overlooked it as I had and was wasting time trying to fix the wrong problem.

@rmenessec, As previously stated, I'm quiet lazy, and reading release notes falls under that umbrella. I also upgraded to the 1.06 beta release in order to get NFC working, so the problems were conflated. Before inspiration struck, I wasn't even aware of KDF, so I wouldn't have recognized the incompatibility from reading release notes anyway.

That said, I assume the KDF version must be part of the DB meta-data in order to decrypt it? So could app not have warned me about the incompatibility when I tried to open it? Or does it rely on file extension?

from keepass2android.

Is there any guidance on expected time to unlock databases with password and yubikey challenge response? It's taking 30+ seconds on an Android phone for me, which is much longer than I expected and longer than the 1 second on a laptop.

Environment is Qualcomm SDM630 Snapdragon 630 Octa-core 2.2 GHz Cortex-A53. Test database encryption settings are AES-256, Argon2 KDF, 19 rounds, 64 MiB memory, 4 threads.

While opening, I see a dialog with the following text:

working

loading database... (Transforming master key...)

(Thanks for all your work on this app!)

from keepass2android.

from keepass2android.

Maybe try to delete the data (and cache) of both apps (KP2A & ykDroid) ?
…
-------- Message d'origine -------- On 5 nov. 2018 à 19:45, JRussell a écrit :
This stopped working for me and I'm not sure why. I haven't changed anything. Using kp2a, ykdroid and a yubikey4 over USB. My USB keys work fine in Windows but on my phone I'm getting a toast that says "The challenge response is incorrect." then just sits at "Working..." indefinitely. I usually use Nextcloud but also tried copying the database straight to my phone and both give the same results. I figured this should be here but let me know if I should open a new issue. — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](#4 (comment)), or mute the thread.

I tried uninstalling and reinstalling both apps. Same result. I should add that this is happening on both of my phones. Sony XZ1 Compact and Pixel 3. Running the latest kp2a beta from the play store.

from keepass2android.

@JRussell I suggest you open a new issue for this.
Can you please

• try with the 1.06f release (https://github.com/PhilippC/keepass2android/releases/tag/1.06f)
• Enable debug logging and send me the log (here or to [email protected])?

from keepass2android.

new issue opened: #609

from keepass2android.

@JRussell Might be unrelated, but I had the similar issue trying to share a db from KeepassXC. Found out that the version of the db was KDBX 3.1 . Changing it to version KDBX 4 and it all worked happily. I'm not using Argon2 yet, either if that makes any difference. Will change to that later when the decrypt gets faster.

from keepass2android.

The decryption won't get faster. The speed depends on the number of transformation rounds you have configured. KDBX4 is generally slower, because it has a better derivation function. That is intended behaviour.

from keepass2android.

I think the reason you experience that the db is very slow is mainly because of the Argon2 algorithm, rather than KDBX4 format per se. I might be misremembering, but I think Argon2 is much more memory intensive compared to AES. And since phones have much slower memory than a PC, it would be a pretty noticeable difference.

However, you can still use the KDBX4 format but with AES encryption. That would be much faster on a phone, but still support YubiKey on KeePass2Android.

from keepass2android.

@lindhe is correct. I'm using AES until issue #306 is resolved.

from keepass2android.

are there any security drawbacks using AES-KDF vs. Argon2?

from keepass2android.