Pasting the password

[Ricardo]

Okay, I see a bit of a pattern here: When I first use the SQRL app, I must enter my full password (manually), in this instance, although I just scanned the QRcode as an attempt to log in to the forum page, it will fail. I have to make a second attempt and then it succeeds (having asked for the first 4 characters, or in this last try it was happy to ask for my finger print authentication (nice).

So my changing password earlier seemed to cause some hiccup that worked itself out, and now it can still take two attempts to succeed.
If the app decides it wants the full password again, I have to get past that, then try the login again a second time to get success.

 

[Ricardo]

It settled down and seems to consistently go for a finger print request to log me in (for tries after the first attempt).
I see there is another thread for the "needing to scan login twice" situation.
So nothing left new here. I seem to be all good otherwise now.
Thanks!

 

[Ricardo]

Update, If I am not already logged in to the SQRL app on my pixelXL, It requires the password of course, then as before, it does not log me into this (sqrl.grc.com on PC Firefox browser) page. I then scan the QR code again, the app just asks for a fingerprint, and then I do get logged in after providing that. App was just updated from PlayStore, I am showing version 0.14.0

 

[kalaspuffar]

Hi Ricardo.

Thank you for the report. How long did you wait after the first login? The site takes some time to trigger and then reload.
The worst I've seen is about a minute. But I guess it can differ.

Best regards
Daniel

 

[Ricardo]

Interesting, I just restarted SQRL and retried it. This time it did work on the first try. It took less than 30 seconds.

I watch as the app gives a sort of bar graph of time for decript/encrypt process, and I always wait a bit after that has completed. Don't know if or how often I would wait a minute or more beyond that in the past.

Just using the app my expectation was that after the SQRL app had given an indication visually that it was done with the processing on the phone, and had returned to the initial visual state before any login attempt, I would wait an additional brief period of time for the Web server to respond. Probably not more than 10 or 15 seconds more at that point.
Anyway, it worked first time just now and with two more tests.

I will repeat testing periodically, to see the new (good) normal. Thanks!


Bye the way, I am getting messages on my browser lately, when trying to post and such:

"Oops! We ran into some problems.
Security error occurred. Please press back, refresh the page, and try again."


-a Gibson server issue? Perhaps my browser plugins are the gremlin?

It won't let me log out either.
I have to close the browser tab, open a new one and reload the page, then I can post.

 

[Ricardo]

Update, now it is letting me post just fine.

I have a new error message pop up on the Android.
I think this was after the app had timed out, because it then requested the password instead of fingerprint.

 

[kalaspuffar]

Hi again @Ricardo

I think we might be on to something on the other thread.

https://sqrl.grc.com/threads/needing-to-scan-login-twice.349/post-3741

Not really sure why they change the nut in while in transit but it seems reasonable as an error. Maybe we need to listen to two or three nuts like you do with RSA code dongles.

Best regards
Daniel

 

[Ricardo]

I will check out the other thread.
Thanks

 

[GotSQRL]

I just updated with the latest reference SQRL Windows client, where I was able to paste my super long password to login. I get the need to only type in the full password rarely, then use the short password. I can live with typing it in every once in a while since I am security conscious, but the general masses would find it too high of a bar and revert to using a short password.

 

[TecMunky]

Yes. I believe that allowing cutting / copying / pasting the password or Rescue Code should be strongly discouraged. It's trivially easy for apps to monitor and capture the system clipboard. It's convenient as hell, and also insecure as hell.

As of the NEXT version of Android (Q-something) apps will no longer be able to capture the clipboard.
Perhaps it would be useful to allow copy and pasting from LastPass on that version ...

I also had to change my password from something long and unmemorable to something else (still long, but now memorable).
I think this reduces security in it's own way.

 

[sengsational]

Steve is right that (for pre-Q at least), an evil flashlight app or whatever could trivially get your "keys to the kingdom" (SQRL master password), so putting your master password in the clipboard on current Android is a Bad Idea. As I understand it from reading just a few minutes on the topic, using version Q, regular apps won't be able to monitor the clipboard from the background, as they can today. That covers the majority of the problem, but system level apps will still be able to monitor the clipboard in the background.

 

[DetlevSchm]

As of the NEXT version of Android (Q-something) apps will no longer be able to capture the clipboard.

Not quite.

The announcement says:

Unless your app is the default input method editor (IME) or is the app that currently has focus, your app cannot access clipboard data.

So, an app A that has the focus can write to the clipboard, and an app B that has the focus can read from it, but an app C, lurking in the background, cannot observe the clipboard anymore (unless app C runs in compatibility mode).

 

[sengsational]

The use-case we're talking about is where someone selects a password in a password manager app (ie LastPass), switches directly to the SQRL client and does a paste. At that point, the SQRL client would wipe the clipboard.

Obviously you trust your password manager and you trust your SQRL client. "IME" is basically the keyboard wedge, so if you stick with the standard keyboard, you should be free of bad actors there too.

My reading of the announcement left me with the impression that if the device was running "Q", then the reading of the clipboard was foreground app only (and keyboard), regardless of anything else. That's not true for the file sharing, but looks like it's true for clipboard.