plain text encryption password in URL line!

[jn0]

It is.

[wwebfor]

Where did you discover it? In settings page?

[jn0]

No, I tried to login to a fresh install, then get to Options, set the encryption password and got back to start page. The prompt for enc key got me to a page with password in URL.

[jhallard]

https://i.redd.it/096w6x07l3px.png

come on guys

[privacytoolsIO]

https://www.reddit.com/r/softwaregore/comments/55j9wg/very_secure_password_storage_password/

[claell]

Might it be possible that this is OS/browser specific? Seems like all screenshots are taken on Windows?

[miestasmia]

@claell No. The password is simply transferred through GET. These guys are just entirely ignorant of security. This isn't a bug, this is negligence.

[Yrlish]

@claell This is either OS or browser specific. This is the result of an badly coded application. One does not simply transfer PASSWORDS in plaintext through GET.....

And this issue has been open for over 6 months! Fix this shit already!

[claell]

@miestasmia @Yrlish This is not happening for all users. So in some cases there is this bad transferring and in others it is not. I was wondering what causes this.

[miestasmia]

@claell I gather they intended for it to use POST but for whatever reason your browser might be falling back to GET, and they used something similar to PHP's $_REQUEST which doesn't care where it comes from, which is why it's gone unfixed.

[jn0]

This becomes even more anecdotic :)

[wwebfor]

Sorry, but this happens NOT because your password is transferred somewhere but because on the first start after typing the password, you probably typed ENTER. It happens simply because we didn't prevent the default behaviour.

The intended behaviour on the first start was clicking on "next" button instead of submitting the form. Then, the password would be saved in indexeddb. The issue can be fixed by preventing form submission altogether.

A lot of you seem to be thinking that the password was intended to be transferred to the server especially here, but in fact the password was never meant to be transferred anywhere not with POST request and definitely not with GET request.

Sorry for keeping issues opened for such a long time we did not have enough time to keep track of them.

[wwebfor]

The bug was fixed. As I said, it was happening simply because we forgot to prevent the default form behavior. Thank you @jn0 for reporting the issue.

[bunnitech]

I am using Chrome Version 59.0.3071.115 (Official Build) (64-bit) on Windows 10 Pro x64 and I just experienced this issue. The password I entered is shown in plaintext in the url bar, stored in my browser history, shown to whoever via autocomplete showing this url (esp. when I type Laverna). Password disclosure is a high severity security vulnerability, especially when my browser history containing a plaintext password may be disclosed to a remote attacker.

The issue happened when I created an encrypted instance for the first time under my configuration. The URL with the password is the one shown immediately after the screen which says 'unlock' and selecting an app. It is displayed as follows: https://laverna.cc/app/?password=PLAINTEXT&cloudStorage=0#/notes/f/task

I'm not sure but I think best practice here is to pass and compare a hash or don't use form submission at all.