I am currently posting an encrypted string to a ColdFusion web server where I am trying to decrypt the value using the same password used in encrypting it in LiveCode.
It isn't working at all, where ColdFusion keeps on telling me that the data to be decrypted is not correct.
When I answer the data posted it is exactly the same as what the coldfusion server receives it as.
In Coldfusion I use:
<cfset decrypted=decrypt(#dataposted#, #password#,'AES')>
In Livecode I use:
encrypt gFirstName using "aes256" with password tPassword
(Both passwords are the same in each script).
Any ideas?
Coldfusion decrypt need a key, not a password, so the correct livecode code is:
encrypt gFirstName using "aes256" with key tPassword
Related
In my Django web-app, I would like the user to authenticate itself with an encrypted email address that would simply be the username. Due to the existing GDPR regulations in my country, I have to encrypt e-mail addresses and by doing it with the help of Python Cryptography and Fernet functions, each string is different after encryption, even if two strings are encrypted with one and the same key. Is it possible to authenticate the user without errors in such a situation? If this is possible, where can I read a little more about it?
EDIT: Maybe I incorrectly specified: Django uses username and password for authentication, if the encrypted email is username, when logging in, the user will enter the email when logging in, i.e. harry#example.com. The database keeps an encrypted version of this email, so when using authenticate(request, username, password), it will look for a user with the username harry#example.com, not the encrypted version. If at this point I would like to decrypt the user's e-mail from the database and compare it with the e-mail that the user entered when logging in, app would probably has to decrypt all e-mails in the database, and then check if and which one is harry#example.com and here, in my opinion, it becomes quite problematic, because I have the impression that it is a not good solution in terms of time and server load. Is there any other way that I will be able to compare the e-mail entered when logging in and the encrypted e-mail in the database?
Here is a good lesson on how to use python cryptography https://www.geeksforgeeks.org/how-to-encrypt-and-decrypt-strings-in-python/
As for GDPR, the user can enter their email but you should encrypt it on the store, then decrypt it when you want to use it. Make sure that your secret is hidden. If someone gets access to your database and your secret, the encryption is as good as if it's not there.
You should not be comparing the encrypted strings, you should decrypt the email and compare it to the email that is currently entered. Comparing hashes should only be done with hashing, not encryption. If you don't want to have access to the user's email, you should consider hashing instead of encrypting.
There's a good read here How do I encrypt and decrypt a string in python?. To know the how-to around what you need. Plus, you described the solution quite well, so take a look at the following packages from the Django community which achieve what you are looking for:
https://github.com/orcasgit/django-fernet-fields/
https://github.com/orcasgit/django-fernet-fields/blob/master/fernet_fields/fields.py#L117 It includes an Encrypted email field
https://github.com/patowc/django-encrypted-field
Good day,
I am very new to database/application/connection security and would like some help on a project.
Let me explain my environment :
I have a username A and password A being saved in a database (A) on a local machine.
Password A is being stored using a type of hashing algorithm with salt A.
I am sending the credentails (Username A and Password A) via a HTTPS SOAP Call to a webservice sitting remotely.
Apon receiving Username A and Password A the webservice validates those credentials to a table sitting in database (B) local to the webservice location.
My Problem : If someone gets access to database A and extracts the hashed passwords they can use a SOAP request to connect to the webservice. This means that my security is null and VOID.
I have to possible solutions :
SOLUTION 1 : Before sending password A to the webservice, I decrypt it and send it over plaintext via the Secured HTTPS connection. The webservice will then encrypt it again when validating agains the hash stored in database B.
SOLUTION 2 : Before sending password A to the webservice, I do a second encryption to that existing hash. When arriving at the webservice, it is decrypted to expose the hash which is .then validated against database B.
My Question : Is any of the 2 solutions above, best practice. If not, what would be a best practive solution for this scenario.
Kind Regards
Just a few notes
there is difference between hash (one way, non-reversible) and encryption (reversible). You cannot decrypt hashed value.
I will assume you are working with service credentials, not user's identity credentials
Here I will assume you are talking bout
SOLUTION 2 : Before sending password A to the webservice, I do a second encryption to that existing hash. When arriving at the webservice, it is decrypted to expose the hash which is .then validated against database B.
The hash effectively becomes a password, it doesn't add any security to the solution
SOLUTION 1 : Before sending password A to the webservice, I decrypt it and send it over plaintext via the Secured HTTPS connection.
There are several standards to authenticate the SOAP WS client, using simple credentials it's WS-UsernameToken. Effectively the client sends its username and password plain, relying HTTPS to handle the channel security.
My Problem : If someone gets access to database A and extracts the hashed passwords they can use a SOAP request to connect to the webservice
One the password is hashed, you won't be able to decrypt it, but as well you cannot use the hashed value as a password. Otherwise you will get the "solution 2" and you are using the hash as a password.
Indeed, this is generally a problem. You may search other questions, how to store service credentials locally. The whole problem is - you need to store the credentials. In my experience the best you can do at least make retrieval somewhat harder, e.g. encrypt the service passwords so they are not stored plain in the database or config files. At the end the client application needs the encryption key somewhere to decrypt the credentials. The key needs to be protected as well.
If you are dealing with user credentials (user identities), do not store the user passwords at all at the client side, there are other ways how to authorize user actions (access token, jwt token, ..)
If you are using xml based SOAP you can use WS-Security to encrypt the password and sign your request data so that the integrity and security of your password is ensured, and the send the data over https.
For storing passwords you should use irreversible crypto hash like sha2, at server you will decrypt the password, create sha2 hash and match it against the one from database
I have an encrypted password "$H$9f1gABgoDXyr1P0AT7Wz8qAB3.QNGF" and I want to decrypt it but I really can't understand which encryption they used for this password. I took this password from my website forum mysql database. Can anyone tell me how to decrypt this and also tell me the name of this encryption? I've been searching for this since 1 hour and found nothing useful.
You can't, by design.
The "encrypted password" you've posted is one-way encrypted using a trapdoor function: the only way to get the original password is to enter the original password and see it produce the same output.
If you could "decrypt" this password, there'd be nothing stopping an attacker, after breaking into your password database, from doing the same.
I am working on a User Authentication mechanism for ColdFusion Web Service called from mobile apps. The app developer wants to encrypt the User Id and password using AES. ColdFusion requires a key in order for the string to be decrypted, but, how can I know the key, if it's not generated on my server?
Yup, #Henry has it right. You will need the key (stored securely of course).
I'm writing a web app in Django that is interfacing with the Read it Later List API (http://readitlaterlist.com/api/docs/). However, all of the API calls require sending the username and password with each request. In order to do this, it seems that I need to store the user's password in plain text in my database. Am I missing something or is that the only approach possible in this case? Is there some way to store an encrypted password in my database, but yet be able to send a decrypted version of it when making the API call? If not, then are there any best practices that I should be following to safe-guard the user's password?
I'm pretty sure that this can't be the only service requiring sending password in plain-text. I'm interested in knowing how developers deal with these sort of services in general. I'm new to web development, so any help or pointers is appreciated.
do your users have to log into your website to use it? if you also are making use of a password authentication scheme, you could piggy back on top of that. Use the login password for your site as a cipherkey in a symmetric key cipher to encrypt the api password. then you need only store a hash of the users password (to your own site) and an encrypted password for the remote api.
Never save password in plain text. You can encrypt and decrypt the password but the problem is that the key you use to do the encryption and decryption will generally be accessible to anyone who has gained access to your server so it's not secure.
An alternative is to ask them to enter their password and save it in an encrypted cookie, or session variable or something else that will expire when they have logged out of your app. This has the drawback of them having to enter their password every time they user your app.