Summer of Code

[Ronni Elken Lindsgaard]

Hi everyone

During the summer vacation I am planning on working on some stuff for RndPhrase, and I would like your input before I start. I have several things planned and I don't expect to get through it all, but either way I believe these things could benefit RndPhrase as a whole, and maybe if we get a good discussion it can be used in the future.

## RndPhrase Mobile
### The project
First of all I would like to make an app for mobile devices. Personally I use rndphrase just about everywhere, and it is quite cumbersome having to load a url everytime I need the service (although it always is my first tab on the device).

Even though the service does not require heavy computing I believe that native code is best. To get multi-platform from the start I am contemplating developing the mobile app in titanium. Another benefit is that the code is kept in java.

I am interested in opinions about this choice before venturing into titanium mobile, especially if anyone has serious pros or cons for this choice.

### Source organization
Another thing is the organization of the sourcecode. I have given this some thought and have come to the conclusion that RndPhrase Mobile should be a separate project, however it would be handy to have some shared files, some of the core files, such that hashing on the mobile devices as well as for the browser plugins are always 100% in sync.

Does anybody have ideas for that? Maybe just hosting the core files on appspot, or somewhere else so that they can always be referenced?

## Expanding the plugin userinterface
### Settings for domains
I guess most of us have the problem that RndPhrase cannot be used on some websites because they ask for a maximum number, special characters or similar in the password.

The code already supports configuration for this https://github.com/Freaken/RndPhrase/commit/856cb1df777f115c552348f82759841fa1843e65 (I don't know if this code is compatible with the latest RndPhrase release) but there is no frontend for this. It is a bit problematic that you need to "compile" the source yourself to get this feature. Therefore I would like to make a management section where it is possible to specify configurations for a specific domain. I think the following settings are relevant, but this list is probably not exhausted

* Maximum length of password (int)
* Special chars required (bool) or Max/Min number of special chars required (int/int)
* List of special chars allowed (char[])
* Numerals required (bool) or Max/Min number of numerals required (int/int)
* Capital letters required (bool) or Max/Min number of capital letters required (int/int)
* Lowercase letters required (bool) or Max/Min number of capital letters required (int/int)

I believe the max/min versions should be implemented as you newer know what morons programmed the password check

### Settings dialog to improve UX
This is a nice to have, but really user friendly :) Mathis Svensson gave me this idea, that when you hit @@ instead of just @ when entering your password, a dialog for the settings appear and you can manage the settings for a specific domain.
Any other ideas how to make the functionality more accesible?

Please discuss the above, and feel free to contact me if you want to help with any of the above. RndPhrase mobile is on the top of my wishlist currently, so this is probably where I'll start unless anyone else wants to give a hand with some of the other things

Regards

Ronni Elken Lindsgaard

[Johan Brinch]

Excellent news and some well thought out suggestions!

I'll write a proper reply with my comments and ideas sometime next week when I have the time (some of suggestions are things I've put thought into but never actually done).

I welcome and support the initiative!

> --
>  
> ---
> You received this message because you are subscribed to the Google Groups "RndPhrase" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rndphrase+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

[Johan Brinch]

Great news Ronni, there is so much room for improvement in the
RndPhrase addons! I'll try and fill you in on my thoughts.

On Thu, May 23, 2013 at 10:29 AM, Ronni Elken Lindsgaard
<ronni.li...@gmail.com> wrote:
> ## RndPhrase Mobile
> ### The project
> First of all I would like to make an app for mobile devices. Personally I
> use rndphrase just about everywhere, and it is quite cumbersome having to
> load a url everytime I need the service (although it always is my first tab
> on the device).
>
> Even though the service does not require heavy computing I believe that
> native code is best. To get multi-platform from the start I am contemplating
> developing the mobile app in titanium. Another benefit is that the code is
> kept in java.
>
> I am interested in opinions about this choice before venturing into titanium
> mobile, especially if anyone has serious pros or cons for this choice.

I would probably just go with an HTML-based app that could load the
existing JS implementation. It's just the easiest.

Is there something UI-wise that you think could be done more friendly
in a native app? Copy-to-clipboard perhaps? I don't know that much
about apps, but I too find it awkward to load the appspot site in a
browser to login to GMail.

> ### Source organization
> Another thing is the organization of the sourcecode. I have given this some
> thought and have come to the conclusion that RndPhrase Mobile should be a
> separate project, however it would be handy to have some shared files, some
> of the core files, such that hashing on the mobile devices as well as for
> the browser plugins are always 100% in sync.
>
> Does anybody have ideas for that? Maybe just hosting the core files on
> appspot, or somewhere else so that they can always be referenced?

We could definitely put the core files on appspot. No problem. And you
can get them through HTTPS and cache them locally. I guess the amount
of code that can be shared depends on the choice with respect to
implementation of the app.

> ## Expanding the plugin userinterface
> ### Settings for domains
> I guess most of us have the problem that RndPhrase cannot be used on some
> websites because they ask for a maximum number, special characters or
> similar in the password.

I think it's safe to use "all of us" here ;) I bitch like a little
girl every time a site rejects an RndPhrase for being "insecure" and I
have to remember that on this domain I added something weird to the
password. It sucks.

> The code already supports configuration for this
> https://github.com/Freaken/RndPhrase/commit/856cb1df777f115c552348f82759841fa1843e65
> (I don't know if this code is compatible with the latest RndPhrase release)
> but there is no frontend for this. It is a bit problematic that you need to
> "compile" the source yourself to get this feature. Therefore I would like to
> make a management section where it is possible to specify configurations for
> a specific domain.

It was always the intend that there should be some UI support for
this, however implementing the flexibility in the code was easier than
doing the feature in the UI. It should however be compatible with
every RndPhrase, as all it does is let you set a modifier-function
that is allowed to modify the generated password (e.g. append capital
"A") whenever its associated regex matches the domain. The basic idea
is that an unpredictable password + something predictable is still an
unpredictable password.

> I think the following settings are relevant, but this
> list is probably not exhausted
>
> * Maximum length of password (int)
> * Special chars required (bool) or Max/Min number of special chars required
> (int/int)
> * List of special chars allowed (char[])
> * Numerals required (bool) or Max/Min number of numerals required (int/int)
> * Capital letters required (bool) or Max/Min number of capital letters
> required (int/int)
> * Lowercase letters required (bool) or Max/Min number of capital letters
> required (int/int)

These fall into two categories:
* Rules that add something else to the password: no security problem here
* Rules that restrict the password somehow (e.g. size limit, digits
only, no digits): we need to be more careful here

A good place to start could be:
* Size limit (keep it above 8 though, maybe warn the user if going
critically low)
* Add capital letter
* Add "-" (some sites limit the special chars that "counts", but
*surely* everyone counts "-")

It's important that the rules doesn't yield information about the
generated password. For example, I have a site where my generated
password by coincidence doesn't contain any digits (it happens) and
that site, by further unfortunate coincidence, requires at least one
digit.

Now, the naïve rule would fix this by appending a digit, however that
tells everyone who can see the rules (which are simply stored inside
the browser) that the password is 16 letters followed by a digit;
perhaps not an issue since 16 letters is still difficult to guess, but
the other case of 16 digits (obviously less likely) is way worse.

A better way to implement this is to throw out the password and
generate a new one (e.g. by using the first password as the RndPhrase
password). Repeat until the criteria is met. This would only leak that
the password isn't among those that does not meat the criteria set by
the site, which is OK.

So, if possible, the rule should be met by generating a new password
using the prior. If not, add something to the existing password.

This leaves the cases where we have to lessen security significantly,
either because of a size limit or a digits-only limit. Those sites
sucks and enabling such a rule should show a warning of some kind.


NB: with respect to special characters, it's difficult. Some sites
requires a special character. Fine. However, some requires a special
character from their own *chosen* set (e.g. one of "_-.!?") and some
take this further by *only* accepting special characters from their
set (e.g. "-" fulfills the requirement while "%" is an error (by the
way, if that's the way you protect your site against SQL-injections
I'd rather not have an account)). Password "security" rules can be
ridiculous like that.

> ### Settings dialog to improve UX
> This is a nice to have, but really user friendly :) Mathis Svensson gave me
> this idea, that when you hit @@ instead of just @ when entering your
> password, a dialog for the settings appear and you can manage the settings
> for a specific domain.
> Any other ideas how to make the functionality more accesible?

My idea was to add a sub-menu to the existing right-click context menu:
"RndPhrase" ->
* "Add capital 'A' on this domain."
* "Add special char '-' on this domain."
* "Limit size to 12 characters."

Items for the most common rules. But whatever makes it easy to work
with is good.


--
Johan Brinch

[Ronni Elken Lindsgaard]

On 3 June 2013 23:21, Johan Brinch <zer...@gmail.com> wrote:

Great news Ronni, there is so much room for improvement in the
RndPhrase addons! I'll try and fill you in on my thoughts.

On Thu, May 23, 2013 at 10:29 AM, Ronni Elken Lindsgaard
<ronni.li...@gmail.com> wrote:
> ## RndPhrase Mobile
> ### The project
> First of all I would like to make an app for mobile devices. Personally I
> use rndphrase just about everywhere, and it is quite cumbersome having to
> load a url everytime I need the service (although it always is my first tab
> on the device).
>
> Even though the service does not require heavy computing I believe that
> native code is best. To get multi-platform from the start I am contemplating
> developing the mobile app in titanium. Another benefit is that the code is
> kept in java.
>
> I am interested in opinions about this choice before venturing into titanium
> mobile, especially if anyone has serious pros or cons for this choice.

I would probably just go with an HTML-based app that could load the
existing JS implementation. It's just the easiest.

Is there something UI-wise that you think could be done more friendly
in a native app? Copy-to-clipboard perhaps? I don't know that much
about apps, but I too find it awkward to load the appspot site in a
browser to login to GMail.

 

I have a number of reasons for not going with an HTML based app. Here are some of my main reasons. I admit that some of them are more prejudice than result of research on the matter :)

1. As you pointed out, I would like to use precisely copy-to-clipboard functionality. The main objective is to eleminate as many taps as possible. Currently I have to type in my seed, password and domain. Afterward I have to double-tap to get a dialog where I can mark the entire generated hash, and then I have to tap to copy the marked text.

I don't know whether it is possible to use copy-to-clipboard from an HTML based app, but I'd frankly just like to avoid finding out.

2. Not only will I have to depend on different OSes. I will also have to depend on their rendering engines - and they are just about as crappy as the rendering engines of our desktop browsers I believe :P

3. Although I am fond of javascript (for an interpreted language). I would very much like to avoid HTML/CSS as they are a pain in the arse. Especially since I very well know how to implement the UI without them.

4. It is hard to get the look and feel of a native app with a HTML based app. I believe very much in the user experience of mobile apps. Even though the functionality is simple, I still believe that it will take some degree of effort to make it feel proper cross platform. I would rather spend my time on implementing features ;)

5. I have some other UX ideas to get a good flow that I do not know how or whether I can implement them with a HTML based app.

6. I have a personal interest in doing a project in titanium in order to know whether it is worth anything for larger projects. I believe this project is small enough not to be easily implemented, but still large enough to get a proper feel of what those guys at appcelerator are doing. Otherwise I would probably choose to do parallel native implementations in at least iOS and Android.

> ### Source organization
> Another thing is the organization of the sourcecode. I have given this some
> thought and have come to the conclusion that RndPhrase Mobile should be a
> separate project, however it would be handy to have some shared files, some
> of the core files, such that hashing on the mobile devices as well as for
> the browser plugins are always 100% in sync.
>
> Does anybody have ideas for that? Maybe just hosting the core files on
> appspot, or somewhere else so that they can always be referenced?

We could definitely put the core files on appspot. No problem. And you
can get them through HTTPS and cache them locally. I guess the amount
of code that can be shared depends on the choice with respect to
implementation of the app.

Sweet. Currently I'm just focusing on getting a prototype of the app working. When I get around to it I will try changing the original project to my needs. I will ping you for ideas when I get around to it. I don't suspect it will be much effort to adjust the source to my needs though.

 

> ## Expanding the plugin userinterface
> ### Settings for domains
> I guess most of us have the problem that RndPhrase cannot be used on some
> websites because they ask for a maximum number, special characters or
> similar in the password.

I think it's safe to use "all of us" here ;) I bitch like a little
girl every time a site rejects an RndPhrase for being "insecure" and I
have to remember that on this domain I added something weird to the
password. It sucks.

 

:)

* Maybe it would just be easier to have a textfield where one can append whatever special characters and capital letters are needed.

* A warning for sizes below 8 is a must have ;)

It's important that the rules doesn't yield information about the
generated password. For example, I have a site where my generated
password by coincidence doesn't contain any digits (it happens) and
that site, by further unfortunate coincidence, requires at least one
digit.

Now, the naïve rule would fix this by appending a digit, however that
tells everyone who can see the rules (which are simply stored inside
the browser) that the password is 16 letters followed by a digit;
perhaps not an issue since 16 letters is still difficult to guess, but
the other case of 16 digits (obviously less likely) is way worse.

You are completely right, great point.

 

A better way to implement this is to throw out the password and
generate a new one (e.g. by using the first password as the RndPhrase
password). Repeat until the criteria is met. This would only leak that
the password isn't among those that does not meat the criteria set by
the site, which is OK.

So, if possible, the rule should be met by generating a new password
using the prior. If not, add something to the existing password.

Am I understanding you correctly? If a generated hash does not yield a valid hash you would just feed the generated hash into the hashing function again and again until getting a valid hash?

In thus case: I smell a possibly large (if not infinite) series of computation when the password is restricted to letters only and is sufficiently large. I congratulate you on having found one :P 

What I suppose we could do is take a substring of the generated hash that actually is valid, and then run hashing on the previous algorithm again and take what we need ... until we meet the termination condition of a properly large string.

I haven't thought about all the implications, but will a scheme like this work? Do we reveal anything about the components that make up the final hash like this?

 

This leaves the cases where we have to lessen security significantly,
either because of a size limit or a digits-only limit. Those sites
sucks and enabling such a rule should show a warning of some kind.

NB: with respect to special characters, it's difficult. Some sites
requires a special character. Fine. However, some requires a special
character from their own *chosen* set (e.g. one of "_-.!?") and some
take this further by *only* accepting special characters from their
set (e.g. "-" fulfills the requirement while "%" is an error (by the
way, if that's the way you protect your site against SQL-injections
I'd rather not have an account)). Password "security" rules can be
ridiculous like that.

> ### Settings dialog to improve UX
> This is a nice to have, but really user friendly :) Mathis Svensson gave me
> this idea, that when you hit @@ instead of just @ when entering your
> password, a dialog for the settings appear and you can manage the settings
> for a specific domain.
> Any other ideas how to make the functionality more accesible?

My idea was to add a sub-menu to the existing right-click context menu:
"RndPhrase" ->
* "Add capital 'A' on this domain."
* "Add special char '-' on this domain."
* "Limit size to 12 characters."

Items for the most common rules. But whatever makes it easy to work
with is good.

I wasn't aware that it is possible to change the right-click context menu :) 

It sounds like a good first approach, it takes the design out of our hands (phew) and integrates with system behaviour - I like that in usability (as long as I can also configure my system to behave like I want :P)

--
Mvh
Ronni Elken Lindsgaard

[Johan Brinch]

On Tue, Jun 4, 2013 at 4:04 PM, Ronni Elken Lindsgaard

As long as it works, is usable and doesn't require too much work from
me, you have my blessing! :-)
And I will be happy to review any design considerations or prototype
you may make.

Right, so I went straight from the naïve and unsafe solution to a
theoretically perfect, yet unpractical one.

Your idea could work, however I foresee the possibility of a minor
programming mistake that introduces a major security issue. Instead I
propose we change the API from:

* a function that takes [seed, domain, password] and returns a 16
character string (currently used as the password)

to

* a function of same input that returns a block-generator which is a
new function that given () returns a new 16 character block, each
equally unpredictable and safe give away. The first block matches the
one returned in the old API and can thereby be used in the common
case. If a password of only digits is required, call the this
generator-function repeatably and filter the result until the password
i sufficient.
E.g.:
generator() -> "h6tpsen13wbmpy6v" -> apply filter -> "6136" -> too
short, continue
generator() -> "erqnthvkbo2z5mwr" -> apply filter -> "25" -> concat ->
"613625" -> too short, continue
generator() -> "3765jbimep4z1a72" -> apply filter -> "37654172" ->
concat -> "61362537654172" -> done


This way the safety guarantee stays inside the password generator
where it can be controlled and reviewed.

But you seem to have the idea on how to do the filtering.

I know it's possible because I've seen it done, but I don't know how
difficult it is.


--
Johan Brinch