Recently I came across this word in a basic authentication article. What it meant by base64 clear text usrname and password on the network?
Thanks
In HTTP Basic authentication, the "password:username" is encoded in Base64. Since it's not encrypted, it's cleartext.
Here is a sample Authorization header,
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
Where dXNlcm5hbWU6cGFzc3dvcmQ= is Base64-encoded "username:password" (literally).
It means encoding the username and password using base 64. The result won't look too much like your username and password but it's pretty easy to reverse the operation to get the plain text.
See here for details on base 64 encoding
http://en.wikipedia.org/wiki/Base64
For example the string password encoded in base 64 is cGFzc3dvcmQ=
This online tool can encode/decode base 64 for you http://www.motobit.com/util/base64-decoder-encoder.asp
Base 64 encoding (Wikipedia article) turns "This is my password." into:
VGhpcyBpcyBteSBwYXNzd29yZC4=
It's easily recognizable and entirely reversible, so its entirely insecure.
This means that the username and password is not encrypted (ie clear text) The text is just base 64 encoded for transporting and can easily be decoded.
Base64 is a way to deliver binary data through a connection (or file) that limits what characters are allowed to be included. For example, e-mail attachments are encoded in base64 because the e-mail protocol only allows for plain text in an e-mail message.
See the wikipedia page for more http://en.wikipedia.org/wiki/Base64
Related
There are algorithms for encoder which are impossible to hack and these encoder are used in applications like HTTPS for sending secure message over network. Base64 is very simple and can be easily decoded, I think encoding with base64 is as simple as sending raw data.
Then why base64 encoding is used? For example Elasticsearch automatically generates id which is encoded with base64
Base64 is not used for security at all, it is used as a means of escaping special characters.
see:
https://security.stackexchange.com/questions/29916/why-does-http-basic-authentication-encode-the-username-and-password-with-base64
What is the purpose of base 64 encoding and why it used in HTTP Basic Authentication?
Why Base64 in Basic Authentication
This actually breaks down into a lot of separate questions to understand the overall process.
From what I understand a JWT is just three JSON objects encoded into base64 separately from one another. Then the Base64 strings are separated by periods. This is done purely for "shorter message" purposes?
These include a header, "payload," and signature. The header and payload are 100% available to read by anyone who intercepts them. They are just base64 strings that can be decoded into JSON and read.
Then the MAGIC: The server receives the SIGNATURE, which cannot be decoded. The signature is actually a hash of the header, payload, AND a secret key. So the server takes the header, the payload, and ITS OWN secret key, and makes a hash. If this hash MATCHES the signature that came with the message, the message is trusted. If the signatures DO NOT match, the message is invalid.
My problem with all this? Where are the two separate keys here? It seems that the key used to encrypt the message and the key used to decrypt the message are the same. This is the root of my question - if you answer nothing else, please help with this.
Other than that, I wonder if I understand the process correctly? Also, where is the standard "agreeing on a public key" and then trading "mixtures" of public/private keys occurring here? All I see is the same key being used to encode/decode. But when did the agreement happen? Viewing this in context of .NET and Auth0 btw, but overall q.
Random stuff I watched/read/used if anyone is interested on seeing this q later:
Summary of JWTs: https://scotch.io/tutorials/the-anatomy-of-a-json-web-token
Public-key/Assymetric Cryptography: https://youtu.be/3QnD2c4Xovk
Hashing: http://www.webopedia.com/TERM/H/hashing.html
Base64: http://en.wikipedia.org/wiki/Base64
Firstly, JSON Object Signing and Encryption standards (JOSE) use base64url encoding and not straight base64 encoding, which differs slightly.
JWT header and payload are JSON objects but the signature is not, that's a base64url encoded binary blob
the whole JWT is available to anyone who intercepts it, all 3 parts of it
you're describing a symmetric key algorithm, where sender and receiver use the same shared key; that is just one option for JWTS, another option is to use public/private key pairs for signing/validation/encryption/decryption
As with all crypto, agreement on keys needs to happen out of band.
Then the MAGIC: The server receives the SIGNATURE, which cannot be decoded. The signature is actually a hash of the header, payload, AND
a secret key. So the server takes the header, the payload, and ITS OWN
secret key, and makes a hash. If this hash MATCHES the signature that
came with the message, the message is trusted. If the signatures DO
NOT match, the message is invalid.
There is no magic here. JWT supports four well-known signature and MAC (message authentication code) constructions: HMAC (a symmetric algorithm), and ECDSA, RSASSA-PKCS-v1.5 and RSASSA-PSS (public-key algorithms). Each of these may be used with the SHA-256, SHA-384 or SHA-512 cryptographic digest. See also the table of Cryptographic Algorithms for Digitial Signatures and MACs from RFC 7518 - JSON Web Algorithms (JWA).
My problem with all this? Where are the two separate keys here? It
seems that the key used to encrypt the message and the key used to
decrypt the message are the same. This is the root of my question - if
you answer nothing else, please help with this.
There are not necessarily two separate keys - if a public key algorithms is used, the signature will be created using the server's private key, and verified using the corresponding public key. But if an HMAC algorithm is used, a shared secret key must be used for both signing and verification.
I'm taking a user inputted NSString, converting it to NSData with NSUTF8StringEncoding. I'm then using CCCrypt to encrypt that data using a random salt and IV and a user inputted password.
My question is, how do I convert this encrypted NSData into a format that could be decrypted by a plain text AES decryptor such as http://www.everpassword.com/aes-encryptor?
Furthermore, does CCCrypt automatically add the salt & rounds to the encrypted data? Or do I need to manually add them in some way before the data can be decrypted with access only to the secret password?
Any help on this would be greatly appreciated.
The website you posted uses Gibberish-aes and giberish aes uses an openssl compatible format. CCCrypt will not give you that format by itself, however you don't have to do it yourself. RNCryptor happens to have an OpenSSL format mode RNOpenSSLEncryptor.
How to decrypt a string with unknown encryption algorithm?
There is a string:
5aaC5p6c5L2g5a+55oiR5Lus5Zyo5YGa55qE5LqL5oOF5pyJ5YW06Laj77yM5bm25LiU5a+5cmFpbHMv5YmN56uv5byA5Y+R5pyJ6Ieq5L+h77yM5qyi6L+O5Y+R6YCB6YKu5Lu25YiwZ2hvc3RtNTVAZ2l0Y2FmZS5jb23pooTnuqbkuqTmtYHml7bpl7TvvIznoa7lrprkuYvlkI7lj6/ku6Xnm7TmjqXmnaXliLDmiJHku6znmoTlt6XkvZzlrqTlj4Lop4LkuqTmtYHvvIzosKLosKIK
I don't know the encryption algorithm. How to decrypt it?
To analyze and solve this problem, what should I learn?
It's not an encryption algorithm, it's base64. You can tell because of the +s.
http://www.opinionatedgeek.com/dotnet/tools/base64decode/
Try running it through this page, it'll turn into this:
如果你对我们在做的事情有兴趣，并且对rails/前端开发有自信，欢迎发送邮件到ghostm55#gitcafe.com预约交流时间，确定之后可以直接来到我们的工作室参观交流，谢谢
NOTE: If it was actually encrypted and you actually had no clue what it was encrypted with, you would be screwed, because any good encryption algorithm turns the output into meaningless gibberish, unusable without the key. Base64 has no key, you can just reverse it the same way every time.
This string appears to be a Base64 encoded string.
The decoded value is: 如果你对我们在做的事情有兴趣，并且对rails/前端开发有自信，欢迎发送邮件到ghostm55#gitcafe.com预约交流时间，确定之后可以直接来到我们的工作室参观交流，谢谢
Well, the string is likely Base64 encoded. If you decode it, you should get an effectively random piece of binary data if its encrypted (EDIT: As others have shown, it isn't encrypted, but the following would still apply if it were)
By checking the length, you can determine the block-size of the cipher. If its not an even block size, it likely could be a stream cipher (or a block cipher operated in stream mode).
However, any more information will need to be gleamed from other sources - as the point of good encryption is to make the data truly opaque.
Its Base 64 encryption.The above code is translated as:
如果你对我们在做的事情有兴趣，并且对rails/前端开发有自信，欢迎发送邮件到ghostm55#gitcafe.com预约交流时间，确定之后可以直接来到我们的工作室参观交流，谢谢
"If you are doing things we are interested in, and on the rails / front-end developers are confident, please send e-mail to communicate ghostm55#gitcafe.com appointment time, after determining the direct exchange of visits to our studio, thank you"
I am trying to create a ticket for Remote Assistance. Part of that requires creating a PassStub parameter. As of the documentation:
http://msdn.microsoft.com/en-us/library/cc240115(PROT.10).aspx
PassStub: The encrypted novice computer's password string. When the Remote
Assistance Connection String is sent as a file over e-mail, to provide additional security, a
password is used.<16>
In part 16 they detail how to create as PassStub.
In Windows XP and Windows Server 2003, when a password is used, it is encrypted using
PROV_RSA_FULL predefined Cryptographic provider with MD5 hashing and CALG_RC4, the RC4
stream encryption algorithm.
As PassStub looks like this in the file:
PassStub="LK#6Lh*gCmNDpj"
If you want to generate one yourself run msra.exe in Vista or run the Remote Assistance tool in WinXP.
The documentation says this stub is the result of the function CryptEncrypt with the key derived from the password and encrypted with the session id (Those are also in the ticket file).
The problem is that CryptEncrypt produces a binary output way larger than the 15 byte PassStub. Also the PassStub isn't encoding in any way I've seen before.
Some interesting things about the PassStub encoding. After doing statistical analysis the 3rd char is always a one of: !#$&()+-=#^. Only symbols seen everywhere are: *_ . Otherwise the valid characters are 0-9 a-z A-Z. There are a total of 75 valid characters and they are always 15 bytes.
Running msra.exe with the same password always generates a different PassStub, indicating that it is not a direct hash but includes the rasessionid as they say.
Another idea I've had is that it is not the direct result of CryptEncrypt, but a result of the rasessionid in the MD5 hash. In MS-RA (http://msdn.microsoft.com/en-us/library/cc240013(PROT.10).aspx). The "PassStub Novice" is simply hex encoded, and looks to be the right length. The problem is I have no idea how to go from any hash to way the PassStub looks like.
I am curious, have you already:
considered using ISAFEncrypt::EncryptString(bstrEncryptionkey, bstrInputString) as a higher-level alternative to doing all the dirty work directly with CryptEncrypt? (the tlb is in hlpsvc.exe)
looked inside c:\WINDOWS\pchealth\helpctr\Vendors\CN=Microsoft Corporation,L=Redmond,S=Washington,C=US\Remote Assistance\Escalation\Email\rcscreen9.htm (WinXP) to see what is going on when you pick the Save invitation as a file (Advanced) option and provide a password? (feel free to add alert() calls inside OnSave())