Feel free to try out heylogin and let me what you think of it. I know we don't have feature parity with 1pw, but we try to innovate on the core user experience of logging into websites first. Our typical users are non-IT people, but more and more features are now implemented to also cater IT pros.
Thanks for popping by! Feature parity with 1Password would actually count against you, it's so bloated with stuff only huge enterprises need now, and all its best features have been removed over the last few years. I checked our 1Password billing and it seems we're paid up until Dec 2027, so if you've got good passkey support by then you may well have a new customer.
passkey support is currently in internal beta, but will be released soon.
what kind of features have been removed from 1pw that you considered important?
Oh man, I don't think that essay would fit in a HN comment. The biggest one for me though was keyboard operation - I have fine motor control problems so try to use the trackpad as little as possible. 1Password used to have two different global keyboard shortcuts, one for the regular autofill interface and another that would pop up a mini version of 1Password that was fully keyboard navigable and could do almost everything the full 1Password app could do. I could hit Cmd+Opt+\ from anywhere and then entirely through keyboard interactions do almost anything I needed to do. This has been replaced by one global keyboard shortcut that only works if your focussed app is a browser with a login screen on it, and even then it often needs hitting multiple times in order for the interface to appear, and sometimes never appears at all until you finally give up and launch the 1Password app, and then magically you get the 1Password app with the 1Password mini interface over the top of it. It's one of the most frustrating experiences imaginable when it used to be such a useful thing.
Thanks, that's interesting. We don't see all the smaller changes our competitors are doing.
With heylogin, you could try our Quick Access feature. It pops up with a global shortcut and is fully keyboard navigable. Let me know if something is missing there.
Goldberg's answer "The 1Password Secret Key may not be the most user-friendly aspect of our human-centered design..." is unfortunately true.
We experienced a lack of understanding on the user side that this secret key needs to be printed and stored safely. It feels like a huge barrier for the adoption of 1Password for non-IT affine people.
This and other challenges led us to develop heylogin which does not require a master password and has no secret key that needs to be printed. Instead we generate cryptographic keys using the user's smartphone. For providing your desktop browser temporary access to passwords you simply confirm on your smartphone. This feels similar to modern SSO solutions but is technically a password manager.
In our experience, a user with one phone doesn't really need this key. You'll always be able to log from that phone into that phone's vault with just the password.
It's only if you're adding another device or logging in online, or replacing a lost first device with no backup, that you need the 2nd piece of key material.
Secret keys are backed up in order to recover the data in the event of device loss, and master passwords are used to prevent data access by an attacker with disk access, including access to device backups in the cloud. Am I misunderstanding, or are you just accepting that the data gets lost or breached in those situations?
I think we can do better in protecting vaults against offline brute force attacks.
As written in the this post, 1Password uses a randomly generated "secret key" together with the user-chosen master password. This "secret key" is not stored on 1Password's servers, instead it should be printed on a piece of paper and stored safely.
While this is a good starting point, it significantly reduces usability, since you need this piece of paper when re-installing 1Password.
At heylogin, we are rethinking this cryptographic design. In our case, a random secret is generated inside the smartphone's security chip. From this secret, all keys for encryption are derived. The smartphone app and the browser extension is end-to-end encrypted and authenticated using an out-of-band QR code.
This results in the following UX: To log into a website in the browser, the user needs to confirm on the phone. The app now provides the extension with temporary access to the passwords etc (a little bit more complicated to explain here).
Thus, if the same breach would happen to us, the vaults would still be secure, since the e2ee does not depend on a user chosen master password.
It's not easy to get a foot in this market, but I am confident, we can do it.
> This "secret key" is not stored on 1Password's servers, instead it should be printed on a piece of paper and stored safely. While this is a good starting point, it significantly reduces usability, since you need this piece of paper when re-installing 1Password.
you can bootstrap from an existing installation too. you’re painting this to be more of a hassle than it actually is in practice.
maybe… I sort of agree it's not a huge hassle when recovering from another still functional 1Password installation. I still think that the initial flow of asking the user to print something that looks complicated is something that turns away users who are less IT-savvy.
You are asking the right & also complicated questions :)
Let me first say that we are just finishing up a version 2 of our whitepaper that can answer all questions regarding the cryptographic architecture including these scenarios. We'll announce that in the next 2-4 weeks when it's ready.
There are different scenarios here:
* If you install heylogin on a new phone, you will get asked to transfer your account to the new one. If you confirm, everything is cleared on the old phone, secrets are regenerated and date is re-encrypted.
* If you are using the team features of heylogin, your admin can disable your old phone (even if it's broken) and you can connect a new one with the help of the admin. The secrets are re-generated and data is re-encrypted. The underlying architecture is a little bit more difficult here and will be explained in the whitepaper.
* You can write down a backup code and use this for recovery (I like this method the least)
* We'll soon have a feature where you can add a security key as another method of accessing your data. This will also help in re-gaining access if the phone is lost.
* We'll also probably have a "social recovery" in the future, similar to the admin recovery flow but for private users.
Internally, we have more ideas to provide transfer & recovery flows. We'll keep on experimenting.
Since secrets are re-generated and data is re-encrypted, even if the old phone is broken, the TMP no longer holds secrets that are usable to decrypt the data.
I would legit pay money for Google to pull that piece of junk from the Play Store, because it's damn malpractice at this point, given there are so many other options that don't straight-up swallow the TOTP keys
You can back the secrets up to a text file, print them out, etc. too. They're short Base32 strings and TOTP is a standardized protocol with an RFC (6238) and everything.
Except it is cumbersome to doo on Google Authenticator. You must press export to get shown a giant QR code. You can't screenshot it. Must photo with different phone and print on a piece of paper for offline storage.
This is a wake up to call to not build your security model on a user chosen master password!
Since the vaults have been stolen, an offline brute force attack can be executed. This attack is no longer slowed down by online protection mechanisms, such as blocking IP addresses. Rather, security now depends solely on the cryptography and thus on the master password chosen by the user.
In the end, it is a single factor that separates the attacker from the encrypted data. If less IT-savvy employees are not adequately trained and supported in choosing the master password, the result is fatal. The extent of this will become clear in the coming months when the attacker has cracked the first master passwords and compromises accounts.
At heylogin, we believe that this security model of traditional password managers has come to an end. That's why we built a new solution that uses the secure element of smartphones to implement end-to-end encryption that is 2-factor secure by default and works without a master password.If our users' encrypted databases were stolen, the attacker would not be able to perform a brute force attack.
Great work Fabian! Nice to see this work becoming open source.
I am pretty new to fuzzing, please correct me if I am wrong: Since Jazzer fuzzes a Java application at runtime, can it be in principle also be used to fuzz a Java app without having it's source code?
Yes, that is exactly how it works, there is nothing that would require source code access.
If you have a Java app packaged as app.jar, all you need to do is write a fuzz target (with the fuzzerTestOneInput function) and package it into e.g. target.jar. Then you can run jazzer with
I agree that it's weird that they fixed it and didn't consider it a security issue.
For the user it looked like it would provide two-factor authentication since the PIN is requested, while in reality it's not verified. Thus, they only provided one-factor security.
I came to a similar conclusion: U2F hardware is the way to go. For some people, smartphones are becoming the only device they use. However, I am not fully convinced of using the device itself as a U2F key. Then it's no longer a two-factor solution. Thus, I envision the use of U2F hardware with mobile devices as the future of authentication.
Unfortunately, it is still difficult to find the NFC "sweetspot" at the back of your phone. At Cotech, we work on a Hardware Security SDK that solves this and works independent of Google Play Services. It brings support for U2F Hardware over NFC and USB to Android phones: https://hwsecurity.dev/fido/
Feel free to try out heylogin and let me what you think of it. I know we don't have feature parity with 1pw, but we try to innovate on the core user experience of logging into websites first. Our typical users are non-IT people, but more and more features are now implemented to also cater IT pros.