How to develop password decryption page

[Notquiteanewbie]

I commonly use this resource to decrypt passwords provided to me by our vendor.
https://decrypted.datapipe.net/

They have a policy not to provide passwords in email. Which I like

I would like to incorporate this same policy but not sure how to get started

They provide a hash such as

-------BEGIN SECURE DATA-------
U2FsdGVkX181BE8rtJhap9xxxxxxxc=
-------END SECURE DATA---------

I input this information along with the customer id and I get the password in the empty area below the form.

Anyone have any ideas on how I would get started. I would also need to make something to create the hash in the above format.

Thanks

 

[bassman]

This should be easy to do if passwords are indeed encrypted. (If passwords are hashed, you're screwed.) You'll need to give more information before you'll get any useful advice.

Which encryption algorithm do you want to use? Which platform would the page be running on? Which platform are the usernames/passwords for?

And why do you want to make it a web page? Are there other people who would be using it?

 

[bashPenguin]

This sounds like the customer number was used as the shared secret for the encryption of the password, and the algorithm used to generate that encrypted string was a symmetric key encryption algorithm like AES or Blowfish (it's not hashed, a cryptographic hash like SHA-256 would screw you over since they're meant to be one-way).

If that's the case, it should be simple to write a form where you have similar fields to put in something like a name/customer number, then a place to put the ciphertext, and then submit to a backend that calls the encryption library/function/whatever of your choice to decrypt the ciphertext by using the name/number as the shared secret.

That's if there is really a need for this to be a webpage.

 

[Notquiteanewbie]

Well currently I manage Active Directory, Exchange and several third party web applications in my company. So I receive many requests to either create or update user accounts or send sensitive information via email. So this got me thinking. I'm not a web developer or anything like that but I can find my way around most things. My company is a Microsoft shop so this would most likely have to be asp or asp.net based I'm assuming. AES sounds good to me.


I'm thinking of having multiple "customer numbers" so I can distinguish between what its for.
Example:
1111 - Active Directory
2222 - Web App1
3333 - Web App2

I want to make it a web page because when I get the request to either create or update an account. I will reply the request with
-------BEGIN SECURE DATA-------
U2FsdGVkX181BE8rtJhap9xxxxxxxc=
-------END SECURE DATA---------
and the user can go to the web form and enter the appropriate "customer number" and encrypted text

 

[JohnleMVP]

How about instead of sending them their password through an encryption system you let them reset their password.

You send them an email with a link to the reset form with a code like reset.do?code=249sadfSmlsSDFmxEIOSxcv9sfBlahBlah

on that page they also enter their email address or username and new password.
When they hit submit it checks the email/username and code match, checks the expiration time and then if it passes changes their password. You can add one of those text images validation systems to protect against bots too.

I had to make a system like this because we MD5 our user passwords so their isn't a easy way to send the user their original password.

 

[bassman]

when I get the request to either create or update an account. I will reply the request with
-------BEGIN SECURE DATA-------
U2FsdGVkX181BE8rtJhap9xxxxxxxc=
-------END SECURE DATA---------
and the user can go to the web form and enter the appropriate "customer number" and encrypted text

You send them an email with a link to the reset form with a code like reset.do?code=249sadfSmlsSDFmxEIOSxcv9sfBlahBlah

Both of these methods are just as insecure as sending the password. If you don't trust email with the password, you shouldn't send this stuff through email either. You're just adding pain and complexity for you and the users with no additional security against someone who knows what they're doing.

Well currently I manage Active Directory, Exchange and several third party web applications in my company. So I receive many requests to either create or update user accounts or send sensitive information via email.

So would these emails go through the internal company email system, on the protected internal company network? Is there a reason to suspect eavesdropping on your network?

 

[Notquiteanewbie]

All the emails communications are within the internal network. I do not suspect eavesdropping but many of the consultants travel up to 100%; so there is a potential risk. Additionally we are a small company that is rapidly expanding. Many of the internal processes need to catch up to the demand. So I'm trying to find ways to begin lock down and provide an efficient and secure process for handling requests.

I do enable users to reset their passwords. These requests are more applicable to new user accounts or sensitive information.

Email is the current communication medium for this. Should I continue this practice or is there a better alternative?