How to decrypt password which is of type pass Password (1 Way Encrypted)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-13-2017 02:39 AM
How to decrypt password which is of type pass Password (1 Way Encrypted) in user table
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-13-2017 03:17 AM
1-Way encryption in Servicenow is actually not encryption, but Hashing! And the answer is, NO. You can't decrypt a HASH message to its plain text, means reversing is not possible for Hashing. For example,
SHA(plainText) -> hashText
then there is no mechanism like inVerseSHA which can do the following,
inVerseSHA(hashText) -> plainText
All you can do is generate the hashText again in another entity by the same procedure SHA(plainText) -> hashText and check the integrity of the text message (matching the two hashText), that is the main purpose of hashing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-13-2017 04:39 AM
You can't - it's irreversible. You can possibly create hash tables and try to do a match, but this will involve a large amount of work.
Can I ask what the use case is for this? It's unusual for someone to request encrypted private information be decrypted by anyone other than the information's owner.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-14-2017 01:00 AM
Hi David,
We are doing third party tool integration with SNOW, now we got user info but password field is missing, to store them manually we want to decrypt.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-14-2017 02:09 AM
Okay.. bit confused here - if the password field is missing, then you have nothing to decrypt...?
Either way, it sounds like your problem isn't about decrypting passwords, but ensuring authorised users are able to login. If that's the case, trying to decrypt the password so that you can populate their password field is the wrong approach: not only is it exposing private information to users, it's possibly violating security policies in some organisations/countries, and it's also degrading the level of trust in end users. How would your users feel if you told them "we cracked your password so that we could add it to our database"....?
The usual way forwards is to set a one-time random password for the account then communicate this password to the account holder with instructions on how to change it once they login. Not only will their known (random) password now be invalid, they have assurance that the new password is still private to them only.
I suspect this is another "tell me how to navigate this journey" rather than "help me get to this end destination" problems, but YMMV.