1 |
On Wed, Feb 6, 2019 at 5:18 AM Neil Bothwick <neil@××××××××××.uk> wrote: |
2 |
> |
3 |
> On Wed, 6 Feb 2019 04:28:49 +0800, Mark David Dumlao wrote: |
4 |
> |
5 |
> > My own solution is actually very simple. I have a "secret algorithm" |
6 |
> > that incorporates several secrets with a predictable way to generate a |
7 |
> > site-specific secret. The end result is a 100% predictable way to |
8 |
> > generate unique passwords for every site that are cryptographically |
9 |
> > secure from each other (you cannot derive |
10 |
> > one from the other) which can be generated by any device using the |
11 |
> > appropriate tools. |
12 |
> |
13 |
> The was a tool in portage this did this. I tried it but it did not work |
14 |
> in the real world because you couldn't set a rule for generated passwords |
15 |
> that matched the requirements of all sites, for example some require a |
16 |
> non-alphanumeric character while other sites only allow alphanumerics. |
17 |
> |
18 |
> I can remember what the tools was called, although I'm pretty sure it |
19 |
> was written in Python. I'd be interested to know how you get around the |
20 |
> conflicting restrictions as this seems a good way to do things. |
21 |
> |
22 |
|
23 |
Well the original idea is to reduce dependency on specific tools, such |
24 |
that the algorithm is the secret, and the passwords are just |
25 |
byproducts of the secret. You will still need tools to do any hashing, |
26 |
but those are generic tools you can acquire anywhere. |
27 |
|
28 |
So for example, the "password123" equivalent secret algorithm might be: |
29 |
1) global pepper: "password" |
30 |
3) site-specific pepper: pepper plus number = vowels in domain name |
31 |
2) site-specific ID: pepper dot domain name dot username |
32 |
4) hashing algorithm: md5sum + base64, take first 8 |
33 |
|
34 |
Example application: madumlao@×××××.com |
35 |
1) site-specific pepper: pepper3 (3 vowels in domain name: google) |
36 |
2) site-specific ID: pepper3.google.madumlao |
37 |
3) site-specific hash: (2) -> md5sum -> base64 -> first8 -> NGI3MTQz |
38 |
4) combined with global pepper: password.NGI3MTQz |
39 |
5) hashed with global pepper: (4) -> md5sum -> base64 -> first8 -> MWJjZjg2 |
40 |
password: MWJjZjg2 |
41 |
|
42 |
Example application: madumlao@×××××.com |
43 |
1) site-specific pepper: pepper3 (3 vowels in domain name: yahoo) |
44 |
2) site-specific ID: pepper3.yahoo.madumlao |
45 |
3) site-specific hash: (2) -> md5sum -> base64 -> first8 -> ZDQzZGM5 |
46 |
4) combined with global pepper: password.ZDQzZGM5 |
47 |
5) hashed with global pepper: (4) -> md5sum -> base64 -> first8 -> ZjUwMTI2 |
48 |
password: ZjUwMTI2 |
49 |
|
50 |
The procedure takes up a little more headspace than 1 password, but |
51 |
definitely less headspace than a dozen cryptographically secure |
52 |
passwords. You can change the hashing algorithm, peppering rule, ID |
53 |
rule, number of characters, etc to your tastes. You can add iteration |
54 |
rules for the nth password change anywhere in the procedure, and add |
55 |
constraint rules for sites that have certain password limitations (the |
56 |
caveat is that you have to remember which sites have password changes |
57 |
and constraints). For me really all that matters is that the building |
58 |
blocks are widely available and the end result incorporates data loss |
59 |
that makes it impossible to recover the original secrets. |
60 |
|
61 |
"Obviously" do not use this algorithm as-is. The algorithm, not the |
62 |
password, is the secret, so using this algorithm as is is the |
63 |
equivalent of using any example of a crypto secure password (correct |
64 |
horse battery stapler) as a password. |
65 |
-- |
66 |
This email is: [ ] actionable [x] fyi [ ] social |
67 |
Response needed: [ ] yes [x] up to you [ ] no |
68 |
Time-sensitive: [ ] immediate [ ] soon [x] none |