I've read on this post that Nginx does not support multiple Authorization headers.
I was wondering if how I would check in the http request if an
authorization header is present.
basically I am adding a basic auth to my webpage since its not ready for production yet. My site is a single page application and I have successfully added authentication in the index page, but my site has also log in feature. When I log in it keeps asking for the authentication again. Im new to nginx and I am not quite sure how to get around with this
location / {
root /path/to/my/app/root/folder;
index index.html index.php;
#I want to only executed these lines only on the index page and login page
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
}
You can use curl to see the headers:
$ curl -v -u your_user_name "http://......."
Look for the > Authorization: Basic ... line which contains a Base64 encoding of user:pass.
You can decode the string using:
printf auth_string | base64 --decode
More details here.
Also, make sure /etc/nginx/.htpasswd has the right permissions for nginx to be able to read it and that it contains your user/pass credentials in a format recognized by nginx (info here):
1. Plain text:
# comment
name1:password1
name2:password2:comment
name3:password3
2. Encrypted/hashed:
encrypted with the crypt() function; can be generated using the “htpasswd” utility from the Apache HTTP Server distribution or the
“openssl passwd” command;
hashed with the Apache variant of the MD5-based password algorithm (apr1); can be generated with the same tools;
specified by the “{scheme}data” syntax (1.0.3+) as described in RFC 2307; currently implemented schemes include PLAIN (an
example one, should not be used), SHA (1.3.13) (plain SHA-1
hashing, should not be used) and SSHA (salted SHA-1 hashing, used
by some software packages, notably OpenLDAP and Dovecot).
$ htpasswd
Usage:
htpasswd [-cimBdpsDv] [-C cost] passwordfile username
htpasswd -b[cmBdpsDv] [-C cost] passwordfile username password
htpasswd -n[imBdps] [-C cost] username
htpasswd -nb[mBdps] [-C cost] username password
-c Create a new file.
-n Don't update file; display results on stdout.
-b Use the password from the command line rather than prompting for it.
-i Read password from stdin without verification (for script usage).
-m Force MD5 encryption of the password (default).
-B Force bcrypt encryption of the password (very secure).
-C Set the computing time used for the bcrypt algorithm
(higher is more secure but slower, default: 5, valid: 4 to 31).
-d Force CRYPT encryption of the password (8 chars max, insecure).
-s Force SHA encryption of the password (insecure).
-p Do not encrypt the password (plaintext, insecure).
-D Delete the specified user.
-v Verify password for the specified user.
On other systems than Windows and NetWare the '-p' flag will probably not work.
The SHA algorithm does not use a salt and is less secure than the MD5 algorithm.
Related
I have a job that runs periodically and signs/encrypts a file like so:
$ gpg --homedir /path/to/.gnupg -r key1#mydomain.com -r key2#mydomain.com --local-user sig1#mydomain.com --batch --passphrase-file /path/to/gpg-password --sign -ea myfile
The command encrypts the file for two recipients: key1#mydomain.com and key2#mydomain.com. It signs the file with sig1#mydomain.com. It runs in batch mode as there is no human interactivity - this is an automated process. It gets the passphrase for the signature from /path/to/gpg-password.
What I would like to do is now sign the file with two signatures at the same time. Like so:
$ gpg --homedir /path/to/.gnupg -r key1#mydomain.com -r key2#mydomain.com --local-user sig1#mydomain.com --local-user sig2#mydomain.com --batch --passphrase-file /path/to/gpg-password --sign -ea myfile
gpg: skipped "sig2#mydomain.com": bad passphrase
It works fine in interactive mode (eg. without --batch), I just have to supply the two passphrases via the command line. However, in batch mode it fails as it tries to get the signatures from the file. The signature is only valid for one of the signing keys.
From the man page:
--passphrase-file file
Read the passphrase from file file. Only the first line will be read from file file. This can only be used if only one passphrase is supplied.
How do I tell it what the password is for each key?
You have different options.
Completely remove the passwords, since they're stored somewhere anyway.
Use the same password (as you already discovered).
Use the gpg-agent and preset the passphrase. I'm unsure whether this is GnuPG 2-only (usually installed as gpg2, maybe to be installed from a gnupg2 package). Presetting the passphrase is as easy as running gpg-preset-passphrase --preset [fingerprint]. You will have to run this command for each of the keys individually, and make sure to cache the passphrase for a given time (at least the processing time of adding all the passphrases, and then signing the file you want to sign).
For the sake of completeness, but impractical: sign the file individually for each key, then take apart the OpenPGP packets and recombine them adding all the signatures one after the other. Signing with multiple keys just creates multiple signature packets.
For anyone else in the same situation as me, I ended up working around this apparent deficiency of gpg by editing one of the signing keys to have the same password as the other (the password stored in the gpg-password file). This doesn't compromise security in this instance since the password is stored in a text file anyway - the real security is the password of the user that this commands runs from and the fact that the secret keys are kept secret). You can change the password on a key by doing gpg --edit-key <key_id>, then passwd. Don't forget to save after.
I encryptd a file using gpg, now I want to decrypt the file.
Is there any way to decrypt the file without need to import the secret file?
We have the secret key in a file called key.sec; can we pass the secret file to gpg as a parameter (when we run the decrypt command from the bash command line) to use when decrypting the encrypted file? Or must we import the secret key then decrypt the encrypted files?
You must add the secret key to a keyring. From the gpg(1) documentation:
--no-default-keyring
Do not add the default keyrings to the list of
keyrings. Note that GnuPG will not operate without any
keyrings, so if you use this option and do not provide
alternate keyrings via --keyring or --secret-keyring,
then GnuPG will still use the default public or secret
keyrings.
You could --import --no-default-keyring --secret-keyring temporary to import the key, use --secret-keyring temporary when decrypting the content, then delete the ~/.gnupg/temporary.gpg file when you're done. But that's just a work-around.
You have to import the secret key to use it but the way that secret keys are managed by GnuPG version 2.x has changed. There is a gpg-agent daemon that handles secret keys access and its use is mandatory from version 2.1.
Here is a way that you can quickly create a temporary keyring to decrypt with a secret key that is contained in a file:
$ mkdir -m 700 ~/.gnupg-temp
$ gpg --homedir .gnupg-temp --import key.sec
$ gpg --homedir .gnupg-temp -d an_ecrypted_file
If you want to clean up afterwards, stop the agent and remove the directory:
$ gpg-connect-agent --homedir .gnupg-temp KILLAGENT /bye
$ rm -r ~/.gnupg-temp
There used to be an option --secret-keyring about which the documentation for version 2.1 has this to say:
This is an obsolete option and ignored. All secret keys are stored in the private-keys-v1.d directory below the GnuPG home directory.
The private-keys-v1.d directory (wthin the --homedir or ~/.gnupg) is owned and operated by the agent.
The objective of the OP Mohammed appears to be keeping his PUBLIC and SECRET key apart. After all, do we want to keep the Secret key with the data it was used to encrypt? Thus, Mohammed's and 10,650+ others (at the time I write this) are interested in if/how it's possible. Indeed it is, and this is how you do it:
The publicly-facing host only has two keys: Both are Public Keys
Your GPG Public key used to encrypt data
Your SSH Public key in .ssh/authorized_keys to facilitate non-interactive logins.
Round-tripping an encrypted file using Public-Secret key separation:
The following bash snippet when executed on the host with the Secret Key will fetch the crypted file from the DMZ host via scp, and squirt the gpg decrypted standard output back onto the DMZ host into a file so it can be read/operated upon. This code is tested and known to work correctly:
echo "$(gpg -d $(scp myuser#192.168.1.10:/home/myuser/test-gpg.txt.asc .;ls ./test-gpg.txt.asc))" | ssh myuser#192.168.1.10 'cat > /home/myuser/test-gpg.txt'
Note that you will still be prompted for a password once decryption begins. But once the password is supplied, the script continues and injects the decrypted gpg stream into a file on DMZ host.
And don't forget to do an rm test-gpg.txt of the decrypted file once the operation that required it's contents to be readable has been completed.
So yes, very possible to keep your secret key apart from the publicly accessible host where encryption occurs and your secret key tucked safely away in a host outside of that DMZ. HTH- Terrence Houlahan
I almost been stuck a day on the following issue,
I installed LDAP using: apt-get install slapd
and use the following configuration:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
allow bind_v2
loglevel 0
moduleload back_sbdb.la
database bdb
suffix "dc=test,dc=nl"
rootdn "cn=Directory Manager,dc=test,dc=nl"
rootpw test
directory /var/lib/ldap
index objectClass eq
index userPassword eq,pres
index givenName,mail,mobile,sn,title,cn,description eq,sub,pres
index displayName eq,sub,pres
index postalAddress,facsimileTelephoneNumber pres
access to *
by self write
by * read
and I then try to bind using
ldapsearch -D cn=Directory Manager,dc=test,dc=nl -w test
but I still recieve the error ldap_bind: Invalid Credentials (49)
Anyone has any idea or clues what this could be?
Thanks in forward
Try it using quotes like;
ldapsearch -D "cn=Directory Manager,dc=test,dc=nl" -w test
Space character in Directory Manager may cause the problem.
Edit: Also, are you sure you don't need -h -p parameters?
-h The host name of the directory server
-p The port number of the directory server
Edit2: Just figured out what is wrong. You are using rootpw unencrypted in your slapd config file. You should use an encrypted password created by slappasswd tools output. This may cause problems under special circumstances.
Check this link for details: http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ldap-quickstart.html
A few things you could try:
Turn on more verbose logging (loglevel 255), and see if anything shows up in the log file.
Verify that the server really is reading the configuration file you think by checking the access time on the slapd.conf file (ls -lu slapd.conf)
Try binding using an invalid dn (ldapsearch -D cn=no-such-user -w test) and see if the error message changes (if so, that confirms that the problem is with the password, not the dn).
Try man ldapsearch.
I'm not really sure on debian/ubuntu, but in FreeBSD you need to add a -x to use simple authentication instead of SASL. I think this might be your issue?
Also, you could use -W instead of passing the password plain text on the commmand line.
Is it possible to add a salt to passwords in .hpasswd files? I assume not since the server would need the salt for each user in order to verify the password and I can't think of how it would get them, but otherwise if the list was to be obtained it would be rather vulnerable. Is there a solution?
Many thanks for your help,
Ben
By default htpasswd uses the standard crypt function and thus passwords are already salted - note in this example that both users have the same password yet the hashes are different:
simon#diablo:~$ htpasswd -b -c htpasswd simon abcd
Adding password for user simon
simon#diablo:~$ htpasswd -b htpasswd simon2 abcd
Adding password for user simon2
simon#diablo:~$ cat htpasswd
simon:NWvm/LCCxQ64E
simon2:2I.LBzsRqULN6
(note: the -b flag is normally discouraged because other users can see your command line arguments and hence the password)
The first two characters of the hash are the salt; passwords are verified by calling crypt() again. Entering the wrong password produces a string that's unequal to the hashed password:
>>> from crypt import crypt
>>> crypt("wrongpass", "NWvm/LCCxQ64E")
'NWbxQgX1unvso'
whereas the correct password produces the expected hash:
>>> crypt("abcd", "NWvm/LCCxQ64E")
'NWvm/LCCxQ64E'
htpasswd -m uses a different algorithm that's MD5-based and uses a longer salt:
simon#diablo:~$ htpasswd -m -b -c htpasswd simon abcd
Adding password for user simon
simon#diablo:~$ cat htpasswd
simon:$apr1$mfvnBVmG$iIHIHOaH9vcImG5G.8eVa/
Here, the salt is the 8 characters between the second and third $.
htpasswd -s stores a SHA-1 digest with no salt; this appears to be for compatibility with Netscape/LDIF:
simon#diablo:~$ htpasswd -s -b -c htpasswd simon abcd
Adding password for user simon
simon#diablo:~$ htpasswd -s -b htpasswd simon2 abcd
Adding password for user simon2
simon#diablo:~$ cat htpasswd
simon:{SHA}gf6L/odXbD7LIkJvjleEc4KRes8=
simon2:{SHA}gf6L/odXbD7LIkJvjleEc4KRes8=
These can easily be reversed - convert into a hex digest:
>>> "".join("%02x" % ord(c)
... for c in "gf6L/odXbD7LIkJvjleEc4KRes8=".decode("base64"))
'81fe8bfe87576c3ecb22426f8e57847382917acf'
then use an online hash database.
The htpasswd utility already does use salts in most cases:
The crypt() and MD5 formats permute the representation by prepending a random salt string, to make dictionary attacks against the passwords more difficult.
And that's (sort of) the purpose of salts in password files. While salts have to be included in the server's .htpasswd file for the server to be able to check passwords, it is the numerous different possibilities of what a salt could be that defends against such attack techniques as rainbow tables.
However, if your users pick weak or common passwords, password cracking is a problem anyways, since the attacker (presumed to have access to the password file) will try those first, very quickly in fact (not limited by the speed of the server and Internet connection), by guessing in the normal way. The best advice I can give is that users should always pick strong passwords.
Edit: Haven't solved my problems, but I've moved on to new and more exciting problems.
Leaving this here in case anyone has and insightful that'll help someone who stumbles on to this question in the future.
Hi,
I'm attempting to send an encrypted email from php to outlook. As such, I need to generate a certificate to import into outlook. I had no problem generating a set of keys using openssl and the CA.pl script that comes with it, but when I try to run the command to generate the PKCS12 file to import into outlook it complains about a missing "demoCA" directory. It appears this directory is a part of openssl, and is referenced in the openssl config... but i have no idea where it is. I've searched the drive in many ways from grep to spotlight (on os x, though i really wasn't expecting spotlight to find anything), and can't come up with anything.
The command I was trying to run is:
$ openssl ca -cert newcert.pem -ss_cert newcert.pem
Using configuration from /sw/etc/ssl/openssl.cnf
./demoCA/private/cakey.pem: No such file or directory trying to load CA private key
19918:error:02001002:system library:fopen:No such file or directory:bss_file.c:245:fopen('./demoCA/private/cakey.pem','r')
19918:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:247:
I am a bit of a noob when it comes to encryption / SSL, so I might be missing something stupid (I'm sure if it, haha).
You should create a new CA by means of the script provided, which is easier than just handle all the openssl options. You can do this be means of openssl bundled with Cygwin inside Windows itself or use your favourite Unix distro. I will show you how to do it with bash scripts (but perl scripts should be the same).
$ ./CA.sh -newca
This creates demoCA directory with the CA certificate inside it. As you invoke above command you will be prompt about the fields of the CA certificate (CN, OU, etc.) and CA private key passphrase.
Now you can create certificate requests or certificates from certificate requestes.
$ ./CA.sh -newreq
This prompts for a new certificate request fields and the passphrase to encrypt the private key generated. By default the request is left in the same directory as CA.sh (newreq.pem). It is important that you use as CN (Common Name) the email address you have.
Now you only need to sign it and you have a full blown certificate.
$ ./CA.sh -sign
This will generate newcert.pem which is the signed certificate request. You have your certificate, you only need to pack the certificate and the private key inside a PFX or P12 file, that Microsoft CSP recognizes.
Then copy the contents of newreq.pem and newcert.pem into a file.
$ cat newreq.pem > keypair.pem
$ cat newcert.pem >> keypair.pem
And now generate P12 file by means of openssl shell (this time we don't have the help of any script). It will prompt you for the passphrase you used when request was generated and then the export password (to encrypt private key inside p12 file).
$ openssl pkcs12 -export -in keypair.pem -out mykeypair.p12
Enter pass phrase for keypair.pem:
Enter Export Password:
Verifying - Enter Export Password:
Et voilà. You have a PKCS#12 file that you can double click in Windows and import it to your keystore and use it as a mail signing certificate (I don't remember if default options are enough or you need to specify some additional attributes when creating the certificate so Outlook recognizes as a e-mail signing certificate). You will also need to import CA certificate as a trusted CA (copy cacert.pem to cacert.cer that is inside demoCA directory and double click it to import).