Is this text encryption possible to do?

[imgrooot]

Say I have a form field where I input any text(numbers,text,symbols, or mixed). I want to encrypt that input into 16 characters long encryption string that includes at least one uppercase letter, one lowercase letter, one number and one special character? 

 

How can that be done?  Also I want to decrypt it back to original input as well. Can that be one?

 

 

[Jacques1]

Common sense tells you that you cannot have a one-to-one mapping between the gigantic set of all possible strings and the relatively small set of all 16-charater strings. You can either have non-reversible fixed-sized hashes, or you can have reversible dynamic-sized ciphertexts.

 

What are you trying to achieve?

[imgrooot]

Common sense tells you that you cannot have a one-to-one mapping between the gigantic set of all possible strings and the relatively small set of all 16-charater strings. You can either have non-reversible fixed-sized hashes, or you can have reversible dynamic-sized ciphertexts.

 

What are you trying to achieve?

It's what a client requested. For now, he asked if I could do the encryption. Decryption hasn't come up yet. I was just curious.

 

I am assuming it's possible. It should be no different than encrypting  a password but with certain defined parameters no? I suppose one way would be to use a database. Have a column for the original input and the second column for the encrypted text. Then it's simply a matter of retrieving it from the database no?

[requinix]

It's what a client requested.

Then you need to ask why. You want to do the best thing for the client, right? Then that means understanding what they want to do - not how they believe they want it done.

 

The average person does not understand what encryption is. (The numbers aren't much better for programmers, too.) You need to find out what they're really thinking.

[Jacques1]

I don't think you understand what encryption means. Of course you can arbitrarily map strings to other strings, but this has nothing whatsoever to do with encryption. So you obviously mean something very different.

 

Again: What are you, or what is your client trying to achieve? Give us the full picture, then I'm sure we can come up with an idea.

[imgrooot]

I don't think you understand what encryption means. Of course you can arbitrarily map strings to other strings, but this has nothing whatsoever to do with encryption. So you obviously mean something very different.

 

Again: What are you, or what is your client trying to achieve? Give us the full picture, then I'm sure we can come up with an idea.

 

I'm getting the details tomorrow. I'll let you know.

[Ninjakreborn]

I agree. With proper details a lot of things are possible. Someone would be able to help you get a solution once the big picture is provided.

 

Having a database with the original text and the encrypted almost defeats the purpose of encryption in the first place though. It's not very secure for any purpose.

Edited May 26, 2017 by Ninjakreborn

[imgrooot]

Alright so here's the new info.

 

The new encryption will be like a password. User inputs text into a textfield and hits submit. It will return a string of 16 digits with uppercase letter, lowercase letter, a number and a special character. There will be no decryption or saving it in the database. Also the client wants it so that it's not a random string of numbers for the same word. So if the input is "johnsmith", then it will return the same string no matter how many times it has been submitted.

 

Can that be done?

[ginerjm]

Usually - and I am not a security expert - the request you are detailing is for the INPUT value, not the encrypted result.  Whatever the result of your encryption process becomes a password (that's what it is).  I really can't see you even attempting to create your own encryption method when they are so difficult to write and when there are several of them already out there.  If your client is really making this kind of demand, then they should be referred to some good security documents/guidelines to see how out of line they are in this spec.

 

My $.02.

 

One last thing - I notice you did not mention any kind of decryption and that's a good thing.  If there was a decryption method then you have just made your supposedly-secure token much less secure.  One creates a plain-text password (following the above-mentioned guidelines) and it is used to create an encrypted token that gets saved in a secure table usually.  Any authorization attempt then uses the user's password to generate the token using the same method again and compares the stored encrypted value against the just-generated value and if they match the authorization is said to succeed.  The user (and hopefull nobody else) ever sees the encrypted value.

[benanamen]

It sounds like the client just wants a strong password generator which in that case you would not provide any input. There are many online. Show the client and see if this is really what they need. Here are a couple.

 

https://strongpasswordgenerator.com/

 

http://www.strongpasswordgenerator.org/

[ginerjm]

And if Benanamen is correct in that assumption then this whole post is moot.  The topic is merely a business requirement.  Of course it does assume that the application design will utilize state of the art security methods in its authentication and authorization processes down the road.

[Jacques1]

For the third time: What is the client trying to achieve? Forget about the “encryption” stuff. As you've been told multiple times, your client doesn't know what he's talking about, so taking him literally will likely end in a disaster for both of you. You need to figure out what he really wants, not what he says he wants.

 

So users enter what? Their username? And the output is what? Their password? First off, what on earth is the point of that? Secondly, this is a horrible idea. The “password” is now calculated from public input using a public algorithm, which means anybody can do the same calculations to obtain it. The output may look strong to a layman, but this is all fake. In reality, you're effectively using the name as the password.

 

And again, what is the whole point? What is the use case? We can talk about the tech stuff later. First we need to understand what this is even about.

[ginerjm]

I think Benanamen hit it on the head.

[Jacques1]

Except that it's the exact opposite of what the client asked for, and that's dangerous in a business relationship.

[imgrooot]

For the third time: What is the client trying to achieve? Forget about the “encryption” stuff. As you've been told multiple times, your client doesn't know what he's talking about, so taking him literally will likely end in a disaster for both of you. You need to figure out what he really wants, not what he says he wants.

 

So users enter what? Their username? And the output is what? Their password? First off, what on earth is the point of that? Secondly, this is a horrible idea. The “password” is now calculated from public input using a public algorithm, which means anybody can do the same calculations to obtain it. The output may look strong to a layman, but this is all fake. In reality, you're effectively using the name as the password.

 

And again, what is the whole point? What is the use case? We can talk about the tech stuff later. First we need to understand what this is even about.

 

That's all he's trying to achieve. The output is the encrypted password. He basically wants users to have a complex password that they can use for their social media accounts. For eg. User inputs "johnsmith", the output will be "Rju9f3j5?10w3j81". The user can use this output password to register for say Facebook. The user also knows that if they ever forget the output password but knows the original input, he can go back to the site, input "johnsmith" again and receive the exact same output as before. That's his goal.

Edited May 26, 2017 by imgrooot

[imgrooot]

Usually - and I am not a security expert - the request you are detailing is for the INPUT value, not the encrypted result.  Whatever the result of your encryption process becomes a password (that's what it is).  I really can't see you even attempting to create your own encryption method when they are so difficult to write and when there are several of them already out there.  If your client is really making this kind of demand, then they should be referred to some good security documents/guidelines to see how out of line they are in this spec.

 

My $.02.

 

One last thing - I notice you did not mention any kind of decryption and that's a good thing.  If there was a decryption method then you have just made your supposedly-secure token much less secure.  One creates a plain-text password (following the above-mentioned guidelines) and it is used to create an encrypted token that gets saved in a secure table usually.  Any authorization attempt then uses the user's password to generate the token using the same method again and compares the stored encrypted value against the just-generated value and if they match the authorization is said to succeed.  The user (and hopefull nobody else) ever sees the encrypted value.

 

You're second statement could be one of the ways to achieve this goal.

[ginerjm]

I pass on this whole thing.

[Jacques1]

That's his goal.

 

And that's dangerous nonsense which you a) need to realize and b) explain to him in a diplomatic way.

 

Again: Running a public username through a public algorithm with no additional input doesn't magically turn it into a “complex password”. That's mathematically impossible. It cannot be done. Not even Chuck Norris can do it. What you end up with is a bunch of entirely unprotected social media accounts, and nobody today can afford that.

 

Let's imagine this forum generated our passwords by running our username through, say, SHA-256. Can you see the problem with that? Do you see how somebody else might be able to calculate your password? And that's exactly the problem.

 

If you want to generate passwords, you need secret input, be it pure randomness (the optimum), a user-chosen string (acceptable) or a server-side secret (the weakest option). There is no other way.

[imgrooot]

And that's dangerous nonsense which you a) need to realize and b) explain to him in a diplomatic way.

 

Again: Running a public username through a public algorithm with no additional input doesn't magically turn it into a “complex password”. That's mathematically impossible. It cannot be done. Not even Chuck Norris can do it. What you end up with is a bunch of entirely unprotected social media accounts, and nobody today can afford that.

 

Let's imagine this forum generated our passwords by running our username through, say, SHA-256. Can you see the problem with that? Do you see how somebody else might be able to calculate your password? And that's exactly the problem.

 

If you want to generate passwords, you need secret input, be it pure randomness (the optimum), a user-chosen string (acceptable) or a server-side secret (the weakest option). There is no other way.

 

I see your point. I will sure to relay your concerns to the client.

[DionLieb]

why not just use crypt with a random salt

[Jacques1]

Which part of "impossible" did you not understand?

 

I really wonder what you guys think an algorithm like bcrypt does. Magic? Do you think you can just run "123456" through bcrypt and somehow get an unguessable super-password back? How is this supposed to work?

 

bcrypt is entirely deterministic. Anybody who knows the input can simply calculate the output. In this case, the only input is the public username and the semi-public salt, so there is no secret anywhere. It's just math.