One secure password for all occasions
I will not argue, the title is provocative. But the continuation is no better ...
Good morning! I'm a complete paranoid. Therefore, I like complex passwords. But to keep them in my head is very troublesome ... You still remember that I am paranoid? And therefore I do not use password managers, except for those that I can put on my servers and can control traffic. But I still physically can not check for bookmarks. Not enough time or experience. Therefore, I am afraid to use someone else's password managers.
Let's imagine that one secure password for all resources is possible. Traditionally, all who are interested in the topic please under the cat.
Once I had an idea - I can keep a passphrase in my head! She will be one for all occasions. But thanks to one-sided functions, I can store the modifiers for it in the form of open and accessible text. In this form:
')
For example:
And keep such a list just in a notebook. When it was necessary to go to a resource, then with a simple Ctrl-F I find the resource and drive the necessary data into the form .
In the field of the passphrase, that same Super-Secret Form, in the field modifier, according to certain rules, the modifier formed from the open data. In general, of course, you can not greatly pervert and score just a modifier, the result will not suffer from this.
Red emphasizes the result of a one-way function, with the last two values ​​replaced by + F. On the one hand, this adds complexity to restoration, on the other hand, it allows access to resources where special symbols and capital letters are needed.
From experience: even if all the characters do not fit in the password entry field on the resource, in any case, with the same actions on the part of the user, the result will be the same, i.e. authorization will be passed.
In general, the approach proposed by me will allow, on the one hand, having one password on all resources, on the other - not to be afraid of password compromise on one of them, since “stolen knowledge” will not lead to the discovery of other resources.
Bottom groups of numbers made more for myself, because so it is more convenient for me to read them from the phone.
It took about 2 hours to write, which indicates a low level of code complexity. Those. Most of the residents of Habr, if they wish, will write this for themselves much faster. At the same time passwords are not stored anywhere and anyone can use the finished form. Well, or, if it’s really interesting what it is, I’ll publish the code (I’m saying right away that it’s "non-bothering," the main idea is still).
Well, for sweetness - the whole exchange at the time of generating the password.
and brief instructions for use:
Thanks for attention. Special thanks for the comments (in advance, I hope they will).
UPD: Following the first reading of comments, I would like to focus on a few points:
UPD2:
I will explicitly indicate the pros and cons of some approaches to working with passwords:
Local ManagerPasswords : Pros - cryptographic strength, minus: possible loss of the device.
Cloud Manager Passwords (on a foreign server) : Pros - cryptographic strength, accessibility. Cons: hacking resource, malicious intent, surrender to regulatory authorities without your knowledge.
Your ResourcePoGeneration Passwords : advantages - control, the ability to deploy at least on the iron (in my case), resistance due to the lack of stored passwords. Minuses (in my case): password generation on the server. And it is rather a half-minus, because the server and the system are completely mine.
Good morning! I'm a complete paranoid. Therefore, I like complex passwords. But to keep them in my head is very troublesome ... You still remember that I am paranoid? And therefore I do not use password managers, except for those that I can put on my servers and can control traffic. But I still physically can not check for bookmarks. Not enough time or experience. Therefore, I am afraid to use someone else's password managers.
Let's imagine that one secure password for all resources is possible. Traditionally, all who are interested in the topic please under the cat.
Once I had an idea - I can keep a passphrase in my head! She will be one for all occasions. But thanks to one-sided functions, I can store the modifiers for it in the form of open and accessible text. In this form:
')
| | | |For example:
habrahabr.ru | acyp | Walhall |And keep such a list just in a notebook. When it was necessary to go to a resource, then with a simple Ctrl-F I find the resource and drive the necessary data into the form .
In the field of the passphrase, that same Super-Secret Form, in the field modifier, according to certain rules, the modifier formed from the open data. In general, of course, you can not greatly pervert and score just a modifier, the result will not suffer from this.
The result of the input SSF and modifier from the example (screenshot)
Red emphasizes the result of a one-way function, with the last two values ​​replaced by + F. On the one hand, this adds complexity to restoration, on the other hand, it allows access to resources where special symbols and capital letters are needed.
From experience: even if all the characters do not fit in the password entry field on the resource, in any case, with the same actions on the part of the user, the result will be the same, i.e. authorization will be passed.
In general, the approach proposed by me will allow, on the one hand, having one password on all resources, on the other - not to be afraid of password compromise on one of them, since “stolen knowledge” will not lead to the discovery of other resources.
Bottom groups of numbers made more for myself, because so it is more convenient for me to read them from the phone.
It took about 2 hours to write, which indicates a low level of code complexity. Those. Most of the residents of Habr, if they wish, will write this for themselves much faster. At the same time passwords are not stored anywhere and anyone can use the finished form. Well, or, if it’s really interesting what it is, I’ll publish the code (I’m saying right away that it’s "non-bothering," the main idea is still).
Well, for sweetness - the whole exchange at the time of generating the password.
Nginx logs
and brief instructions for use:
Instructions for those who are too lazy to write their
1. Get yourself a journal or file that can be kept open to which you have constant access. And keep it all open information. Those. even if on the resource you are forced to change the password (or there is such a need), simply change the modifier
2. Register on the resource by generating a password by reference to the form passer'a. In this case, record all the necessary data (from the modifier field) to the log.
3. If you need to enter this resource, take the data from the log and also use the passer to recover the password. Feature: In places where I am not sure, I do it from the phone, transferring the password to the input form. Then, being in a trusted place, I change the modifier in the log and change the password.
To say quite honestly - I do it easier: The password phrase in my head, in the modifier, the resource to which I want to gain access. And since I changed passwords on a small number of resources and I remember them all, I simply add vN (N is the number of the password change) to the modifier on such resources. And I don't even keep a journal.
2. Register on the resource by generating a password by reference to the form passer'a. In this case, record all the necessary data (from the modifier field) to the log.
3. If you need to enter this resource, take the data from the log and also use the passer to recover the password. Feature: In places where I am not sure, I do it from the phone, transferring the password to the input form. Then, being in a trusted place, I change the modifier in the log and change the password.
To say quite honestly - I do it easier: The password phrase in my head, in the modifier, the resource to which I want to gain access. And since I changed passwords on a small number of resources and I remember them all, I simply add vN (N is the number of the password change) to the modifier on such resources. And I don't even keep a journal.
Thanks for attention. Special thanks for the comments (in advance, I hope they will).
UPD: Following the first reading of comments, I would like to focus on a few points:
- I do not ask to use my application. Moreover, I rather insist that if you have your own fully controlled resource (which is important), write an application yourself that will generate a hash password according to certain rules. I just described the methodology.
- In the imageman's comments, the application was sounded on .js ( chriszarate.imtqy.com/supergenpass ), if I knew about the existence of which, then the article most likely would not exist. The method I proposed is completely illustrated to them. It is unlikely that I will use it at the present time. I do not understand the code yet. But if I find time to study and analyze, I’m happy to use it. From a functional point of view, I liked it more than my own.
UPD2:
I will explicitly indicate the pros and cons of some approaches to working with passwords:
Local ManagerPasswords : Pros - cryptographic strength, minus: possible loss of the device.
Cloud Manager Passwords (on a foreign server) : Pros - cryptographic strength, accessibility. Cons: hacking resource, malicious intent, surrender to regulatory authorities without your knowledge.
Your ResourcePoGeneration Passwords : advantages - control, the ability to deploy at least on the iron (in my case), resistance due to the lack of stored passwords. Minuses (in my case): password generation on the server. And it is rather a half-minus, because the server and the system are completely mine.
Source: https://habr.com/ru/post/335986/
All Articles