I came across this old post Password to string with AES 256 (https://forum.winbatch.com/index.php?topic=1973.0) and was curious if it is indeed using AES 256. My assumption is that it is but I wanted to verify. I have been using the old RC4 extender for quite some time to store encrypted passwords and I have been asked to see if I can use AES 256. Any insight would be appreciated.
THANKS!
You will have to ask MSFT. It is their .Net classes used in the example. The documentation for the current Framework version of the class can be found here:
https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.aesmanaged?view=netframework-4.8.1
Thanks Tony!
I tweaked the code from the original post to use Aes.Create() as I read last night that AesManaged is obsolete.
I'll completely admit I don't fully understand everything in the code but when I query for KeySize it does return 256. So I guess I am good.
objAes = ObjectClrNew('System.Security.Cryptography.Aes')
objAesCreate = objAes.Create()
;; Set key and initialization vector.
checkKeySize = objAesCreate.KeySize
As long as you are working with CLR. might consider
System.Security.Cryptography.Rfc2898DeriveBytes to create key(s)
Security.Cryptography.AesGcm as main Aes Instance
[EDIT]:
Probably stepped into this thread w/out asking basic question. Are you looking for AES to basically encrypt User/pw pairs (in which case using credentials and secure-string should suffice) or encrypting text with AES and key?
I'm basically looking to encrypt text with AES to store it in a database so it can, at a later time, be retrieved, decrypted and read.
Quote from: chrislegarth on December 12, 2024, 02:02:26 PMI'm basically looking to encrypt text with AES to store it in a database so it can, at a later time, be retrieved, decrypted and read.
This may be off-topic, but I attached a quickie script based on my StdOut function. In my last year at Charter I used SecureString in multiple PS exes I compiled for use with accessing secure servers via API. The script will encrypt and display text as Base64 [run it more than once and each time the output is different]. I suggested an option to persist to a file, or to a db table if needed. This assumes the data would be decrypted by the same script that encrypted it. If you were to persist to a file/table that would be exported for other uses, then an extra 'key' would be needed, and I am sure you already know this. and that would involve System.Security.Cryptography. I could easily set up a PS script to perform encrypt/decrypt with keys in PS as you could get the code with CoPilot. I am sure the .NET could be coded with WB CLR, but would involve Tony skills. Anyway, the script is attached
Quote from: chrislegarth on December 12, 2024, 02:02:26 PMI'm basically looking to encrypt text with AES to store it in a database so it can, at a later time, be retrieved, decrypted and read.
Generally, passwords are stored using asymmetrical encryption and a salt. Using one-way encryption and salted passwords adds additional layers of protection to your database.
https://en.wikipedia.org/wiki/Salt_%28cryptography%29
Quote from: td on December 13, 2024, 02:18:27 PMQuote from: chrislegarth on December 12, 2024, 02:02:26 PMI'm basically looking to encrypt text with AES to store it in a database so it can, at a later time, be retrieved, decrypted and read.
Generally, passwords are stored using asymmetrical encryption and a salt. Using one-way encryption and salted passwords adds additional layers of protection to your database.
https://en.wikipedia.org/wiki/Salt_%28cryptography%29
Nice read, and sorry Wiki want $2.75 from readers to stay alive. Still going to be up to the OP to more clearly define if the goal is to persist encrypted password, or other sources, i.e. email messages etc.. While using security to restrict access to a database, url, sharepoint.... storing encrypted data in a database seems complicated as it would be easier to save as .bin files and mark as hidden after persisting... then unhide/unencrypt when needed - easier with file functions vs. db (although SQLite in WB would be an option).
just .02
Wikipedia has always asked for donations, so it is nothing new. As a long-time contributor and frequent user, I have no problem with that aspect. It is not the definitive source for much of anything, but it is a good starting point for further research.
The OP requested information about password encryption, and a salt + asymmetrical encryption in a database for fast lookup is one recommended approach. The idea is that servers regularly get compromised but a salt + asymmetrical encryption makes cracking passwords computationally more expensive. Of course, if the OP is storing things other than passwords, asymmetrical encryption may not be appropriate.
Quote from: td on December 14, 2024, 08:59:23 AMWikipedia has always asked for donations, so it is nothing new.
Understood and I contributed after using Wiki for help calculating Easter and listing all the popes in a db table. But when I tried the link you posted, it was a little more blatant. Pink pop-up screens, seemed timed so they popped every 3 minutes.... and I rank them below my St. Jude and ASPCA donations.
And I think we are on the same page in terms of clarifying the request:
- Encrypt passwords for access to a db.... or...
- Encrypt text/passwords in a db table for later use
I don't see any pink pop-up screens when I follow the link so I don't know what to tell you. It could be my browser setup as it blocks almost all ads and popups without the site noticing.
It was pink last time, blue this time... not important but I use Duck Duck Go which I like for eliminating trackers but the pop-up is outside their scope.
Back to this thread... waiting on OP.
@spl Do you use the (Raymond Hill / gorhill) uBlock Origin (https://chromewebstore.google.com/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm?hl=ru))%2C) browser extension? Like Tampermonkey, it's a must-have. That is probably what blocks those pop-ups for me...