So... I'm unlikely to use a website for password generation. Even if everything is done in JS (which from a cursory glance seems to be the case here), that could easily be changed without me knowing it. I think that is a showstopping issue for this app, because any competent administrator will avoid handing out passwords, and nobody wants to read through your sourcecode. You need to seriously rethink the trust issues here.
Other than that, please get someone who is a native English speaker to look over your text. I haven't the foggiest idea what some of it means.
The advisability of using this tool has already been discussed so I'll ignore that aspect and critique the tool as is . . .
- It isn't clear what's the significance of the master and slave pages. I know you have a paragraph of text on the slave page but I think that needs to be the first thing you see. It's a feature which distinguishes you from many other services. Shout about it.
- Your guidelines state that a good password will, "Be seven or fourteen characters long, due to the way in which encryption works. For obvious reasons, fourteen characters are preferable." The default on the form is 8 characters. Try to be internally consistent. My knowledge of encryption is fairly weak, why is 7 or 14 characters best?
- Your privacy statement says, "API page only permitted SSL(https) requests." I seem able to access the page using plain http.
- What is the significance of "You generate password 50 times in the an hour. Because, we check SPAM requests." The way I'm reading it you only generate 50 sets of password each hour and if more than 50 people come to your site you just serve the same set of passwords again. I doubt this is correct but that's the way I read it.
Isn't this the second post lately on nice mini-tools which probably can't easily translate into a startup? There is a difference between just a web app and a business, right?
head may read an awful lot from /dev/urandom before it exits. ;-) And md5sum would limit my password to 0-9a-f whereas with tr(1) I get to choose the character set.
Of course it will, since the password is stored as a string. It may be a random set of 0-9a-f, but a brute force attack will still only need to use those characters. Compare that to a password of the same character length using any possible characters and you can see that it is clearly weaker.
You need to re-read Shannon. The information content of a 128 bit random integer encoded in 32 alphanumeric characters is 128 bits. You cannot feasibly brute-force a 128 bit random number: if you could guess 1000 times per second, it would take you 323708492124180425669115874649 years.
[edit: i got ((((((2^128)/1000)/60)/24)/365)/2) wrong the first time]
I understand that. I'm not disputing the fact that a 128 bit random integer is hard to guess.
The problem, however, is that it is being stored as a string. As such, if you decide to use the 32 character hex representation as a password, you're essentially storing a 32 character string that can only consist of 0-9a-f.
A random 32 character alphanumeric string would correspond to a random integer much larger than 128 bits, and as such, would be much stronger. There's no benefit to go with a weaker password.
You used `md5' in your pipeline, I assumed you meant md5sum(1) as I'm not aware of an md5 command. md5sum gives a 32 character string that's the 128-bit MD5 digest in hex. Therefore it uses only characters 0-9a-f making the password weaker. I'm sorry that you find this criticism "silly" but others reading your pipeline may not, like you, realise its flaw, you got an upvote after all, and use it.
On my Mac, it's just "md5". There's no "flaw" in a 128 bit random password. You use the word "weaker" as if to mean "not unbreakable", though "unbreakable" is what it is.
You're assuming a limit on password length won't apply. In that case, I may as well print it in binary and just have 0 and 1 ASCII characters in my password.
This is mini tools. And This application don't keep password. This is source code. I think write with js this app but maybe firefox add-on or iphone plugin etc usable api can require.
You want to use passwords generated by someone else's server, but first you want to install a Firefox extension, which would give them access to all your existing passwords and cookies?
I'm not the author, but I assume he wants everything client side. If I'm going to have a web site generate a password for me, I certainly don't ever want it touching their server in the process.
I'm not really sure why you'd ever want a website to do this, even client side. There are tools like apg that do exactly this; what does the javascript version offer?
The real security problem relates to social engineering, which this website could quite well be exploiting. Therefore, there is no reason for this. Take your tech skills and move onto something that corresponds to market requirements.
Other than that, please get someone who is a native English speaker to look over your text. I haven't the foggiest idea what some of it means.