I'm looking for free to use phonetic/pronounceable password generator written in Java (or any JVM language, which can be called from Java).
Ideally the generator would accept criteria for the passwords it creates, eg:
minimum length
minimum number of non-alpha characters
This would be used in a commercial, distributed application, so the license must be compatible with this scenario.
Are there any out there?
Simple algorithm: Create a list of vowels and consonants. After adding a consonant to the password, also add a vowel.
Related
So I've been studying this concept of length extension attacks and there are few things that I noticed during my study about it which are not very bright to me.
1.Research papers are explaining how you can append some type of data to the end and make newly formed data. For example
Desired New Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo&waffle=liege
(notice 2 waffles). My question is if a parser function on the server side can track duplicate attributes, could then the entire length extension attack be nonsense? Because the server would notice duplicate attributes. Is a proper parser that is made to check any duplicates a good solution versus length extension attacks? I'm aware of HMAC approach and other protections, but specifically talking just about parsers here now.
2.Research says that only vulnerable data is H(key|message). They claim that H(message|key) won't work for the attacker because we would have to append a new key (which we obviously don't know). My question is why would we have to append a new key? We don't do it when we are attacking H(key|message). Why can't we rely on the fact that we will pass the verification test (we would create the correct hash) and that if the parser tries to extract the key from it, that it would take the only key in the block we send out and resume from there? Why would we have to send 2 keys? Why doesn't attack against H(message|key) work?
My question is if a parser function on server side can track duplicate attributes, could then the entire length extension attack be a nonsense?
You are talking about a well-written parser. Writing software is hard and writing correct software is very hard.
In that example, you have seen an overwritten attribute. Are you able to say that a good parser must take the last one or the first one? What is the rule? There can be stations that the last one must be taken! That is an attack that can be applied or not. This depends on the station. If you consider that the knowledge of the length extension attack goes back to 1990s, then finding a place applicable to this should amaze someone!. And, it is applied in the wild to Flickr API in 2009, after almost 20 years;
Flickr's API Signature Forgery by Thai Duong and Juliano Rizzo Published on Sep. 28, 2009.
My question is why would we have to append new key? We don't do it when we are attacking H(key|message). Why can't we relay on the fact that we will pass verification test (we would create correct hash) and that if parser tries to extract key from it, that it would take the only key in the block we send out and resume from there. Why would we have to send 2 keys? Why doesnt attack against H(message|key) work?
The attack is a signature forgery. The key is not known to the attacker, but they can still forge new signatures. The new message and signature - extended hash - is sent to the server, then the server takes the key and appends it to the message to execute a canonical verification, that is; if it does the signature is valid.
The parser doesn't extract the key, it already knows the key. The point is that can you make sure that the data is really extended or not. The padding rule is simple, add 1 and fill many zeroes so that the last 64 (128) is the length encoding (very simplified, for example, the final length must be multiple of 512 for SHA256). To see that there is another padding inside you must check every block and then you may claim that there is an extension attack. Yes, you can do this, however, the one of aims of cryptography is to reduce the dependencies, too. If we can create a better signature that eliminates the checking then we suggest to left the others. This enables the software developers to write more secure implementation easily.
Why doesn't attack against H(message|key) work?
Simple, you get the extended message message|extended and send the extended hash
H(message|key|extended) to the server. Then the server takes the message message|extended and appends the key message|extended|key and hashes it H(message|extended|key) and clearly this is not equal to the extended one H(message|key|extended)
Note that the trimmed version of the SHA2 series like SHA-512/256 has resistance to length extension attacks. SHA3 is immune to it by design and that enables a simple KMAC signature scheme. Blake2 is also immune since it is designed with the HAIFA construction.
Our application has a GUI for selecting devices by their MAC address. At this time I have to enter the MAC address in captial letters and with colons.
However, I often have the MAC address in Windows format, which is lower case and with hyphens instead of colons.
The developers keep telling me that it's not possible to apply an uppercase transformation and replace the hyphens by colons. In this project I'm working as QA and I'm neither familiar with SAP Query nor ABAP. But being a developer for C# and Java projects, I really can't believe this.
Is there a way in SAP Query to transform user input from e.g. aa-bb-cc-dd-ee-ff to match the database content AA:BB:CC:DD:EE:FF?
The datatype is C length 17. The program GUI at the time filling the query with the parameters is RSSYSTDB. The Program Dynpro at that time is AQZZ/xxx/yyy where xxx is our partner namespace and yyy corresponds to the transaction. The program GUI and Program DynPro when the result is displayed is SAPLAQRUNT.
If the data element is used exclusively to store MAC addresses (i. e. it's not some generic "device information data" field), the developers could implement a (very concise and easy to implement) conversion routine. That would also help users entering the data. Other than that, I believe the options provided by SAP Query are more than limited...
I am working on a program that creates a "license" file. This file is expected to be binary, containing a name, today's date, a warning date, an expiration date, and a preference of Metric or Imperial units of measurement, and essentially authorizes programs to work until the expiration date is reached, before which the warning date notifies the user that the license will expire. For this functionality to be fully utilized, the dates must not be able to be easily edited so as to prevent people from setting the date to whatever they want and keeping the program.
What I have now writes each field from a String or Integer into whatever the BinaryWriter class deems should be written when I use its "write" method. I have been experimenting with the difference between Big and Little Endian encoding, which is selectable in the form.
[code redacted]
If the entered name has no spaces, the file looks a bit unreadable, but not enough. With Big Endian, most of the Expiration Date is still showing; with Little Endian, the other two dates are mostly visible. However, using spaces in the entered name changes the format of the outputted text quite a bit, making all characters deliminated by a space, and therefore incredibly easy to change. My apologies that I cannot actually show you what the files look like.
Is there a better/more accepted way of storing this data? I would like the license files to work with existing FORTRAN programs, of which read unformatted files in the general structure I've detailed, but reverse-engineering this sounds a bit difficult from what I've read and my employer has offered to rewrite the FORTRAN files to accept this new license creation program if need be.
Create your license structure as text, containing whatever data you need (XML is a convenient format).
Encrypt that using public key encryption (using your private key).
Embed the public key in your app. Decrypt the license file with the public key. Deal with it as you need to.
Easy!
Most license managers I've seen tend to show the license information in plain text, followed by a checksum code that the program checks against, most likely the data hashed with some other random stuff. That provides the benefit of having a human-readable license file while being hard to change.
Be advised that license managers like these will make casual copying difficult, but someone determined to run your program without a license will still be able to crack it with a disassembler and some time.
The most secure way to do that would probably be to encrypt the license file and have the programs using the licenses decrypt the file and display the info in it as necessary.
I have to write a program that will test the strength our our teams password after they have chosen
i need to write a program that will email them and tell them to choose a better password
Is there any lists available, legal of course, that i can use to do this?
You ask for lists so I'm guessing you're fine with the programming but are seeking wordlists/dictionaries to use?
To begin, if you have access to a UNIX/Linux/MacOS box there is a list in /usr/dict/words or /usr/share/dict/words.
A list of common passwords is at http://www.openwall.com/passwords/wordlists/password.lst
Also, check here for a large collection of wordlists - http://www.net-comber.com/wordurls.html
However, a list alone isn't sufficient, you'll want to check for words being reversed, repeated letters/numbers, etc etc.
There is a jQuery plugin that will show you password strength. The link also tells you the algorithm it uses (so you could implement it server-side if you want.)
A slightly different (or simpler?) approach may be to measure the password strength based on the diversity of characters used.
For example award one point if:
Password has at least one lower case letter
Password has at least one upper case letter
Password has at least one number
Password has at least one special symbol
Password is at least 6 characters long
Now you have password strength on the scale of 0 to 5....
Would it not be better to devise a set of guidelines or requirements (must contain letters, numbers, symbols and must be over 8 characters long and not be your username) or similar. This way you can test against those requirements and remove the ability for people to choose weak passwords such as dictionary words and short strings.
Without thinking about it at all I just want to say I should allow every character. It gets hashed in any case, and I don't want to limit people who want to create strong passwords.
However, thinking about it more, there are plenty of characters that I have no idea what effect they'd have on things. Foreign characters, ascii symbols, etc. to name a couple.
I tried to Google but I can't find any definitive standard for what people do. Even most professional organizations don't seem to know. It seems to be a common practice for many sites to disallow special characters altogether, which is just silly and not what I want to do.
Anyway, are there any standard recommendations for length, allowed characters, and so forth?
I'm not sure if it matters, but I'll be using ASP.NET w/ C#
Any printable, non-whitespace ASCII character (between 33 and 126 inclusive) are typically allowed in passwords. Many security professionals (and SO commenters) are advising the use of a passphrase in place of a password, so you'd have to allow spaces. The argument is that due to their length, and since phrases aren't in a dictionary, passphrases are more difficult to crack than passwords. (A passphrase can also be easier to remember, so a legitimate user doesn't have to keep it written down on a sticky-note right on their monitor.)
Some strong password generators use a hash, so I'd put a very high limit on the length (512 or 1024) just to be inclusive. Password generators today often yield strings of 32-128 characters, but who knows what hashes will be used in the next few years.
Non-ASCII characters certainly make things harder when it comes to entering the password on limited devices (mobiles, consoles etc) - but usually not impossible. Arguably if the user wants to do that, you should let them. It's easy enough to do a reasonable and consistent thing - encode in UTF-8 before hashing, for example. You'd only get into difficulties if some input device sent the characters as a composition (e.g. e + acute accent instead of "e acute") - but I suspect that wouldn' t happen in real life. (You could decompose everything yourself, but that would be a lot of trouble to go to for an edge case.)
I'd restrict it to printable characters, however. Putting tabs, form feeds etc in a password really is asking for trouble.
Not an expert, but I hate when characters I choose and not that bizarre are rejected. So, I think I agree with your gut.
Short answer: allow as much as the system backing it can support. Nowadays there's really no excuse not to use full unicode support for text entry, and that includes passwords. I don't think you need to worry about problems with characters as long as they're handled literally (but I'm not a pro in this field--beware of sql injection).
I have a pet peeve against sites that impose restrictions on passwords... any kind of restriction. I like sites that will tell you how strong your password is and recommend you make it stronger, but forcing a user to type at least 8 characters, or to require both letters and numbers, etc. is just plain frustrating.
If you need to have a maximum field size (for example for storing in a database) try to make it large enough for anything that people would type out by hand. There's really no such thing as a too-large password field since there's always the potential to use an automated, generated strong password, but 64 to 128 characters would certainly suffice.
Fundamentally, most of the unicode class of characters should be allowed. Do skip however control characters (e.g. 0-31 besides space), the byte order mark (0xfffe and oxfeff). Further, you want to first canonicalize the representation to get rid of problems caused by differing representations. You might issue warnings though for characters that seem to be too hard to enter, but users will guard against that themselves.
Remember: When you are storing passwords, all passwords should be encrypted with a one-way algorithm like md5 of sha1. Since these algorithms always yield hexadecimal numbers, you don't need to worry about SQL injections or anything like that.
So, as long as you can md5 or sha1 a character, it should be accepted.
If you are talking about preventing SQL-injection type of attacks, it is probably a better idea to make sure your code does what it is supposed to do, rather than relying on restricting the input so the problem becomes easier.
For non-ascii characters, I don't see that as a more difficult problem if your input can be correctly represented as a binary string (and not as text), which is then passed to your hash function or key generator, etc.
Add another vote for "let the user include any and all characters that their interface allows them to enter". I wouldn't even disallow tab or control characters. Your software has the capability to accept arbitrary byte strings and hash them, so accept arbitrary byte strings as passwords. To do otherwise reduces the space which an attacker must search in a brute-force or dictionary attack.
(Of course, even if you do allow everything, 99% of users will still use their pet's name as their password...)
Eventually you may have to print out the clear password in a confirmlation email sent to your users.
PS: Might consider also encoding problems in the email, if it's not standard ascii (eg. Japanese characters), it's possible that a user will not receive the email in the proper format or simply can't read it on another system due to fonts not being installed.
All this weighs in the "printable" ascii characters range.