Strategy/structure/roadmap to learn Pentesting I am currently teaching myself computer security and pentesting.
My problem is the following: I more or less know the absolute basics (tcp/ip, bufferoverflows, xss...) but in all those areas I dont have complete and deep understanding of the topics. My current way of teaching myself is doing wargames, right know pwnable.kr, and then I try to read myself into the exercise until I can solve it. Unfortunately at wargames there are often no good answers or solutions and often when I google the topics I only fing very superficial explanations of what is going on.

So my first problem is: How do I get a deep understanding of common vulnerabilities and how to exploit them?

My second problem is this if a very unstructured approach and I feel like I am missing out on important things.
What would you recommend? What is a good approach to get from "I pretty much know the basics" to "I can apply my knowledge to pentesting and can solve wargames/ctf's" ?

In other words: Program/List/FAQ/Course about pentesting that guides you from easy things to the advanced stuff?

I am thinking about all those fitnes websites that have detailed plans how to make progress where you personally stand.

Are there any good moocs for computer security?

My personal goal is to compete in a live ctf someday, so I want to teach myself the skills needed for that.
Thank you so much!

How do I get a deep understanding of common vulnerabilities and how to
  exploit them?

There are papers about vulnerabilities which describe the attack vectors, a deep knowledge of the used functions and programming and scripting languages may be required. Generally you learn by auditing and testing code and learning the OWASP cheatsheets for common webapp vulnerabilities.

  Program/List/FAQ/Course about pentesting that guides you from easy
  things to the advanced stuff?

There are some institutes and websites which provide free and paid trainings and courses and free papers. But you should also practive on real webapps, read exploits and try to understand how they work.

Best way is to learn the languages, their functions / methods and their pitfalls.

As software- or webdeveloper you have a much better overview when writing and reading code.

Here are some helpful ressources:
https://github.com/enaqx/awesome-pentest
https://github.com/sbilly/awesome-security#scanning--pentesting

OWAS ZAP is a well known pentesting tool and OWASP has many articles and cheatsheets about pentesting and security.

https://www.owasp.org/index.php/Web_Application_Security_Testing_Cheat_Sheet
https://www.owasp.org/index.php/Category:How_To

You may take a look at the SANS Institute reading room:
https://www.sans.org/reading-room/whitepapers/testing/

They also provide courses, trainings and certificates.


Isolating host machine from external network How to prevent a host machine from sending/receiving packets with the following network configuration:

eth0 - physical NIC :: not configured;

tun0 - virtual NIC for VM which role is the gateway for other VMs :: auto configured (dhcp), has Internet access, receives ip from the router (192.168.1.1/24);

tun1 - virtual NIC, the gateway for other VMs :: 10.0.2.1/24, dhcpd, iptables with NAT masquerading 10.0.2.0/24 through tun0 (which is eth0 in the guest VM)

bridge0 - bridge that includes eth0 and tun0 :: not configured

bridge1 - bridge that includes all VMs virtual NICs (tun{1...}) :: auto configured, receives ip from the gateway's VM dhcpd (10.0.2.1), but default route through 10.0.2.1 is deleted.

I want to completely isolate my host machine from the external network (Internet in my case). And I need to access VMs network 10.0.2.0/24. So the route table on the host machine looks like:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 br1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo

But there is one VM that is the gateway to Internet for other VMs, but not for the host (which is part of 10.0.2.0/24 network). I'm interested if deleting the default gw is sufficient or some smart software running in user-space can detect that 10.0.2.1 is the gateway to Internet and Linux kernel allows to route to unknown hosts through that.

on IP layer the host machine will not receive nor transmit anything. However, on layer 2 and below it will see all traffic. What is your real objective?


Are environment variables entered *directly* before a command visible to other users? UPDATE: I know that environment variables are generally secure, and am familiar with this question. My question is can other users see them if they are entered as part of a command (same line, no semi-colon), seeing as command line options are not secure. Normally env vars are entered as a distinct command, on their own line.

You can enter environment variables just before a command like this:

# FOO=bar some-command

(ie, all in one line, no ;, not in separate commands)

is FOO=bar visible to other users (in Unixy systems)?

I fully agree with @AndreBorie, you have the shell history where the command will be logged together with the variables. e.g.

$ FOO=bar echo 3
3
$ history 2
  674  FOO=bar echo 3
  675  history 2

You can disable that with set +o history for bash or the POSIX way with set -o posix; set -o nolog (which does not work in either bash or zsh according to my tests).

On Linux you have two more files of interest: /proc/<PID>/environ and /proc/<PID>/cmdline.  The environment file is safe from other users:

$ ls -l /proc/self/environ
-r-------- 1 grochmal users 0 Sep 28 00:51 /proc/self/environ

But the command line file, not quite:

$ ls -l /proc/self/cmdline
-r--r--r-- 1 grochmal users 0 Sep 28 00:51 /proc/self/cmdline

Fortunately the Linux folks have been there and the cmdline file does not log the environment variables passed:

$ cat -v /proc/self/cmdline
cat^@-v^@/proc/self/cmdline^@

$ FOO=bar cat -v /proc/self/cmdline
cat^@-v^@/proc/self/cmdline^@

The important thing about /proc/<PID>/cmdline is that it is from here that ps takes its information about processes' command lines.  Therefore these variables will not be seen in something like ps aux or ps -afe.


Why is it not possible to fake a digital certificate? When a client accesses an HTTPS webpage, (please correct me if I'm wrong), it just checks whether the certificate of that website has been signed by a trusted CA or not, but does not ask directly the CA something like: "ey, did you actually sign this?". Then why is it not possible to fake a digital certificate just by creating one with a signature of a well-known/trusted CA like VeriSign?

A digital certificate, especially the most-common X.509 format used for TLS, has a number of parts. Three of the most important are the subject name, the subject public key, and the issuer signature. The first two tell you who the certificate is for (such as "*.stackexchange.com"), and what the public key that corresponds to that entity's private key is. Spoofing these parts would let you use a certificate that was issued to you for intercepting requests to another server (by changing the subject name), or using your own public/private key pair to decrypt the key exchange and thus decrypt the entire TLS connection (by replacing the subject public key with your own public key). Therefore, the certificate needs to be protected against tampering, and the recipient of the certificate needs to be able to tell whether the certificate was spoofed or not (you could, after all, just make up the subject fields). That's where the signature comes in.

Digital signatures are created using a private key, not a public key, so only the holder of that private key can create the signature. Anybody who has the public key can verify the signature, though. Typically you create a signature of a short byte string, called a cryptographic hash digest (the output of a function like SHA-256), because public/private-key cryptography is slow (though you could, in theory, sign the entire certificate). Verifying the signature string turns it back into the original digest. If the verified signature does not match the digest of the certificate (which the client can compute themselves), then the certificate is not trusted (because it's been tampered with or has a fake signature).

Because the only entity with a CA's private key is (in theory) the CA itself, only the CA can create signatures that will verify using the CA's public key. The client doesn't need to ask the CA whether it signed the certificate; if the CA didn't sign the certificate, then the certificate wouldn't have the CA's signature on it (unless somebody else got ahold of the CA's private key, which is the kind of failure that tends to put a CA out of business). An attacker also can't just take the signature from some valid certificate X and put it on a fraudulent certificate Y, because when that signature is verified it will match the digest (hash function output) of certificate X, but not the digest of the fraudulent certificate Y (unless the attacker has found a collision in the hash function, which is why nobody trusts certificates signed with old and broken hash functions like MD5 anymore).

Clients, such as your browser, know what the CA's public key is because trusted CA certificates (which include public keys) are included with your client, or even with your operating system. Therefore, I can't just sign something with my own private key and pretend Verisign signed it; Verisgn's public key is already known to your client and wouldn't verify the signature, so you wouldn't trust the certificate. This trust is often used transitively; a root CA (like Verisign) might say "I trust this so-called intermediate CA, so I'm going to sign their certificate (including the part that says that their certificate can sign other certificates), and you should trust them as you trust me." The intermediate CA can then sign a certificate for a web site or something, which is at the bottom of a "chain of trust" that connects the web server's certificate to the root CA certificate by way of the intermediate CA.


No HTTPS on credit card entry form - can it be safe? I was going to make a purchase on a website, but the page containing the credit card entry form is served via HTTP and not HTTPS. Is it definitely unsafe?

The website advertises the use of "RapidSSL", but if I send my credit card number through HTTP, this SSL connection will not be used. Is pressing Next on this page a security concern?

Checked it now: CC details are really sent UNENCRYPTED over the wire. They use no SSL at all.
Not even on POST. The credit card details are really sent over the clear, over the wire.
The RapidSSL button is even false, because it does not popup a validation when clicked (which real RapidSSL buttons should do)

I also checked. They have a SSL site with real certificate and Everything, but they specifically disable SSL by redirecting to HTTP when attempting to load the /secure namespace over HTTPS. It should really be the opposite, where HTTP redirects to HTTPS.

I would say you can be sure about submitting a CC number there, and thats only in this specifically case:
If you are 100 % sure that your WHOLE PATH, from your computer, to that company's server, is completely trusted, then you can submit the CC there.
That includes trusting your ISP, your landlord and every router and device on the path to the Company in question.

How to check yourself:

Check the source of the page.
If the credit card form "form action=" parameter Point to a HTTPS site, its encrypted.

If the "form action=" parameter is empty or contains a invalid value, chances are the CC is submitted over a AJAX script and thus you have to rummage through tons of JS code to find out if CC are sent encrypted or not.

However, submitting to a HTTPS site from a HTTP site is NOT 100% SAFE. There is possible that the page in question has been modified in transit by a malicious indivual to send the details to a attacker's server or via a HTTP Connection to be able to sniff the data.

However, MITM/modifying attacks are rare, if you are home on your home Connection and you DO NOT sit on wireless, its pretty hard to get into a suitable position to be able to modify data in transit.

I would say:
As long as the form submits to a HTTPS resource (form action=https://blaahblaahblaah) you can be SUFFICIENT safe that the credit card is not being leaked.

If we take the assumption that there only PASSIVE listernes, no Active adversiaries in the network, then your credit card number is 100% safe if the form is sent over HTTPS.
However, this are NOT in case here, thus you should really trust the link Before sending anything there. Not even your home Connection may be fully 100% safe to send CC details there, if you account in the physical security of EVERY node on the path.


Does the TOTP Algorithm rely on the client time always being synced correctly? What happens if for some reason a cell phones clock / calendar is off by a significant amount of time?  Does the TOTP (Time-based OTP) algorithm generate an invalid token?  Also, do time zones play a role in the token being correct or does both the client and the server talk to a Network Time Protocol server to ensure that everything is synced up?

So in other words if we wanted to bullet proof the design of the server to be sensitive to the above scenario how would we go about doing this?  For instance suppose there was a 5 seconds differential between server time and client time and my grand mother was typing the the code on her phone, and just taking a long time.  How would be assess the amount of buffer time the user has to type the code and whether it's correct or not.

Also how are all clients ensuring that their timestamp starts at the same time that the server epoch instant starts?

Does the TOTP Algorithm rely on the client time always being synced correctly?

Yes

  What happens if for some reason a cell phones clock / calendar is off by a significant amount of time? Does the TOTP (Time-based OTP) algorithm generate an invalid token?

They would be unable to authenticate correctly. This is not exactly an invalid token, just a token for a different time.

  do time zones play a role in the token being correct

No

  does both the client and the server talk to a Network Time Protocol server to ensure that everything is synced up?

No. A NTP server is a way to make any of them to get the right time, but your grandmother manually introducing the current date and time (and the device being configured in the right timezone) would work as well.

  suppose there was a 5 seconds differential between server time and client time and my grand mother was typing the the code on her phone, and just taking a long time. How would be assess the amount of buffer time the user has to type the code and whether it's correct or not.

The server can be a bit lenient by accepting a few time steps around the right one (from the server POV), and using a not-too-small time step.

For example, with a Time Interval of 30 seconds, and accepting 3 TS above or below the server one, it gives your grandmother 1.5-2 minutes to type it. Increase it to 10 and you would give her 5 minutes… It's just a matter of determining for how long you want to accept them. But conversely, that allows a greater attack window to fraudulently use such code.

Regarding the clock skew, note that you could record the difference between expected and provided codes and extrapolate the expected skew from that. If at day 1 10:00, the user provides the code for 09:58, and the next day the code for 09:56, it could infer that it has a clock skew of 2 minutes per day, and adjust accordingly the server expectation for this user to old values that would otherwise not be used (properly resetting when the user clock is "fixed"). This calculation increases the complexity noticeably, though. Most of times, I don't think you would generally need to do that.

  Also how are all clients ensuring that their timestamp starts at the same time that the server epoch instant starts?

The algorithm they both agree to use, set a given time from which the instant starts (typically the Unix epoch).


Wifi penetration testing: waiting for beacon frame I was trying penetration testing on my wifi and every time when I use command
aireplay-ng -1 0 -a bssid wlan0mon and hit ENTER
the response is
Waiting for beacon frame bssid on channel 11.
wlan0mon is on channel 11 but the AP uses channel 1.

How can I solve this problem? I am currently new to this.
I tried something like
sudo iwconfig wlan0mon channel 1 but it didn't work.

If you know the channel you want to attack, then when setting your network interface in monitor mode, just specify it:

airmon-ng start wlan0 1

Also, I notice you use -1 0. Don't forget that this "attack" mode does not work with WPA/WPA2.


How to sign multiple data sets with a single signature, so that it can be validated for single data set without requiring the rest of the data? Let's say Alice has three secrets: SecretA, SecretB, SecretC
Alice shows these three secrets to Bob and gets a single signature from him that signs all three secrets together. Something like
Signature = Sign(Hash(SecretA, SecretB, SecretC))

Of course some care needs to be taken here with the hash function to avoid second preimage attacks.
Now Alice would like to prove to Carol that Bob has seen/signed SecretA, without revealing SecretB and SecretC to her (Bob is not around anymore to ask, but Carol trusts Bob's certificate).
Is there some form of hashing & signatue that would allow this? So that she can generate some proof using all three secrets plus the signature, but that will require to reveal only SecretA to Carol (plus maybe some data derived from SecretB and SecretC, which does not allow to recreate these secrets however)

Yes, if Bob creates his signature over hash(SecretA) || hash(SecretB) || hash(SecretC), like so:
Signature = Sign( hash(SecretA) || hash(SecretB) || hash(SecretC) )

and hash(SecretA), hash(SecretB), and hash(SecretC) are made public.
Then, Alice can prove to Carol that Bob signed SecretA by taking a hash of SecretA, and concatenating it with hash(SecretB) and hash(SecretC) [remember hash(SecretB) and hash(SecretC) are public, so Alice and Carol do not need to know SecretB and SecretC] , then verifying the signature over the above using Bob's public key.


Create mod page for an anonymous website I developed a website. There is no login section in the website. I didn't want to force people to sign up. Now I have a problem. There are a few .php pages that only I should access. How can I do that? I am afraid that some hacker will find the page and have access to admin functions on the site.

What I did I included this code on the page:

if($_POST['code'] != 'mysecretcode')
   exit("you are not allowed");

Whenever I want to enter that page, I include the code as a POST parameter:  http://mywebpage.com/iptracker.php?code=mysecretcode

However, I don't know how effective this solution is.

The most simple solution would be to protect the files which are part of your admin interface using the http password authentication capabilities of your webserver (like .htaccess on apache). This will prompt you for a username and password via your browser. You rarely see this solution "in the wild" because it's far uglier than logging in through a web-based form, but it's entirely sufficient for private admin backends where beauty doesn't matter.

A solution with an even higher security standard would be to use TLS authentication with both server and client certificates. It means that the connection to the admin portal is encrypted and that the user-authentication works via a certificate in your web browser. Consult the documentation of your webserver for how to set this up. You won't need to get a server certificate from a 3rd party authority (even though you can get them for free now). Because you are the only user, you can simply add your own certificate as a trusted certificate to your web browser.


Special characters in filename leads to starting virus executable So I've just downloaded torrent with one file in it - the formal name of file should  be "123.avi.exe" (which is typical for viruses and trojans). Now, interesting thing is that name is encoded in UTF16-LE as following bytes:

FFFE3100320033002E002D202E202D202E206900760061002E00650078006500

which gives us strange, partially reversed over ".exe" text (try to move cursor left-to-right and you will be surprised):

123.iva.exe

But the bad part of all - is that utorrent showing non-suspicious ".avi" extension while when you double click it in GUI - it goes as as ".exe" and program runs.

You can test it yourself by creating dummy file with the name I wrote above. One more interesting thing - Total Commander prevents executing such file if it's name contains these special characters.

P.S. I've started similar thread on uTorrent tracker (not yet approved by moderator)

The trick is the right-to-left override character. Languages such as Arabic write right-to-left instead of left-to-right. To embed such text in a string, you can switch the direction of the text, and that can help in hiding the real extension.

helloworld.<RLO>cod.exe

will be displayed as

helloworld.exe.doc

because the part after the RLO character is reversed.


Is it possible to not store passwords locally, at all? Earlier this year I was playing around on the schools computers and found out the administrative password to a computer in my classroom. I realized how XP stored their passwords, booted into Ubuntu, and took the SAM and SYSTEM files. I was wondering if it was possible to store these passwords on a remote computer and use roaming desktops, so that if one system was compromised the passwords would still be safe because they were not stored on the local machine, but a remote one that only verifies their access to the domain? This would ideally be some computer server locked up somewhere like in the office or network closet, but any advice or comments on the subject would be nice. Thanks for any help

Yes it is, you must have the computer on a domain and disable password caching. Know that if you do this you will receive the error "The system cannot log you on now because the domain  is not available." if the domain server is down.

This can be done by setting a group policy to have HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\CachedLogonsCount set to 0.


Which attributes of a X509v3 certificate are never really used? Are there any extensions/extended key usage attributes of a X.509Certificate that are rarely or never used in practice?
Either due to never being part of an issued certificate or because they are skipped during validation for some reason (e.g. obscurity in the RFC on the usage of the attribute)?
A  documentation of the opposite (i.e. list of attributes extensions/extended key usage that are known to be used in the field) if available would be also of interest to me.

Take care that the set of possible extensions is, by definition, not bounded (at least not practically; there is an internal limit a bit of about 1282255). There are standard extensions which are described in the X.509 standard, but there could be a lot more elsewhere. In particular, Microsoft's implementations (e.g. AD Certificate Services) tend to use a few Microsoft-specific extensions (such as an extension which designates the "certificate template" which was used to issue a given certificate).

Among the extensions described in RFC 5280 (which is the standard for "X.509 on the Internet"), the following are rarely used in practice:

Policy Mappings: people rarely get policies right anyway, and to use mappings meaningfully you have to understand how certificate policies work.
Issuer Alternative Names: this is not a very useful extension, since name chaining in a certificate path uses Distinguished Names, so there is little reason to give extra names to the issuer (if extra names are needed for an entity, they will be as Subject Alternative Names in the certificate for that entity).
Name Constraints: support from existing implementations is, let's say, a bit lacking in reliability. Also, the semantics are convoluted and contrived, so even if someone says that they implemented it, you cannot be sure that they implemented it properly and it is hard to test. Thus, nobody really uses them.
Policy Constraints and Inhibit anyPolicy: same reasons as for policy mappings.
Subject Directory Attributes: too new, too broad in scope.

All other standard extensions are commonly used (not always used, but common enough). However, some features of these extensions are rarely used, including indirect CRL (where the CRL issuer is not the CA), CRL scopes which do not cover all revocation reasons, X.400 addresses,...


Android, how to protect in case of theft What are some steps to take into account to protect an Android phone in case of theft?

Smartphones are everywhere now, before the market was dominated by Blackberry and Windows Mobile. These days more and more companies are adopting Android, Windows Phone and iPhone instead.
People carry a lot of information on their phones, often confidential data that was distributed through email.

How can one protect from leaking this business critical data in case of theft? Meaning: remote whiping or encryption of all data on the phone so that a thief cannot access this data anymore.

Since Ice Cream Sandwhich, Android devices support full disk encryption. This is based on dm-crypt and requires password or pin to unlock your phone. While users may find this irritating (the swipe method is not supported), it is a tradeoff you will need to consider to keep your info safe.

Apps that can whipe data or more:

Kaspersky Mobile Security
Touchdown

Email clients that encrypt your email:

GOOD
Voltage Securemail


Is a mobile app more secure for mobile use than the "normal" website? An untrained end user who uses a mobile web browser is vulnerable to phishing and can't easily verify the the authenticity (or security) of a website among other issues.  Also, it is very easy to prevent even a knowledgeable user from detecting MITM by hiding the HTTPS icon, replacing it with a favicon, or many other tricks since most many browsers completely hide the entire URL.

Is a native application (perhaps with certificate/root cert validation) really the only way to achieve reliable, secure interaction with my back end services over HTTPS?
Should I train my end users to not use a web browser, and use an "app" that is hard-coded to my URLs and optionally does additional certificate validation to reduce MITM risk?
Should my web server go as far as detecting a mobile session, and prevent them from authenticating?

A web app and a web browser both have the same problem- an attacker can subvert the data they send or receive.

I would not encourage forcing a user to use an app over a browser- I would take it the wrong way of a company tried to force me. I might not want to install an app, as part of my security policy.


Is it possible to crack hash with known salt? If yes how? If the salt in the hash is known to us, then is it possible to crack to extract the password from the hash? If yes, how?

Hash functions are designed to go only one way. If you have a password, you can easily turn it into a hash, but if you have the hash, the only way to get the original password back is by brute force, trying all possible passwords to find one that would generate the hash that you have. Assuming the salt is very long, not knowing the salt would make it nearly impossible to crack (due to the additional length that the salt adds to the password), but you still have to brute force even if you do know the salt.

As an example, let's say that the password is "secret" and the salt is "535743". If the salt is simply appended to the end of the password, then the hash you'd be cracking would be a hash of the string "secret535743". Without knowing the hash, you'd have to try all possibilities until you reach "secret535743", which would take quite a while due to its length (keeping in mind that real salts are much longer than this).

But if you know that the salt is 535743 and that it is appended to the end of the password, then instead of trying everything, you'd try "a535743", "b535743", "c535743", etc. This greatly reduces the number of possibilities you have to try until you reach the correct string.

With that being said, it is generally quite rare to have a situation where you know the hash but not the salt since both are usually stored in the same place.


How does basic HTTP Auth work? How does basic HTTP Auth work?

The server sends back a header stating it requires authentication for a given realm. The user provides the username and password, which the browser concatenates (username + ":" + password), and base64 encodes. This encoded string is then sent using a "Authorization"-header on each request from the browser.
Because the credentials are only encoded, not encrypted, this is highly insecure unless it is sent over https.


Best approach for making an app that connects to sensitive information I'm gonna be writing an app that connects to a server with sensitive information and one of the main requirements is that only my app will be able to make the connection.  There is no user supplied username or password involved.  Btw, this will be on the Android platform, but that shouldn't be too relevant for this question.

I'm not too familiar with the inner workings of secure internet communications, however, I'm assuming the best approach will be to establish a SSL connection between my app and the server.  The concern I have is: what prevents someone from monitoring what network traffic my app sends to the server to initiate the SSL connection and then sending the same traffic to open up their own connection (ie: duplicate the random number I send to the server that's used to create the session key)?  I'm assuming these kind of things have been though of before and secured against, but I'm hoping someone can share some more insight into this to help deal with my concern.

Thanks,
Harry

SSL prevents an attacker on the network from being able to see or manipulate the data in transit.  However,  this makes no guarantee that the user of the application hasn't modified the application.  Any value stored in memory on the device can be easily obtained using a debugger.

In short you can never trust the client,  and this isn't a problem that cryptography can solve, period.


Can I prevent all employees from accessing customer data without being logged (especially IT) I am hosting a web application and SQL server database on Azure and I would like to ensure that no individual at the company can access customer data without the access being logged. It seems that with all the security options in Azure there is always a way for at least one admin with malicious intent can gain access to keys and anonymously access the data or storage of the data. What option are there to secure the data from access without an audit log?

(This scope of this question does not include the trust in the cloud provider and is specifically only concerned with securing against employees of the technology company)

If there's a way to access data without an audit log, secure the credentials required to access it that way and audit their access. Software such as Vault is geared toward this. Physical control of an MFA token such as storing it on a YubiKey and then putting that in a safe place with somebody who doesn't control the password would provide you with dual control.


Can the content of a plain-text help breaking the key to the encryption used? i am currently trying to encrypt a set of files safely (using AES encryption in CBC mode), but knowing that plain text copies of some of these files may be floating around the file system i am worried that the content of these copied files can help break the key to the entire set of files i am trying to encrypt (with the same key). i know a very obvious solution is to encrypt every file with it's own key but, it seems quite an awkward solution...

No, knowing the plaintext of a given ciphertext does not improve an attackers attempt to break AES-CBC.

https://crypto.stackexchange.com/questions/1512/why-is-aes-resistant-to-known-plaintext-attacks


Does hiding php error messages increase security of the web app? Many PHP frameworks such as Codeigniter on production environment opt-out to hide any PHP related error message. Also, that applies on other PHP frameworks as well such as Symphony and Laravel (with the appropriate settings).

So I wanted to know if this behavior increases slightly my web-app's security and how is security in increased.

You should never allow end users to gain insights into the inner workings of your system.
Doing so will allow a potential attacker to streamline his attacks and increase the chance that they will be successful.

For more information have a look at this:
https://cwe.mitre.org/data/definitions/200.html


Joomla Linux Permissions I installed Joomla 3 to /var/www/html directory in Cent OS 6 server. Currently /var/www/html is owned by apache:apache.

What is the recommended permissions for Joomla installation on Linux in production environment. Who should own what with which permission?

Here is what finally used as a bash file.

#/bin/bash
chown -R root:root /var/www/html
cd /var/www/html
PLACES='
administrator/components
administrator/modules
administrator/templates
cache
components
images
images/banners
images/articles
language
media
modules
templates
'
for i in $PLACES; do chown -R apache:apache $i; done

find /var/www/html -type f -exec chmod 0644 {} \;
find /var/www/html -type d -exec chmod 0755 {} \;


OS fingerprinting: can I rely on the results? Using nmap -O www.example.com I get:

Running (JUST GUESSING): Microsoft Windows 7|2008 (90%)

So I can say the target site is running Windows.

Using xprobe2 -v www.example.com, I'm just astonished at the fact that the results are completely different being:

+] Primary Network guess:
[+] Host 217.*4.***.** Running OS: "HP JetDirect ROM G.08.08 EEPROM G.08.04" (Guess probability: 86%)

Questions:

Can a website really fake a response given to a network scanner?
Nowadays is there a tool which is able to detect the running OS a hundred per cent sure?

First, the theory
OS fingerprinting works by examining the quirks about how a given computer responds to network traffic. While RFCs specify a lot about TCP/IP stack behavior, some of the details or defaults may not be officially specified, and some OSes may deviate slightly even in prescribed behavior. Since the TCP/IP stack low-level behavior is generally implemented in the OS, implementation differences typically reveal the OS in use.

Next, the complications
That said, it's reasonably simple, almost trivial, to throw off these detection systems. Since these fingerprinting systems rely on the assumption that settings such as initial window size or TTL are never changed, simply changing the defaults is typically enough to throw the system. While some examined behavior reflects code differences, other aspects are user-configurable settings which generally never get changed.

In fact, beyond just confusing OS fingerprinting tools, additional tools exist for the express purpose of giving very specific but "falsified" results in response to fingerprinting attempts.


Could server honesty be audited by remote peers without said peers having sole (or any) control of the server? Suppose for some reason, you and your peers absolutely positively have know that a server is acting honestly.

Could the server behaviour be audited remotely through some mechanism of randomly polling portions of server memory and disk content to check against the predicted result derived from publicly cross-signed drive content?

Or could a server cunningly subvert any such mechanism?

I can think of several methods, not necessarily independent:

Fully homomorphic encryption, the ability to securely compute on other machines without revealing the data, and possibly without revealing the program itself.

HElib, a FOSS project by IBM
Scarab a FOSS project, though impractical/slow, it is a good demonstration

Secure function evaluation, see External links section of article on secure multi-party computation  for possible implementations

Secure Function Evaluation; incidentally hcrypt also has a SFE project, but there are

SNARK/s, (Succint Non-interactive Argument of Knowledge), the ability to turn a program into a proof, and obtain a succinct that the program ran. Here the input isn't provided by you, necessarily, but the twist is, the input can be provided by the computer running the program, and not revealing that input to you. This is a bit different, but for this application, this detail doesn't matter. The program can be verified that it ran fully.

SCIP (Succinct Computational Integrity and Privacy) is an effort to make this practical. They have designed a virtual architecture called TinyRam, for creating and verifying the program/trace/proof, and are working on a C-compiler to the architecture (see SNARKs for C : Verifying Program Executions Succinctly and in Zero Knowledge (extended version) (PDF)).

See also:

Youtube talks:

Universal and affordable computational integrity - Bitcoin 2013 Conference by Eli Ben-Sasson
Eli Ben-Sasson -- Universal and Affordable Computational Integrity, or, Succinctly, from C to PCP

Answers to Using a proof-of-work system to discourage piracy or encourage donations: (1, 2)


What to never log to Android logcat? Android apps write their logs to a file (usually referred to as "logcat") which is very useful not only for developers but also for users who want to investigate problems. You can easily see that hundreds of lines get written to logcat every time you open Facebook, Gmail, Whatsapp, or pretty much any other app.

In all recent Android versions, a logcat line is only visible to the app that wrote it, and to the human user (please correct me if anything is not exact).

As a developer, what should I never output to logcat?

Dialog that the user opens
Language choice of the user
Accessed URL
Software versions
User settings
WiFi name
User nickname
Current geolocation
Credit card number
Password
etc

Where to put the limit? What information, if included, would be considered a vulnerability?
Actually, I often see WiFi names in my logcat.

Context: Small open source non-critical app with only a few thousands users, many of whom send bug reports (including logcat) or even help with debugging, I rely on them and because it is a hobby and I don't have much time for testing.

As a developer, what should I never output to logcat?

Your release build should output nothing to LogCat.

After all, writing information to LogCat adds zero value to the user. While the CPU and battery cost is minimal, minimal is still more than zero, so the cost does not justify the (non-)value. You cannot access the user's LogCat data, except where you are the user (or the user happens to be an Android developer).

As a side benefit, you will not leak private information or security data to LogCat, if you do not log anything to LogCat in your release build.


Is JavaScript needed for browser code execution vulnerabilities? Does JavaScript VM have to enabled in a vulnerable browser to exploit an arbitrary code execution bug?

There is a number of bugs in borwsers that don't seem to involve JavaScript. For example, CVE-2014-8967 or CVE-2015-6184. I understand what use-after-free is, but I'm not clear on how the attacker would deliever the code, especially to a location in memory that is executable. Can this be done without JavaScript VM, or does it have to be enabled?

All browser exploits do not necessarily use Javascript to reach their needs.

A browser plugin can be used to escape a browser sandbox for example.

This means that a malicious person could create a website, knowing that his victim uses vulnerable plugin X (that parses the text of each visited page), and display text on his website that, once parsed by the vulnerable plugin, would escape the browser sandbox and execute code remotely (in this case an exploit in the plugin would be leveraged to exploit a flaw in the browser)

As soon as an external input is read by a browser, a risk exists. In theory a maliciously crafted JPEG could have nasty bits that would make the parser lose its head - in this case good luck finding such an exploit, but you get the point :)

Note that disabling Javascript prevents most exploits from executing. For example, many malware toolkits use Javascript to detect what version of Flash and Java are installed to serve the most appropriate exploit to the user - disabling Javascript would prevent such toolkit to even start fingerprinting the browser


Filtered ports - What exactly filters them? By the NMAP definition, unfiltered ports are the ones which cannot be determined to be open or closed since packet filtering prevents its probes from reaching the port. (ISBN 9780979958717 pag. 77)

So that being said, is my assumption correct that every probe which manage to reach the port will always be properly replied by either a SYN/ACK or a RST?
The only thing which might prevent me to reach the port or get a reply from it would be a security device (e.g. Firewall) -- is that correct?
Can't the application itself just ignore my probes?

In most operating systems, handling the TCP three-way handshake is the responsibility of the operating system's networking code. Applications can only declare interest in receiving connections on a certain port by means of the listen() system call. The operating system will answer a SYN with a SYN/ACK if there is an application listening on the port, and with a RST otherwise. No application has any say in that.

This is the default behaviour. It can be modified by many things, including but not limited to packet filtering mechanisms on the host.
In addition, specialized implementation of TCP/IP may behave differently on purpose.

When NMAP receives neither a SYN/ACK nor a RST in reply to a SYN packet it reports that port as "filtered". It has no way to determine the reason why it didn't receive a reply. Conversely, if an intervening firewall blocks the port by replying with RST then NMAP will report the port as closed even though the probe packet never actually reached its destination.

In sum, your quote is at least inexact. NMAP also reports ports as filtered if they cannot be determined as open or closed for other reasons besides packet filtering. Packet filtering is just the most common of causes, and has therefore become the eponym for that result. What's more, NMAP may even report a port as closed when it cannot determine it as open or closed because of an intervening packet filter.


Is there a good reason (and what can it be) to require DAC restriction on IPC in addition to SELinux rules? Our company is developing an AOSP-based platform for our customer. Some of our vendor services are using HWBinder for IPC which is using SELinux to restrict service discovery and access. The problem is that our customer insists that SELinux restriction is not enough and we need to provide a DAC-based restriction as well.
Our customer is basing this requirement on a security audit that was conducted on an earlier version of the platform. This security audit, however, didn't evaluate HWBinder IPC, but a socket-based IPC that was used in older services. The issue that was highlighted during this audit is that Unix sockets had 0666 access and a recommendation was to change it to 0660 and use Unix groups to allow only specific services to access the socket.
For some reason our customer is now requiring to apply the same (or similar) approach to HWBinder IPC which, however, doesn't have anything to attach these permissions to.
Unfortunately so far I couldn't get a straight answer regarding their threat model, so my question is: Does it even make sense to require DAC + SELinux and if so, what threat model should I be considering to properly implement this restriction?
Also, any ideas regarding how I can get our customer an additional layer of security without changing the IPC method would be greatly appreciated.

World-writable files are pretty much considered bad in all but very specific scenarios.  If there is no legitimate reason to have a file wide-open for the world to read/write to, it's best practice to lock it down.  Nearly all security audits will mark a failure for world-writable files... period.  And remember, in the UNIX world, everything is a "file".
Very few, if any, security audits will take specific selinux policies into account.  If they do, it would be in addition to native OS controls.  And by native, I mean typical UNIX file-permissions.  Many of these tests run across multiple UNIX platforms... Solaris, AIX, BSD, and Linux.  A linux-specific feature like selinux is unlikely to be taken into account.
Files should be owned by the functional account that the application runs as, with permissions limited to the functional owner and it's group, and access limited to those only (in most cases).
Your customers concern may not be tied to a specific threat model as much as it is simply considered best-practice and the ability to pass an audit.


ASV scan with reverse proxy We are PCI compliant as a service provider, however our service port forwards some web traffic at TCP level.

Customers use our PCI compliant service and can choose to upload a TLS/SSL certificate to us if they want their HTTPS traffic analysed. So the flows on our server would be as follows.

Without TLS/SSL Cert Uploaded by Customer

HTTP Port 80 --> Our service analyses the HTTP header data -->
  Customer system port 80 as new HTTP request

HTTPS Port 443 --> Our service simply retransmits the TCP packets -->
  Customer system port 443

With TLS/SSL Cert Uploaded by Customer

HTTP Port 80 --> Our service analyses the HTTP header data -->
  Customer system port 80 as new HTTP request

HTTPS Port 443 --> Our service decrypts and analyses the HTTP header data -->
  Re-encrypted using SSL/TLS to Customer system port 443 as new HTTP request

Note that there is no multitenancy and each customer will have their own set of servers with us for header analysis.

Now there's a problem in the second scenario (without cert and without HTTPS decryption) that we are failing our ASV scans because the scanning traffic hits our customer system and reports on things such as old versions of SSL used, or insecure cipher suites. As you can see, we are simply forwarding traffic at TCP level so any vulnerabilities such as these that are reported are really problems on the customer end-point rather than our system as a service provider. Port 443, and 443 alone is acting as a reverse proxy at TCP level so the scanning traffic is hitting a server that is outside of our PCI scope.

HackerGuardian will not accept these vulnerabilities as false positives because they are failing the ASV scan and are not really false positives - they are vulnerabilities reported from our in-scope system, however it is analysing traffic that is out of scope for us, but in scope for a customer.

How can we achieve a passing scan without forcing customers to fix issues that aren't really any of our concern? Could there be any leeway from an ASV or would we have to implement a compensating control to cover vulnerabilities uncovered when our system is scanned.

You don't so much achieve a passing scan, as work with your QSA to agree the scope of the scan, and ensure this traffic is out of scope.

This will require you have a QSA who can understand this - and a lot does depend on their opinion, but that would be the approach I would take.

If you don't currently use a QSA, ensure you have fully documented the scope and the reasons for excluding certain traffic from scope - this one does seem relatively straightforward.


Save password on user-side for autologin If a user wants to login to a system/server, it's recommended to have the hashed&salted password saved in a database, along with its salt.

So the user wants to login, types in the password, clicks on login and with his input and the salt the system checks if the correct hash is created.

I understand this part.

But when I don't want to type the password every time, how would I save the password on client-side? I can't save it hashed, because I need to salt the clear password for the checkup. If I save it clear, the client is vulnerable. And if I use any encryption where do I store the "master-password".

Also in my case I don't really want the user to force into creating a master-password. Though it's a required feature not to type in the password every time.

Edit:

Second Question:

Well, one question I still have on my mind. How is it done in smartphones? For example your wifi password. You enter it once, it's stored on the device, but how is it secured? Do you know that?

Well, that's what password managers (provided by OSes or embedded in browsers) are for. And yes, you'll need a master password because you need some secret shared with the password manager for it to encrypt those previous passwords of yours. :)

Most websites would provide you with the ability to stay connected via cookies to spare you the pain of re-authenticating. This avoids exposing your credentials, though the cookies being stolen could lead to identity forgery.


Is it possible to establish a secure TLS connection using only client certificate? I'm considering using TLS for a peer-to-peer, SSH-like usage without PKI.

First, there is a setup phase of the clients, before any connection between them is established. The setup consists of generating a self-signed certificate that authenticates A, and then transmitting that certificate to host B. The certificate is transmitted using some pre-established secure channel such as SSH. A requirement is that information flows in the setup phase only from A to B, not the other way around. That means that A can't know about public keys or certificates generated by B.

In the use phase, host A tries to connect to B. In this situation, even if B would have a self-signed certificate of its own, A wouldn't know it. B can't connect to A because of firewalls, NATs, dynamic IPs or other such reasons.

My question is, does TLS using X.509 support this kind of pattern?

1) Is it possible to establish a secure connection using only client certificate, while the server has none? A's certificate isn't meant to be distributed widely; so in theory it would be possible to generate a token using A's private key and demand B to prove that decrypt it using A's public key, or what's even simpler, just demand B to send back the A's public key; I'm unaware whether TLS supports such a flow?

2) From "semantic" perspective certificates are meant to be public information; however, if the use case of 1) is possible, A's certificate must be considered a secret. Is there any better fitting schemes here? I'm thinking of TLS-PSK, but it, on the other hand eschews asymmetricity and A must then be authenticate itself using other, asymmetric means, if I don't want B to be able to imitate A.

From RFC 5246 (TLS 1.2) section 7.4.4 "Certificate Request":

  It is a fatal handshake_failure alert for an anonymous server
     to request client authentication.

It it is not clear in your case if the server is anonymous. But, you specify that the server does not provide a server certificate and you don't say anything about other forms of authentication, like PSK. This suggests that the server in your use case is not authenticated which means it cannot request a client certificate.

But, based on your question you don't actually need a client-certificate-only TLS handshake at all. What you need instead is a TCP connection from A to B followed by a TLS handshake from B to A. In this case A has a role of a TLS server with a certificate known to B. This kind of setup is possible since all the TLS handshake needs is an established underlying (TCP) connection. It does not matter who initiated the TCP connection.


How do I store session data on a server securely I'm building a system where security is important and I'd like to store session details on the server in a session table. However, I'm concerned that if an attacked got hold of the database, they would have access to all session details for all logged in users.

How do I get round this - is it just to keep the session details encrypted and send a secret to the user as a cookie, meaning that on each request there is decryption. This will obviously slow down the user.

I can't store session details in a cookie on user's machine as this cookie could grow very large and may exceed 4kb (maximum request header size).

In general session information is not usually encrypted on the server side. It is generally assumed, as part of the threat model, that if an attacker gains access to the server then they already have everything they need. Session data itself is usually not any more sensitive than the rest of the contents of the database.

There are a few options:

Store them on the filesystem in plaintext. If your threat model suggests SQLi is more likely than filesystem access, this is an easy move.
Encrypt session IDs and data using the database's inbuilt encryption routines. This protects you against cases where a database backup is compromised, but won't protect you against disk theft or an attacker with SQL access.
Encrypt your session IDs and session data in the database, using a key set in a config file on the server somewhere. The benefit of this is that the attacker would need access to both the database (e.g. via SQL injection) and the filesystem at the same time in order to decrypt the session IDs and session data.
Encrypt session IDs and data using a randomly chosen key which is cached within the server daemon process (e.g. APC or memcached for PHP). This would be exceedingly difficult for an attacker to gain access to without full code execution on the system, but has the downside that all session data would be invalidated if you restart the server process.

I recommend the use of authenticated encryption, with separate encryption and authenticity. Pseudocode for encryption is as follows:

iv = secure_random(16)
encrypted = iv || AES-CBC-128(session_id || session_data, enc_key, iv)
auth_encrypted = HMAC-SHA256(encrypted, auth_key) || encrypted

Pseudocode for decryption is as follows:

mac = auth_encrypted[0:31]
encrypted = auth_encrypted[32:]
expected_mac = HMAS-SHA256(encrypted, auth_key)
if mac != encrypted_mac:
    session was tampered with
else:
    iv = encrypted[0:15]
    encrypted = encrypted[16:]
    decrypted = AES-CBC-128_Decrypt(encrypted, enc_key, iv)

This provides authenticated encryption to prevent tampering with session data on the server side.


Secure FTP access; best practices We have several web applications (B2B, B2C eCommerce) to which developers have access in order to upload files.

I need to ensure FTP part is well secure.

What is the best way(s) to go about it?

Currently, I've:

Changed port number, and
Set a static IP (our local IP only) for the uploads

Is that enough to make FTP access secure?

although @mahbubut-r-aaman mentions it in passing, I thought I'd expand on the bit about SSH.  The answer I'd say for securing FTP is don't use FTP.  The reason being that it (by default) sends usernames and passwords in the clear, which isn't considered a very secure approach.

Instead you could look at SFTP (which uses the SSH protocol) or FTP(S) which uses the FTP protocol with SSL for encryption.

Additionally I'd suggest looking at a solution like fail2ban to help block password guessing attempts.

changing the port that it listens on is a bit helpful in avoiding the noise in your logs of random attacks, but you shouldn't rely on it.

locking down access to specific source IP addresses is a good idea if it's practical as it'll limit who can attempt to access the site.


possible exploits through avahi daemon It is always recommended to disable Avahi daemon, for security reasons, when not in use.

So,  by what ways it is possible to  exploit a system which has avahi daemon service running? And how can we secure it?

You can find some of the  vulnerabilities displayed here. The problem with Avahi isn't that it's directly exploitable, but that it uses so called 'zero configuration protocol' or 'zeroconf' it will automatically detect printers, scanners and hosts (computer names) on the network. This can be a good thing for most normal users in a home LAN environment, but you do not want to have this enabled when you are connected to a wireless hotspot with tons of other people whom you don't know and therefor can't trust.

One of  biggest problem with Avahi (well zeroconf in general for that matter) is that it uses multicast DNS rather than unicast DNS, making you even more susceptible to DNS spoofing attacks than normal.


How to use OpenSSL generated keys in Java? I have my pair of Public and Private keys and my certificate. Those where created in OpenSSL (why? because I was asked to do it in OpenSSL).
  Now I want to use those things to make a Java app that uses digital signatures.
  How can I use my private and public keys to encrypt/decrypt info (and use the certificate to see if data is valid? What are the classes in java that allow me to do that?

My keys are in plain text something like this:

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDuyg3h0VbP9iZ6RCxSU6x4WX4
anAwedMVUTqF0WHlvHl1Kiqa6N6TiUk23uXAVUX8RwLFjXWHlG0xwW7mGByA2mX9
5oPQpQFu8C70aMuUotGv87iiLi0UKCZV+9wS9rMdg5LHu1mMPilwgOO6MlyTxKem
-----END PUBLIC KEY-----

UPDATE

I made this code but still can't use the private key to sign a string.

public void encryptHash(String hashToEncrypt, String pathOfKey, String Algorithm) {
    FileInputStream fis = null;
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    int len;

        File f = new File(pathOfKey);

        fis = new FileInputStream(pathOfKey);
        len = 0;
        while((len = fis.read()) != -1){
            baos.write(len);
        }

        KeyFactory kf = KeyFactory.getInstance(Algorithm); //Algorithm = "RSA"
        KeySpec keySpec = new PKCS8EncodedKeySpec(baos.toByteArray());
        baos.close();
        PrivateKey privateKey = kf.generatePrivate(keySpec);  //Here's the exception thrown

        Signature rsaSigner = Signature.getInstance("SHA1withRSA");
        rsaSigner.initSign(privateKey);

        fis = new FileInputStream(hashToEncrypt);
        BufferedInputStream bis = new BufferedInputStream(fis);
        byte[] buffer = new byte[1024];
        len = 0;
        while((len = bis.read(buffer)) >= 0){
            try {
                rsaSigner.update(buffer, 0, len);
            } catch (SignatureException ex) {
                Logger.getLogger(DataEncryptor.class.getName()).log(Level.SEVERE, null, ex);
            }
        }
        bis.close();

        byte[] signature = rsaSigner.sign();

        System.out.println(new String(signature));
}

the exception I'm gettin' is

dic 09, 2011 12:49:02 PM firmaelectronica.DataEncryptor encryptHash
Grave: null
java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: IOException : DER input, Integer tag error
    at sun.security.rsa.RSAKeyFactory.engineGeneratePrivate(RSAKeyFactory.java:217)
    at java.security.KeyFactory.generatePrivate(KeyFactory.java:372)
    at firmaelectronica.DataEncryptor.encryptHash(DataEncryptor.java:40)
    at firmaelectronica.FirmaElectronica.main(FirmaElectronica.java:39)
Caused by: java.security.InvalidKeyException: IOException : DER input, Integer tag error
    at sun.security.pkcs.PKCS8Key.decode(PKCS8Key.java:361)
    at sun.security.pkcs.PKCS8Key.decode(PKCS8Key.java:367)
    at sun.security.rsa.RSAPrivateCrtKeyImpl.<init>(RSAPrivateCrtKeyImpl.java:91)
    at sun.security.rsa.RSAPrivateCrtKeyImpl.newKey(RSAPrivateCrtKeyImpl.java:75)
    at sun.security.rsa.RSAKeyFactory.generatePrivate(RSAKeyFactory.java:316)
    at sun.security.rsa.RSAKeyFactory.engineGeneratePrivate(RSAKeyFactory.java:213)
    ... 3 more

If you have a public key in this form (and not within a certificate), I'd recommend using BouncyCastle's PEMReader. Its readObject() method can read a lot for formats: public keys, certificates, private keys (although you may need to use the method with a password)...

If you don't want to use BouncyCastle, you can read certificates using a CertificateFactory (see examples). With a certificate in PEM format in an InputStream:

CertificateFactory cf = CertificateFactory.getInstance("X.509");
Certificate cert = cf.generateCertificate(inputStream);

For private keys, if your private key is a PKCS#8 structure in DER format, you can read it directly using PKCS8EncodedKeySpec. For example:

KeyFactory kf = KeyFactory.getInstance("RSA");
// Read privateKeyDerByteArray from DER file.
KeySpec keySpec = new PKCS8EncodedKeySpec(privateKeyDerByteArray);
PrivateKey key = kf.generatePrivate(keySpec);

You can convert your private key into PKCS#8 using openssl pkcs8 -topk8 (remember -outform DER, you may also want to check the cipher suites as not all might be commonly supported by both Java and OpenSSL).

From a keystore usage point of view:

If you don't want to do much programming for handling the keys, to go between Java and OpenSSL, it's convenient to use the PKCS#12 format.

If the keys and certs you have produced with OpenSSL are not already in a p12 container:

openssl pkcs12 -export -in cert.pem -inkey key.pem -out store.p12

In general, you can make use of the directly, using Java's "PKCS12" keystore type (instead of "JKS" by default).

If needed, you can convert this PKCS12 keystore into another format (e.g. JKS) using keytool (Java 6+):

keytool -importkeystore -srckeystore store.p12 -srcstoretype PKCS12 \
     -destkeystore store.jks -deststoretype JKS

(Essentially, the opposite operation as the one described in this question.)

Either way, whether from using PEMReader or by loading your key/cert from a KeyStore, you should be able to get instances of PrivateKey and Certificate (or PublicKey directly).

You can verify the signature of a Certificate has been done using by the private key matching a given public key using its verify(PublicKey) method.

With them, you can also use the digital signature API. It's a more general API for any document signature, and I wouldn't necessarily verify a certificate signature with it (I'd rather use the certification path API for this, since it will also build the chain).


How to use FDE without needing to share the encryption password We have an AI model which needs to be deployed on premise. The hardware will be provided by us, so we can do what ever we want on the device. The device is a mini PC running Ubuntu 18.04.

The UI is launched in kiosk mode so only our program will be running. The user should be able to start the machine, provide the username+password to login and the software will start automatically.

This device should be locked down. I.e. we need to:

Encrypt the hard-disk so that nobody can take the hard disk and copy the files by plugging into a different computer.
Enable the user to login and use the application.
Store the AI model, use it in a way that user will not be able to copy it or use it with any other software than ours.

To enable this, there are some issues that I found out. For user to use the system, we need to share the encryption password. Hence he will always be able to plug the hard disk to any other system and use it (or copy the model).

How can I overcome this issue?

It comes to this: You want to implement a DRM scheme. Many before you have tried, all of them failed. It is not possible to give something (hardware, data) to users and prevent them from using it in an unintended way or copy it. You can make it harder, but you cannot prevent it. Others with more resources than you have tried (e.g. Sony, Microsoft, Nintendo to prevent pirating of console games) and in the end it all was broken.


Is a good idea to have security logs stored in the cloud? I was discussing with my friend the topic of the importance of log analytics/correlation and real-time response for an organization. Then, he mentioned that some people consider sending logs (collected from a network: IDS, firewall) to the cloud for storage purposes. Is this good idea? What are the problem/issue he should solve ?

All I could think of is the following

Trust issues security: He is sending sensitive data to the cloud, will he trust a service cloud provider with this information? Is encryption really enough?
Real-time response to security incidents: If an organization sends data to the cloud, will that affect its response in real time? Especially, if he needed to perform some operations in the cloud before sending the logs for analytics.

Is it a good decision to do? Did I mention all the problems he should solve if he determined on that decision?

As usual: threat-risk-mitigation.

Sending security logs from a highly secured zone to a less secured one can be harmful if the content of the security logs can help attackers to better know the security practices hence the way to circumvent them - which is a common use case for security logs.

But being in the cloud in not the only determinant for a security zone. Furthermore, if the application platform is already in the cloud, the question can be quite different.

So IMHO the only questions are: what is the security level at the place where the logs are produced, what is the reason for that level, and what is the security level of the place where the logs will be transfered. In there is a strong decrease in security level and a risk analysis had concluded that the current security level was required it is a bad idea. If the cloud storage is compatible with the global security requirements, I can not see any problem.


Cookie domain security Recently, I started diving into cookies, but as far as the domain property concerned I don't experience it as too be that straightforward. I've read this article:

http://web.archive.org/web/20200418163316/https://www.mxsasha.eu/blog/2014/03/04/definitive-guide-to-cookie-domains/

It points out the recommendation to keep your cookies safe by hosting your websites with a www-prefix, so www.example.com instead of example.com, as in the latter case, IE explorer (or any browser?) will also send the cookies to any (perhaps malicious) subdomain of example.com. But don't you own all the subdomains of a given domain you bought? Why can somebody else own a subdomain under your parent domain in the first place? Aren't you then just setting a cookie for a subdomain someone else owns? That doesn't make sense, does it?

So it is recommended to avoid having untrusted domains under your domain. She also says this is why GitHub pages is hosted under github.io, not github.com, for example. I don't understand why .io would be more secure than .com?

I've learnt that you can always set a cookie for a less specific domain, e.g. bad.example.com can set a cookie for .example.com but not the other way around. What is the ideology behind this from a security perspective? Is this not just dangerous behavior, because a sub domain (which apparently may be owned by someone else?) then can set cookies for all other sub domains of example.com and the parent domain itself. So a user from malicious.example.com gets granted also access to example.com.

When you set a domain value of .example.com, the cookie will be sent to all sub-domains. Does this have anything to do with having the feature of a shared authentication/authorization mechanism that applies to all applications hosted under several subdomains (e.g. dashboard.example.com and admin.example.com) but related to the parent domain/app?

Maybe I'm on the wrong track, but I don't quite understand the WHY behind the specifications.

Thanks in advance,

Mike

But don't you own all the subdomains of a given domain you bought?

Sure. If you own the domain you control also subdomains. If you have control over applications that use your subdomains, then you can do whatever you want.

But there are hosting providers, that give users subdomains like user-123.provider.com below their own domain. In particular, users don't have to pay explicitly for domain registration. If you as a customer have such subdomain and bind your cookie to a higher level domain name, it can be read and modified by other customers that use this top level domain. To avoid that, you should use more specific domain name.

When you are a provider and need a "root" domain name for your own purposes (advertising, price info, faq, etc.), then again if you bind cookies to the domain name provider.com (I don't discuss here differences between .provider.com and provider.com), all your customers like user-123.provider.com can read and modify your cookies. To avoid this, you should use a more specific domain name like www.provider.com.

  Does this have anything to do with having the feature of a shared
  authentication/authorization mechanism ... ?

Not necessarily. But it can be used for authentication and single-sing-on.

In such case normally all subdomains are controlled by the same owner (company) and different subdomains can be bound to different applications. There is normally a filter that checks if authentication cookie is present. If not present, user is forwarded to the authentication page. When cookie is present, the application at particular subdomain considers user as authenticated. When user navigates to some other subdomain (and thus to other application), the other application will also consider the user as authenticated. Such single-sing-on provides good user experience.


Is it secure to execute MySQL queries on a client device? I am building a project that requires users to be authenticated to access it. I was planning on using MySQL as a database and running PHP scripts on the client to fetch user data. E.g. SELECT * from uaccounts WHERE username = 'bob'. And then storing the rest of the info if the user authenticates in a session. Is it secure to execute SQL queries on a client or should I look into something like Firebase or build an API or look at another external API for storing and querying user data (and other SQL queries). Is running SQL on the client open to interception by attackers or is it secure as long as it is done properly?

SELECT * from uaccounts WHERE username = 'bob

Assuming Bob is only supposed to see the record for Bob then no it is not secure. Bob can pull out the connection parameters from the application and run whatever query he feels like.

Database security is in every implementation I've seen done at the table level. I.e even if you give Bob his own user account for the database he's still going to need select permission on the uaccounts table meaning he can run "SELECT * FROM uaccounts".

The only way to make this secure is to instead of giving Bob select permission on the table create parameterless stored procedures (which Bob would need execute permissions for) that use the logged in user name. And this is usually far more effort than its worth and far too easy to screw up. Not to mention it doesn't really scale. Facebook would not want a separate database username for every user of the site...


Injecting ampersand to the url Let's say there is a program sending some data to server via GET:

http://server.com/gateway?value1=abc&value3=def

Then the server sends these values further, adding value2: (python code)

SECURED_VALUE = "safe"
"http://externalAPI.com/?value1={0}&value2={1}&value3={2}".format ( get['value1'], SECURED_VALUE, get['value2'] )

And my point is, can I inject another attribute to the latter request in a way like:

http://server.com/gateway?value1=abc&&value2=hacked&value3=def&&value2=hacked

so then the server --> API request looks like:

http://externalAPI.com/?value1=abc&value2=hacked&value2=safe&value3=def&value2=hacked

The external API most probably will read only the last or first occurrence of the repeated key.

So I have two questions, main, if such hack is possible and one should protect his apps against it. Secondary, how to actually do that, not only by GET method, but maybe by POST, or by modifying a JSON encoded string. Decoding JSON with an ampersand or semicolon gives me an error, putting ampersand to POST method behaves same as in GET method.

I ask this, because I found some security issue and I'm currently writing an example of a successful hacking attempt in case a server developer doesn't strip out ampersands and other risky characters. I don't want to turn out to be a stupid guy who doesn't know such injection can't be performed and is only wasting time of admins, so I thought I'll ask You first.

Third, mini-question, do you know of any good sources of wisdom how to protect yourself from injection (what functions to use for that) in Google App Engine, python, webapp2 framework?

Overview. Yes.  You are right.  Very good catch to have noticed this.

Details. This is basically an instance of a HTTP Parameter Pollution vulnerability.  This is basically an injection vulnerability (analogous to XSS, except that it is injection into HTTP parameters rather than injection into HTML).

Defenses. To defend against this, I suggest you do two things:

Sanitize the parameter values.  Build a whitelist of characters that are expected to appear in your queries and that are also known to be safe in this context (make sure it does not include &, ?, =, #, %), and strip everything in the parameter value that is not in the whitelist.
URL encode the parameter values before interpolating them into the new query.

Related research.  See also the following research paper:

Automated Discovery of Parameter Pollution Vulnerabilities inWeb Applications.  Marco Balduzzi, Carmen Torrano Gimenez, Davide Balzarotti, and Engin Kirda.  NDSS 2011.  (summary)


Multiple CSRs from the same private key Consider that I generate a new undisclosed private key using openssl:

openssl genrsa -out personal.key 2048

I then generate the multiple CSR requests (called csr1.csr and csr2.csr):

openssl req -new -sha256 -key personal.key -out csr1.csr
openssl req -new -sha256 -key personal.key -out csr2.csr

(Both CSRs are generated with the same set of fields.)

The .csr files are given to different parties, and csr1.csr is compromised by a third party.

As I understand that CSR contains only the public key, so I'd like to ask how secure and trusted are csr2.csr and personal.key now (in terms of remaining in use, and keeping them for future use)?

Should csr2.csr and/or personal.key be discarded if csr1.csr is compromised? If so, why is that?

As per this answer CSR with only public key with openssl

The CSR only contains your public key, not your private key, so your private key has not been compromised.

The .csr files will both still be valid no matter what.

When you send the CSR to a Certificate Authority, they will produce a signed x509 Certificate. Any computer that trusts the CA will then consider that certificate valid.

If the CA is the third party that is compromised, then it is likely that the signed certificate is useless as nobody will trust it.

If a man-in-the-middle captures the csr it does them little good, as the only key available is your public key.


Which cipher suites with AES cipher provide forward secrecy? Does standard AES with RSA (reported by Opera as TLS v1.0 256 bit AES (1024 bit RSA/SHA)) provide perfect forward secrecy?

Which SSL3.0 and TLS1.0 ciphers do provide forward secrecy?

Which ciphers in openssl provide forward secrecy and are regarded as secure?

Cipher suites which provide perfect forward secrecy are those which use a Diffie-Hellman key exchanged, signed by the server -- but the server key may be of type RSA. Consider the TLS standard: there are two cipher suites which use AES with a 256-bit key, SHA-1 for integrity check, and a RSA server key:

TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA

Only the latter provides perfect forward secrecy. In the former, the key exchange is done by encrypting a random value with the RSA server keys, something which can be unraveled later on by an attacker who could steal a copy of the server private key.

Information provided by Opera does not seem to be sufficient to distinguish between those two cipher suites.


Secure mobile SD card with a PIN/code Is there a way to set a PIN on your SD card so that in case mobile is lost or stolen, the contents of SD card like photos, docs etc. cannot be seen by anyone else? I am asking for SIM card PIN protection like functionality. On mobiles you can set a PIN lock on your SIM so that if you restart your mobile or use that SIM on another phone you have to provide that PIN to use the SIM again. But these days using SD card as secondary memory is widespread and lots of personal data is stored on them so it will be helpful if there is PIN protect like facility. So please tell me if its possible on any mobile or any app. The app should make SD card unusable without formatting everything on it.

I am asking for an app or inbuilt functionality on both Android and Windows mobile phones.

There is nothing built into the SD card - its basically dumb storage.

What you can do is encrypt files on the device - either individually or the entire filesystem. Modern android supports this natively - under "Security" or "Lock screen & security" etc (depending on manufacturer) look for the encryption section. This works well when the SD card is used as an extension of the built in storage. If you wish to use the card to transfer data you will likely struggle - this answer suggests it isn't possible with standard tools.

As far as I am aware Windows phone does not offer a similar feature. I'm sure there would be some applications which supported encrypting files on the filesystem - but this wouldn't play well with other apps accessing them.


Is it possible to know the key if we have the original value and the hash using HmacSHA1? I was wondering if it were possible to know the key if you already know the original value and the hashed result.

For example, let's say :

`$value` = helloworld
`$hmac_key` = 0123456789
`$result` = 6adfb183a4a2c94a2f92dab5ade762a47889a5a1

With only $value and $result, is it possible to retrieve $hmac_key ?

In simple basic math, it's quite obvious, but with HmacSHA1, is it also possible?

It is not possible to recover the key ... assuming the key has sufficient entropy.

Here's what the attacker can do.  If the attacker has a guess at the key, the attacker can check whether his guess is correct.  This means that if the attacker can narrow down the list of possibilities for the key to a short enough list, the attacker can simply try all possibilities in that list and see which one is correct, and the attacker will eventually discover the correct value of the key.  This attack strategy is known as brute-force search, or exhaustive keysearch.  It turns out that this is essentially the only attack an attacker can do; with SHA1-HMAC, an attacker can't do any better than this attack strategy.

So, your job as defender is to make sure that the number of possibilities for the key is large enough that brute-force search will be unsuccessful.  Ideally, there would be at least 2128 possibilities for the key, all equally likely.  For instance, you might generate the key by reading 128 bits from /dev/urandom.  If that is how you select the key, then there will be no way for an attacker to recover the key.

On the other hand, if you do a lousy job as defender of picking the key, then it might be possible for an attacker to recover the key.  For instance, suppose you decide your key will be a random 4-digit number.  Well, then there are only 10,000 possibilities for the key, so an attacker can try them all and identify which one is correct.  The trial-and-error process will take only milliseconds -- so if that's how you picked your key, things would be totally insecure, and the attacker would be able to recover the key.  If you pick a random 10-digit number as your key, then there are 1010 possible values of the key, which is still not enough: an attacker could try all of those possible value in mere hours.  So, don't do that.  Or, if you use someone's telephone number or SSN as the key, then again it will be possible for an attacker to recover the key (simply by trying all possibilities).  So, don't do that, either.

In short: choose your key using 128 bits of crypto-strength randomness.  Then, it will not be possible for an attacker to recover the key.


How to prevent mobile data from being viewed when leaving VPN server? Please correct me if i'm wrong. As far as i know, when we use vpn service, our datas are only encrypted from us to vpn server. After leaving the server to intended recipient, our data is decrypted and interceptable by any party who is spying us.
How to prevent our data from being intercepted or viewed until it reaches the destination? Does using Signal messaging app make our data encrypted from point to point?
Thanks.

Please correct me if i'm wrong. As far as i know, when we use vpn service, our datas are only encrypted from us to vpn server. After leaving the server to intended recipient, our data is decrypted and interceptable by any party who is spying us.

Yes. This is essentially correct. A notable example would be an embassy which used tor - and the person running the tor exit node snooping on the traffic.
Note that the example is old - from 2006-2007. At that time clear text protocols was the norm, and only banks and similar sites bothered with https.
Today, the norm is https and encrypted protocols for almost everything. Even news websites uses https. Heck, my personal blog uses https - because it's essentially free. Let's encrypt was a major driver here, as they made certificates free for all.

How to prevent our data from being intercepted or viewed until it reaches the destination? Does using Signal messaging app make our data encrypted from point to point?

Signal is one example of end to end encrypted protocol, where data is unreadable by anyone in transit. The provider or anyone in the path is unable to read the messages.
With for instance Facebook's Messenger service, the data is encrypted between you and the server, and between the server and other clients, so a VPN server or tor exit node can't read your data - but Facebook can.
End to end-encryption means that the data is unreadable to anyone in transit. With e-mail this may be achieved with PGP or S/Mime. Otherwise, e-mails will at most be encrypted between user and servers, but readable in clear on the e-mail provider servers.


Using a https Website will my ISP see to which IP i am connecting? If i am visiting a https Website will my ISP see the IP i am connecting to, or is the destination IP adress somehow hidden because i am using ssl?

tl;dr: Yes. You need to use a proxy or VPN to hide the destination of your traffic forom your ISP.

The Long Version:
As described in this section of the IPv4 Wikipedia article, IP packets have a header section and a data section. The header section contains, among other things, the Source IP Address and Destination IP Address fields. These fields are essential to facilitating the communication between the source and destination, so encrypting them would make it impossible for the source and destination machines to communicate. SSL only encrypts the contents of the data section, though not the entire contents -- there are a few more layers of protocol headers before you get to SSL (see the OSI model for more on that).

That said, the source and destination IP addresses in an IP packet may not be the final destinations on either side of the underlying communication. The data section of the IP packet can contain another IP packet (or a different protocol) to be unwrapped, interpreted, and transmitted by the recipient in accordance with a VPN or other proxy solution.

To hide the IP of a site you are visiting, regardless of the presence of HTTPS, you would need to use a VPN, proxy, or other anonymity service (such as tor) to make the connection.


removing SSLv3 does not seem to fix POODLE problem I have removed SSLv3 from my Apache 2.2.15 ssl.conf file with the line

SSLProtocol All -SSLv2 -SSLv3

I have restarted httpd but POODLE tests still show vulnerability exists with POODLE.
What else could be the issue? Thanks

You must first look at all configuration files if SSLv3 is enabled on some vhost:

grep -i -r "SSLProtocol" /etc/apache

Take the list of files grep found, and edit the configuration as bellow:

SSLEngine on
SSLProtocol TLSv1
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH

Restart Apache afterwards and it must work.


sensitive assets identified and properly protected I am going through the IASME cyber essentials questionnaire and one of the questions is

  are all sensitive assets identified (eg protective marking) and properly protected?

I have googled protective marking which refers to the governments level of classification (Top secret, secret etc).

My question is would small businesses use these same classifications or would they simply just state that something is confidential? also, are there other ways to identify sensitive assets?

Sorry if this question is very basic, I am just a little confused on this question. Thank you for any help in advance.

The government uses C, S, and TS as the general material level restriction, but to think that's all they use would be a gross over simplification. Other things in play are "Need to Know" policies -- basically, just because you have TS clearance doesn't mean you get to access everything marked TS. There are far too many to list here, but basically it means that you end up with a greater level of complexity than a simple three marking system.

As for small businesses, classify information based on potential damage if released to the public. Would the firm be embarrassed? Would their competitors gain insight into how they run their company? Is it a secret formula that is behind the entire company? You must also consider legal repercussions from releasing protected information (medical records, etc).

So, the answer your question: companies usually must have at least a confidential level to protect employee information. There is nothing to stop a company that feels it needs additional categories from making them. In every day life however, most firms forgo the "C/S/TS" idea and just use compartments of information.

For example, Apple may not classify their employees in levels of trust (they may, I have no idea), but they certainly compartmentalize project information to only the needed departments.

Think of the government's method on one end of the spectrum and a mafia's "web of trust" on the other. There is more than one way to skin a cat. A company is going to pick the one with the "hopefully" best risk-to-reward.


Security and the Definition of Ready and Done Currently I am in a project where I have to test REST APIs among other things. In another question of mine I also discussed the topics Definition of Ready and Definition of Done regarding security.
Since I am planning a new staging environment for Dev - Test -Stage -Production, the whitebox penetration test topic is always up to date. But also, unfortunately, I have not paid attention to the adaptation of the definition of Ready and Done with regard to security aspects.
Especially in the area of RESTAPI development there are several guidelines that should be observed. Whether now already from the planning out, above evenly on the developer level.

But only several questions that build on each other:

How do I plan the definition of Ready and Done so that the security
relevant rules are adhered to?
How do the security rules behave within an agile process?
How do I evaluate the security policies within the agile process?
Where exactly within my agile planning do I apply the security
aspect?
Is static code analysis sufficient in the development environment?
Even before I plan something, I start with the design to secure it.
But how do I evaluate these safeguards?

How do I plan the definition of Ready and Done so that the security relevant rules are adhered to?

It's really hard to give a specific answer to this, because each company is a little bit different, but here are some really good tips on what and what not to use:
https://www.owasp.org/images/7/76/Jim_Manico_(Hamburg)_-_Securiing_the_SDLC.pdf

How do the security rules behave within an agile process?
How do I evaluate the security policies within the agile process?
Where exactly within my agile planning do I apply the security aspect?

It's a never ending process, ideally you would put the tests in your CI/CD pipeline, but where exactly to put them and how to evaluate them, is very dependent on what are your current processes in development.
You should put in work towards an SDLC (Software Development Lifecycle) plan, which would give you a good insight in where to put the security controls and than create a SSDLC (Secure Software Development Lifecycle) plan on where they are implemented, so that there is a clear guideline on how the security takes place.

Is static code analysis sufficient in the development environment?

The best path is to have static code analysis, dynamic tests on a running instance (SQLi, XSS, etc.) and to check dependencies for potential vulnerabilities. Where to fit each of these tests is really up to your CI/CD pipeline.

Even before I plan something, I start with the design to secure it. But how do I evaluate these safeguards?

The best way to evaluate them is by doing external audits and penetration tests. You can also do these parts internally, but it should be someone who is not associated with the product you are creating, for they could be bias in the evaluation.


Are SSL encrypted communications through a company network safe? If I'm using Skype, Facebook, or another type of communication at my work, can the network administrator see my Skype and Facebook conversations, although its encrypted with SSL?

I found this text:

  If your company is serious about security then it may have installed a
  more advanced proxy like Blue Coat's ProxySG. Such systems perform a
  Man-in-the-Middle attack by dynamically generating a fake certificate
  for the target server. This gives them access to the complete data, as
  if there was no SSL.

If I installed my own computer from scratch, is the method above still possible? Is there a way to protect myself from it?

Is there any way to see that my connection to my bank or Facebook is truly protected by SSL and that I'm using the correct certificate?

If you have full control over your computer it should be easy to detect SSL interception, because the browser will complain about unknown issuer if you access https-Sites. At least if the firewall administrators did not get an intermediate CA from a trusted CA (see https://lwn.net/Articles/480279/). And even these you will be able to spot if you use Google Chrome with certificate pinning and they did not make exceptions for interception for the google.com domains (see http://www.cso.com.au/article/533843/french_treasury_accidentally_signs_ssl_certificate_google_com_domains/).
And, if you have a specific sensitive website you can look at the certificate fingerprint and trust path in the browser and compare it with the results you get from home.

Working around is harder, because usually these firewall rules are installed to protect the company from malware via SSL connections or from data leakage from internal users to external sites (cloud etc). So these rules are usually not primary there to annoy users, blocking these sites would be much easier. So if the admin has properly set up the firewall there should be no way around by using VPN, proxies or whatever. Of course, mostly there is a way, but this depends on the specific firewall setup (or just use mobile network).

BTW, if Skype still works in this setup it is probably safe to use (if you trust Microsoft). Skype does not use SSL, but when tunneling over HTTP proxies it uses a protocol which looks similar enough to fool some deep inspection firewalls.


HSTS Policy being enforced *sometimes* I've implemented an HSTS policy for our site. I have the header being served on our main domain and it's sent on the very first response  that serves the 304 Redirect from the server. (According to this article the header must be on this response.). We have includeSubDomains directive on as well as preload and have preloaded our site. It is listed on the chromium json config file.

The problem is sometimes the policy is being enforced for subdomains, and sometime it is not, and I can't figure out why.

Here what an initial GET request and response from our domain looks like (I've replaced our domain name with REDACTED):

REQUEST

GET http://www.REDACTED.com/ HTTP/1.1
Host: www.REDACTED.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: user_segment=Prospect; _ga=GA1.2.992855402.1446138879; ASPSESSIONIDCQBCRBQD=EIAMMLLAAHBGBIPLEDPCPEFF

RESPONSE

HTTP/1.1 302 Object moved
Cache-Control: private
Content-Length: 149
Content-Type: text/html; Charset=utf-8
Expires: Wed, 28 Oct 2015 17:31:02 GMT
Location: https://www1.REDACTED.com/
Server: Microsoft-IIS/8.0
Set-Cookie: ASPSESSIONIDSQBTRCQC=MGIFCOMALHAFEDECCCMECFKB; path=/
X-Powered-By: ASP.NET
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Date: Thu, 29 Oct 2015 17:32:01 GMT

<title>Object moved</title>

Object Moved
This object may be found here.

I know HSTS works by having the browser cache the policy, but it just seems arbitrary when the UA's (Chrome/Firefox) decide to actually enforce it. Sometimes its being enforced, and others not at all even after I've visited the main domain to "refresh" the policy.

Source: RFC 6797.

The HSTS header is only valid when it is set over HTTPS.

  An HSTS Host MUST NOT include the STS header field in HTTP responses
  conveyed over non-secure transport.

This is because agents only respond to the HSTS header when a resource is served over TLS/SSL:

  If an HTTP response , received over a secure transport, includes an    STS header field...
   [snip]
  Note the host as a Known HSTS Host

The plain HTTP response should return an HTTP 301 permanent redirect to the HTTPS resource. The HTTPS resource then contacted should set the HSTS header. You may as well set all HTTPS resources to return the header and to renew the expiry (max-age).


Is Hamachi on a Linux production server a big system vulnerability? The production server I am administrating can only be accessed through the company-network. However, if I have to do maintenance while not in the office, I can't access the server.

Could I let Hamachi run on the server and join a group? At home I join the same group and can easily access the server through SSH.

However, is this a big system vulnerability. Is it justifiable to use Hamachi for this reason?

Yes it is a security concern. That said it may be acceptable.

Installing any application, and certainly ones that allow remote access, does open up vulnerabilities and risks that otherwise may not have existed. But you may determine that the risk is worth accepting as it allows you to work remotely.

You can configure some security on Hamachi to restrict it to some extent, but you can not be sure of any vulnerabilities that may exist (now or in the future).

Only you know if the risk is acceptable, and only you know if installing this is allowed within corporate policies. You should be careful though you do not breech any policies.


Is it okay to normalize unicode passwords with NFC/NFD? I am currently designing a login for a web service. I will use a PBKDF2 implementation for hashing the passwords.

However, I intend to allow unicode for passwords, as I will have international users, which might want to use, for example, cyrillic characters. To avoid any issues with unicode ambiguity, I thought of using the NFC unicode normalization before encoding the password as utf8 and passing it on to the hash.

The question now is: Is that safe or does it introduce any unwanted ambiguity into the password validation? It is clear that "a\u0308" (a + combining diaresis) and "ä" should be the same, but does NFC fold any more differences which users could be relying on?

Edit:

I found that there is a stringprep (RFC 3454) profile called SASLprep (RFC 4013) which is appearantly used for passwords and usernames in some protocols. It specifies to use a KD normalization, which I consider a bad idea. It will fold differences like ² and 2, which are two characters commonly on keybords in the western world at least, which could be used to enrich the password entropy. Unfortunately, no rationale is given for that.

If you treat 2 and ² as the same character, you're essentially removing one character from the character set. That isn't really so bad if it increases usability, especially if that encourages longer passwords.

Say you take a 8-character password, with a drawn randomly from a set of 2000 characters. That gives log₂(2000⁸) ≈ 88 bits of entropy.  If you had a 9-character password, drawn from 1000 characters (half as many!), that's log₂(1000⁹) ≈ 90 bits of entropy. In fact:

+-----+---------------------------+
|     |    character set size     |
| len |  500 | 1000 | 2000 | 4000 |
|-----+------+------+------+------|
| 6   |  54  |  60  |  66  |  72  |
| 7   |  63  |  70  |  77  |  84  |
| 8   |  72  |  80  |  88  |  96  |
| 9   |  81  |  90  |  99  |  108 |
| 10  |  90  |  100 |  110 |  120 |
| 11  |  99  |  110 |  121 |  132 |
+---------------------------------+

As you can see, in the normal range of password lengths and Unicode character set sizes, the exact size of the character set isn't that important.