ubuntu-phone team mailing list archive

[Ricardo Kirkner <ricardo.kirkner@xxxxxxxxxxxxx>]

The main reason we ask for password confirmation during purchases is that
we want to ensure that the account owner is actually still behind the phone
and to prevent unlocked phone's abuse (on purchases specifically).

With that in context, and given how other platforms support purchases from
the phone (thinking about Google and Amazon doing 1-click purchases) we
could get rid of token refresh in 2 ways

1. Use a different token for login and purchases (this would allow the user
to invalidate each of those independently). The purchase token could have a
larger TTL (like 99 years :)) than the login token.
2. We could still use the same token, and still require the user to
authenticate by locking the keyring with an unrelated un simpler password
maybe (eg, using the phone's unlocking PIN?; this would require to do
something similar for the dash/desktop though)

This is just out of the top of my head... will keep thinking about better
options


On Mon, Sep 1, 2014 at 3:39 PM, Martin Albisetti <
martin.albisetti@xxxxxxxxxxxxx> wrote:

> So, iCloud was hacked somehow. I haven't seen any details as to how,
> but reading about people panicked and confused on twitter led me to a
> tweet[1] that said:
>
> "Of course people pick terrible iCloud passwords. You can't enter a
> good password 50x per week on a mobile device. You'll go carpal."
>
> Which makes perfect sense. We have the same problem, we have a single
> sign on system, which is great for some things, but given the
> introduction of the phone with a touch-screen keyboard and mandatory
> password re-entry on app purchasing as well as new influx of users who
> create their account for the first time on the phone, people will tend
> to pick less secure passwords.
>
> Leaving aside 2FA as the answer, as it's clearly not widely adopted
> (for its complexity?), what can we do to make this a bit better in our
> platform?
> Can we confirm purchases and other tasks that are frequently used
> somehow differently than with the account password, and encourage
> (and/or force) better passwords for the general account?
>
> To try and reduce the scope of the discussion, I'm mostly looking for
> proposals that would be implementable in the short or mid term, rather
> than changes that would require 6 or more months to implement across
> the platform (which we may need to, but I wouldn't want to start off
> that discussion here and now).
>
>
> Any other ideas?
>
>
>
> thanks!
>
>
> [1] https://twitter.com/matthew_d_green/status/506427220546826240
> --
> Martin
>