Critical Concern: Potential E2E Encryption Risk in QR Login Flow

  • Unknown's avatar

    Hello Day One Support Team,

    I am reaching out with a serious concern regarding the QR-based login method and how it interacts with Day One’s end-to-end encryption policy.

    According to your security documentation, the Encryption Key never leaves the user’s device. However, during my recent experience, I noticed something that appears to contradict this. I was connected to Wi-Fi on my laptop and using mobile data on my phone. When I scanned the QR code displayed on my laptop using my phone and tapped “Approve,” the Day One app on my laptop logged in immediately with all journals already unlocked — without requiring me to manually enter the Encryption Key.

    This behavior strongly suggests that the Encryption Key, or a derivative sufficient to unlock the journals, is being transmitted through your servers during the QR approval process. If that is the case, it would not align with the principles of true end-to-end encryption.

    Could you please clarify how the QR login system works internally?
    Specifically:

    • What is transmitted during the QR approval process?
    • Is any form of the Encryption Key shared with or relayed through Day One servers?
    • What safeguards exist to prevent interception if sensitive data is involved?
    • What are the implications if such information were ever compromised?

    I am deeply concerned about the security model, especially since users cannot regenerate or rotate their Encryption Key. If the key were compromised at any stage, there would be no recovery path.

    For other users reading this: if you also consider this a significant issue, please share your feedback so that it can receive proper attention.

    Thank you.

  • Hello @subarnabsadhukhan,

    Great questions. We reached out to our engineers so we could get the best explanation on how Day One does this while still managing to keep things end-to-end encrypted. Here is what they said:

    The web app generates a random one-time encryption key called a “login key” and encodes it into the QR code that is shown on the screen. That login key is never sent to the server. The app scans the QR code and extracts the login key.

    The app then encrypts your master key with the login key and sends it into a waiting inbox on the server. The server can’t decrypt your master key because it doesn’t have the login key. But it notifies the web app that there’s something in the inbox. The web app downloads it and decrypts it locally.

    The code that generates the login key is all running in your browser on your computer. The server never sees the login key.

    This allows the login key to act as a “secure communication channel” between the app on your phone and the web app in your browser. The two can talk to each other (and pass your encryption key across) without the server ever seeing it.

    Hopefully this helps clarify how that works. If you do have any other questions, please let us know.

  • Unknown's avatar

    Thank you for taking the time to address my concern. I’ve now understood the process clearly.

  • You’re very welcome, @subarnabsadhukhan :)

    We appreciate the question and I am glad we could clarify how it works in case others are curious, too!

  • The topic ‘Critical Concern: Potential E2E Encryption Risk in QR Login Flow’ is closed to new replies.