Hi Florian, Thanks for your input. Greatly appreciate the long response. I will respond point by point here.
> > welcome to the fight against weak passwords! It's always great to have people > joining the security side of the battle, but be assured: it'll be a lot of > tough work getting people to actually use strong passwords throughout. I’m trying to make something that while maybe not of maximal convenience, attempts makes up for what it loses by not requiring trusted third parties or installed software or saved password files (even if encrypted). > I've only had a quick look at secretpass.org <http://secretpass.org/>, so > forgive me if I got anything wrong. Here's my thoughts: > > First up, the general idea of generating different passwords from a strong > master password or seed and some other input is workable, at least when > speaking from a security perspective. Tools like passwordmaker or master > password are using it. Please note, I am not familiar with the specifics of > either, so don't take this as an endorsement to use them without having a > closer look. I will check these tools. Thanks. > > Secondly, the choice of parameters. Right now, you are asking for a secret > phrase, a secret number, a secret [special] character and a version. Other > tools most commonly use a strong, secret passphrase (i.e. your master > password) and a (not strong, not secret) identifier (e.g. "google", for your > Google account's password). I would suggest for you to adopt the same idea. > As it stands now, the most easy use case for SecretPass (as I see it) would > be to enter the site name into the secret string field and enter what amounts > to a numeric PIN into the secret number field. This is about as strong as > just using a PIN. Not exactly. My example of google 1234 is an example of how NOT to use it. Maybe if you see our FAQ it will be more clear (or maybe you already did). The idea is to come up with a transform on the name of the service that is easy to remember but hard to guess. You could of course use a strong master password, but if you use the strong master password with the same pin then you are just using the strong master password. Same thing if you use a strong master password plus site name. If somebody figures out your one single password you’re screwed. But you could use this that way if you want to. What I propose as a simple transform easy to remember would be something like “indent the site name 2 chars and camel case all the consonants”, this would mean something like GgL for google or camel case the whole thing backwards eLgOoG or any one of many combinations. But there are many things you could think up. Just be creative. You could also ad numbers to that string. Whatever you want. There are no limits to those fields. They are called “secret string” and “secret number” more to suggest an easy to remember system that would still have some strength to it. At least more than just doing GgL3489! and FcBk3489! (Facebook) as my password directly everywhere. If somebody saw two or three of those they could figure out what’s going on here pretty quick, but with this they could not and the length is much longer as well as more random. This is not particularly strong, and probably never will be for people that know you and can observe you or can compromise your local machine. However I keep seeing all these hacks and plain text dumps of usernames and passwords and I’m thinking how can we protect against that without creating more holes than we’re plugging and still have it be “easy enough". I feel like you are more likely to be randomly targeted by someone far away whom you don’t know than locally targeted. Unless this system becomes very popular it would be unlikely for anyone remote to guess you are using it- the would just move on to the poor sap who uses Password123! - why bother trying to figure out and reverse engineer “%FAD66aCD33DD7eC". I only seek to answer the question: Can I store a strong password in my head for everything I want to use that is unique and virtually immune to data dumps and random tables - and I don’t want to have to install any softwares, or store the passwords locally or trust any third parties. Perhaps I should have stated my thesis more clearly. > > While the approach has some potential, it also has some downsides: firstly, > your generated passwords are not guaranteed to be accepted by whatever site > you are entering it into. Some require special characters to be present, > others forbid them. Some require a minimum length that might exceed others' > maximum length. Finally, some sites will require you to change your password > every now and then. I think you may have addressed this with your "version" > field, but I'm not sure. In any case, I don't think I'd be able to remember > which version I was using in conjunction with what page anyways. If I were to > use SecretPass, this would become a real headache, quite quickly. This is why we provide a 16, 12 and 8 you are intended to take the longest password accepted by your service provider (we could easily add 24, 64, etc.). I have yet to come across something that would not accept a password that has 1 special char, 1 upper, 1 lower and 1 number. All the passwords generated meet that criteria. Yes the version field is about the forced changes. I know that’s annoying but that’s the best compromise I could think of. This occurs rarely on the things that I use. I would only get to version 2 or 3 before it could become really annoying and then I could always just change my transform and/or PIN and go back to 1. Also, at this point this is more about the thought experiment than something I actually think the masses would use… I should make that abundantly clear right now. I do continue to wonder if it could become user-friendly enough for that but that’s a long way off. Clearly better hashes and many other things are needed first. > > As for your implementation of the idea: > > Most importantly, the generated passwords are not secure. You should not use > passwords generated with SecretPass at this stage. > > - You are putting the "secret character" at the start of the password. As > mentioned before, you should get rid of a secret symbol as a separate input > completely. It's a good idea to have your generated passwords contain > symbols, but they should be different symbols for different (generated) > passwords, appearing at unpredictable places in the password, not predictably > at position 1. True and I am sure there is a way to make it appear in different places but how to do it is over my head for. Because remember, we cannot just throw in a random char somewhere at random otherwise the password will not be repeatable. Still, how insecure really is: !31Ab19C2A57F9A2 - it can’t be less secure than “31Ab19C2A57F9A2” and this looks pretty secure to me. If we’re talking about 15 chars plus of randomness we don’t really need that there to make the password strong it’s just to satisfy some requirement. A more improved algorithm would have a hash that includes special chars and the special char would only get tacked on if the randomly generated hash happened not to include one. Would that be secure enough? > - Your passwords only use the character set a-fA-F0-9 and appear to be > shuffled and capitalized hexadecimal outputs from using md5 on the various > inputs. This is almost as bad as using MyPass123 as your password. Instead, > your generated passwords should at least use a-zA-Z0-9 and a set of special > characters [that are tested to be widely compatible]. Is it really as bad as MyPass123? It is definitely true that a publicly useable version would need a better hash algorithm with a-z A-Z 0-9 and special chars if possible and repeatable - but as is isn’t this still better than what 90% of the general public use (or more)? Do you see any problems purely with the strength of the password once SHA-2 (or SHA-3) were implemented? > - Finally, you should not be using md5, at it has a number of known > weaknesses. Use SHA-2 or SHA-3 (Keccak) instead. At this point, MD5 is not > your most pressing issue (the two issues mentioned above are), but it is > nonetheless an issue that must be addressed before SecretPass should do > anything related to passwords. Yes definitely noted. Is SHA-2 easy or possible to implement easily in javascript? If not, how would you recommend it would be done? > > Finally, some points on the implementation itself: > - SecretPass runs in the users' browser. If the machine becomes compromised, > browsers are typically the first piece of software any malware worth its salt > will attack. And in addition to logging keys, modern trojans may log any > input elements and/or take screen captures on key or mouse button press. > Adding a bouncing on-screen keyboard is more likely to include bugs than it > is to improve security. Absolutely true. But what would be the alternative? A binary? What language would you recommend? How would you make it universally portable such that any common user could use it on virtually any device? > - Right now, you are serving the page over HTTP. It's still in development > mode, so this is excusable, but if you are even thinking about handing toy > passwords to the page, it must absolutely always be served over HTTPS. Make > sure to enable HSTS, too. Even then: if a motivated attacker gains access to > your server, he could modify the page to report all input passwords to him. > This affects any application delivered as a web page, by the way, so consider > offering the same functionality as an Add-On/Program/App instead. Absolutely right, it’s just meant as a demo though. I already bought a certificate for HTTPS but have yet to install it. You are supposed to run it locally if actually using it. > - You are using PHP solely to add a cute animation. It's okay to use server > side scripting in general, but there's always some attack surface in any kind > of scripting. Consider moving the animation to JavaScript and serving the > page through a static server instead. That should work just as well (better, > actually). Yes, will remove the PHP version soon. Miscommunication, this wasn’t supposed to be used at all. There is no intention of having PHP in any version that is intended to actually be used to create passwords. > > As a final remark: you did mentioned that SecretPass is in an early stage of > development in your message. At this point, this is not reflected on the page > itself. Please consider adding a warning to people who stumble upon the page, > just to make sure its passwords aren't used at this early stage. This should > improve security (weak passwords aren't used) as well as usability (if you > continue development, your algorithm will likely change. this would break any > previously generated passwords). Yea I’m going to do that right now. Thanks. > > That being said: keep up the good work, consider looking at > passwordmaker/master password for implementation examples with some > experience in a similar scenario and happy holidays :) Will have a look. Thank you. > > Regards, > Florian > > > > On 18 December 2015 at 15:27, Brian Hankey <bhan...@gmail.com > <mailto:bhan...@gmail.com>> wrote: > Hi, > > I am curious to get some feedback from you about a little thought > experiment/hobby project I’ve been working on with some of my coworkers and > have a very early prototype of the concept. > > The question we are trying to answer here is how could we all have ultra > strong passwords i.e. “!3AbDEE9eE45DCea” that are you unique for each and > every website, email, social media, etc. service that we use but without > having to trust any third parties to store them for us protected by single > password (perhaps with 2 factor authentication, hardware key, etc., > admittedly), or to use some kind of local password manager that needs to be > installed on every device you want to use it on with a local encrypted > password file. Lastly, it should be extremely resistant to rainbow tables if > and when one of your passwords is leaked. > > The idea is to have a very compact piece of open source code that can run in > your browser that would help you to generate nearly unbreakable passwords on > the fly every time you need them instead of storing them somehow, or writing > them down where other parties may be able to access them. > > Also, clearly, nothing is unbeatable. Garbage in garbage out. If someone > knows you and your habits they could possibly still break your password- > especially if they know you use this tool and you put very weak things into > it (i.e. google 1234 ! 1 - this will make sense when you look at the demo and > the FAQ). However, the concept is more about: > > 1) Not being the “low hanging fruit” when some major site gets hacked and > usernames and passwords get leaked on the net (i.e. don’t be the guy that is > “u:billsmith32 p:Password123!” on every site he uses). > > 2) Not having trust third parties (i.e.what if I don’t want Apple to store > all my passwords in their cloud?). > > 3) Not requiring cumbersome software that requires installation on your > computer and an encrypted local password file to function (i.e. what if I am > a friend’s house and I need to login somewhere?). > > Known vulnerabilities: Keyloggers, compromised hardware, anyone that can > observe you. (We were thinking of adding a virtual keyboard that bounces > around the screen randomly to help foil key loggers). > > Disclaimer: I am not a programmer, I’m sure the code is buggy (and the bugs > were probably introduced by me and not my coworkers). I am not a > mathematician, and I’m sure there are far better hash functions to use. I’m > also sure that there are better ways to handle the forcing of 1 special char, > 1 upper, 1 lower and 1 number minimum in each password to satisfy the > peskiest “your password is too weak” systems. > > The most important feedback I’m looking for is, do you think the concept is > sound and if so why or why not? If you do think it’s sound then I would like > to know how to improve it? If you think there is potential do you think it is > worth developing further? Assuming it is sound how can we increase user > friendliness and/or security? > > Did somebody else already think of this and do something similar (high > probability I guess) - please tell me so I can give credit where credit is > due. I thought up this idea on a long car trip a year ago and finally got > the courage to con my coworkers into helping me build it to the bare minimum > stage that I could ask some real experts for an opinion. I asked a few > friends already who are pretty well advanced in computer sciences and nobody > called me a stark raving idiot so I thought it would be OK to ask a crypto > mailing list, hope you don’t mind. > > If you find any egregious idiocy in the code it is probably my fault because > I’ve been fooling with it a little bit while being too impatient to get the > experts to fix it. I think it still works as a demo though. I am the only > non-coder of the three that have worked on this so far. The .php version is > only to have a cool looking animation to go with the demo, this is intended > to be run locally. If you want to see the very original version it’s there > too as secretpassv1.html > > Thanks for your time, I look forward to hearing your feedback, good, bad, > awful or otherwise. > > Links - > > live demo http://secretpass.org <http://secretpass.org/> > git: https://github.com/brianci/secretpass > <https://github.com/brianci/secretpass> > > > Thanks. Happy Holidays! > > > _______________________________________________ > cryptography mailing list > cryptography@randombit.net <mailto:cryptography@randombit.net> > http://lists.randombit.net/mailman/listinfo/cryptography > <http://lists.randombit.net/mailman/listinfo/cryptography> > >
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
