Correctly configuring load balancing for TLS session resumption Consider the following network topology:

There are exactly two HTTPS servers, S1 and S2.
There are exactly two HTTPS clients, C1 and C2. Notice this, as there are often many more clients for two servers. But in this case, there are only two clients. (You may ask why? Because C1 and C2 are also servers, serving many clients while being served by S1 and S2 as well.)
There is a load balancer between the clients and server, LB. Here, LB performs load balancing in a round-robin fashion at transport layer (TCP). Therefore, LB does not perform SSL-offloading or anything related to application layer.
The clients request something like https://example.com. The DNS resolves example.com to the IP address of LB, which in turn forwards the packet to either S1 or S2.
LB is configured to route packets in one TCP session (same src port, src address, dest port, dest address) to either S1 or S2, not both. Therefore, S1 and S2 need not be aware of the session information on the other server.
For performance reasons, S1 and S2 can be configured to use TLS session resumption based on either session IDs or session tickets.

The following scenario shows the problem:

C1 connects to https://example.com, and LB sends its traffic to S1. A TLS session is established (full handshake), with sessionID = 123456. After a while, C1 closes the connection.
Some time passes, and C1 connects to https://example.com again. This time, LB sends its traffic to S2. C1 offers to use sessionID = 123456, but S2 does not know this sessionID. So, S2 asks to set sessionID to something different, say sessionID = 789abc (full handshake). After a while, C1 closes the connection.
Some time passes, and C1 connects to https://example.com yet another time. This time, LB sends its traffic to S1, which does not know sessionID = 789abc. You get the idea:  another full handshake occurs.

So, as a client goes back-and-forth between the servers, a full handshake occurs every time, and the performance is impacted.

  What is the correct way to handle this scenario, so that the clients do not perform a full handshake in every new connection?

PS: If I had many clients, I'd configure LB to stick one client to one server for some amount of time. However, since there are only two clients, that would impact performance as well.

Edit: The link I cited above explains this, which I don't fully understand:

  In practice, deploying session tickets across a set of load-balanced servers also requires some careful thinking and systems architecture: all servers must be initialized with the same session key, and an additional mechanism is required to periodically and securely rotate the shared key across all servers.

That's exactly what session tickets are for. While session ids are only some kind of reference which "point" to the session information stored on the server, session tickets contain all what is needed inside the session ticket, including the key material. Nothing is stored on the server side for the session.

Of course it would be a bad idea to have these information in plain text because than an attacker could just take the session ticket to extract the keys and decrypt the traffic. Therefore the session tickets are somehow protected - the details depend on the actual implementation. Usually this means they are encrypted with some server side secret and protected against manipulation with some MAC or HMAC. And as long as all servers share the same implementation and encryption key they can deal with the tickets issued by another server.

Given that session tickets include all key material it is essential that they are properly protected. If the servers are using the same encryption key for the tickets all the time it is sufficient for an attacker to attack one of these servers, get the encryption key and then use this to decrypt all previously sniffed session tickets and thus all previously sniffed traffic. The best way is therefore to regularly rotate the secrets in order to limit exposure of such critical information.

Given that a session ticket can store arbitrary information it can also store an ID for the encryption secret which makes it possible to use a new encryption key but being able to handle tickets protected by the old key for a while. Whenever such an old ticket gets received it can be decrypted if the old key is still known and then a new ticket protected by the new key can be issued.

Note that this mainly describes session tickets up to and including TLS 1.2. With TLS 1.3 the session handling mechanism was reworked. For more information see Botching Forward Secrecy - The sad state of server-side TLS Session Resumption implementations and The Future of Session Resumption - Forward secure PSK key agreement in TLS 1.3.


How to choose a password that I have to remember for a long time but do not use a lot I have a scenario where I have to remember a password / keyphrase, which I will not be able to recover if I forget it, for a long time (probably more than 10 years). The problem is because this password is part of a disaster recovery strategy I will hopefully not need it very often.

Are there any techniques or methods to choose a good password for this situation and to keep it in my mind?

Likely the best option in this kind of scenario is to record the password/passphrase in a physically secure location (e.g. bank vault, safe deposit box).

Relying on human memory to record this kind of information for 10+ years is an extremely bad idea.  For example the person who knows the passphrase leaves the comapny/gets hit by a bus/forgets it.

Writing it down and storing it in (preferably 2+) secure location avoids this kind of issue.


Privilige escalation with CreateNamedPipe and Impersonation for Windows Server 2012 While working with window based application came to know that local privilege escalation is possible when we use CreateNamedPipe method with Impersonation. This vulnerability was reported in Windows Server 2000 and Windows Server 2008.

In the same fashion is privilege escalation possible with Windows Server 2012? Please let me know the vulnerability reported on the same line is possible with CreateNamedPipe method and Impersonation - bulletin: Microsoft Security Bulletin MS15-050 - Important.

If the vulnerability mentioned in above bulletin does not work with CreateNamedPipe, then is there other vulnerability which causes privilege escalation after use of CreateNamedPipe method? Why I am asking this question is because in the Microsoft's blog they mentioned the patch for related vulnerability only but never confirmed that whether same patch will be applicable to other flavors of Windows developed afterwards.

MS15-050 (CVE-2015-1702) and other vulnerabilities against tokens on the Windows Server 2012 platform do not appear to leverage the CreateNamedPipe method.

You can see a binary diff and vulnerability analysis of CVE-2015-1702 by Alex Ionescu in his blog entitled, Analyzing MS15-050 With Diaphora. There is also a Nessus plugin to test for the existence of MS15-050 available -- here -- but the scanner likely only checks the patch level.

You could always get the exploit code for CVE-2010-2554 (but not CVE-2010-2555, the other half of MS10-059) via Exploit-DB, CORE IMPACT, or CANVAS and then compare that code to Alex Ionescu's analysis, or the further work done on similar token impersonation privilege-escalation bugs by Google Project Zero (such as their work on CVE-2015-0002 that led to the development of the popular metasploit-framework exploit/windows/local/ntapphelpcachecontrol module). P0 even produced a nice set of tools to check for these sorts of things in sandboxes.


Is it a bad idea to add random characters to user ID and password? I've heard people say again and again that you shouldn't implement your own security algorithm, and I'd like to ask you if I'm breaking this rule.

I'm creating a traditional client-server application with a twist: I want to encrypt all data on the client so that even an attacker who gains complete control over my server will be unable to access the users' data. That is, I want end-to-end encryption for my client-server application.

The client encrypts the user's data with a cryptographic key derived from the user's password, so it's important that the server not be able to figure out the password because that would allow the server to decrypt the user's data. The client therefore uses Secure Remote Password protocol to avoid sending the password to the server. So far so good.

Now here's where my design gets a little unorthodox. The problem is that users in general are very bad at creating passwords - usually picking a password from the top 10,000 passwords list - which would make it pretty easy for an attacker who has access to the server to decrypt the user's data. Therefore I plan to generate a random set of characters and append them to the User ID field, so the user would need to log in with something like these credentials:

User ID: John-CPE4E38J
Password: snoopy

But before processing these credentials the login code moves the random characters to the password so the underlying SRP authentication library sees this:

User ID: John
Password: snoopy-CPE4E38J

In addition, the client offers to remember the User ID (ie. John-CPE4E38J) so that most of the time the user only has to remember their password.

What do you think of this approach? Am I breaking the do-not-implement-your-own-security-algorithm rule? Or is this a good way to strengthen the security of my application?

Yes: you're re-writing security here. There are already several password derivation functions that are known to work, the most well-known one being PBKDF2. Use that instead of your custom scheme.

What you're trying to do is, in essence, salt the password (with a short salt) and store the salt value in the user name. It's not really much of an improvement.

Something else you might want to rethink: with your system, the encryption key is directly derived from the user's password. This means that not only can an attacker attempt to decrypt the user data by attempting to use known password lists (even if using a password-based key derivation function makes it harder) but you also effectively prevent the user from ever changing his password (otherwise, you need to re-encrypt all the user's data).

Without knowing more about your requirement and environment, it's hard to suggest the best way to proceed but, from what you describe, I'm sure that this can be greatly improved. I suggest, therefore, that you hire a specialist to help you find a proper solution in this case.


Does WhatsApp "end-to-end" encryption protect against a compromised router? So today when I connected to my WiFi it got a note "Your WiFi is being controlled" which made me paranoid that maybe my router is hacked or something. I have yet to convince my father about this, or maybe is the one trying to spy on me.

Are the chats on WhatsApp safe from being spied upon, even if the router is compromised?

What you describe as your wifi in being controlled let fear a Man In The Middle attack. The encryption of Whatsapp message is more than enough to be protected from that. Someone just eavesdropping what is exchange over the Wifi network will only see encrypted messages and will not have access to the actual content.
Now if your question does using Whatsapp guarantee that nobody else but the recipient will ever see the messages, the answer is quite different. The protocol used by Whatsapp is indeed secure, but it looks like the implementation willingy choosed ease of use over security. It has been discussed at Whatsapp security, and a comment gave a link to the Guardian explaining that

A security vulnerability that can be used to allow Facebook and others to intercept and read encrypted messages has been found within its WhatsApp messaging service...
However, WhatsApp has the ability to force the generation of new encryption keys for offline users, unbeknown to the sender and recipient of the messages, and to make the sender re-encrypt messages with new keys and send them again for any messages that have not been marked as delivered.
The recipient is not made aware of this change in encryption, while the sender is only notified if they have opted-in to encryption warnings in settings, and only after the messages have been re-sent. This re-encryption and rebroadcasting of previously undelivered messages effectively allows WhatsApp to intercept and read some users’ messages.
[Whatsapp justifies that to cope when] a contact’s security code has changed. We know the most common reasons this happens are because someone has switched phones or reinstalled WhatsApp. This is because in many parts of the world, people frequently change devices and Sim cards. In these situations, we want to make sure people’s messages are delivered, not lost in transit.

So Whatsapp main design is useability and not security. Full stop. For most usages it is fine, but if you really need a high Confidentiality level, choose a tool dedicated to security like PGP or S/MIME encrypted mail. Not as sexy but far more secure.


How do I protect the Azure Client ID and Client Secret in HashiCorp Vaults with AKV Auto-Unseal? Say I set up a HashiCorp Vault, on dedicated hardware, with an AKV seal stanza like the following:

seal "azurekeyvault" {
  tenant_id      = "46646709-b63e-4747-be42-516edeaf1e14"
  client_id      = "03dc33fc-16d9-4b77-8152-3ec568f8af6e"
  client_secret  = "DUJDS3..."
  vault_name     = "hc-vault"
  key_name       = "vault_key"
}

I'm putting privileged Azure information in plaintext configuration parameters in the HashiCorp Vault configuration file (/etc/vault.d/vault.hcl).

For Linux OS nodes on dedicated hardware, that are not deployed in Azure, how do I reduce or ameliorate this specific source of vulnerability?

Reading your post, I think I understand your ask. You've already taken a great step of securing your credentials within a vault, but now you're concerned that the API credentials that allow you to secure your vault may be at risk since they are stored in clear text within a configuration file. The reality is that you will never likely get a solution that really eliminates some single point of failure that needs to be protected. The best you can do in situations like this is make it difficult for the attacker and go from there.

So the vulnerability that you are trying to manage assumes the following.

Your attacker has direct access to your file system
Your attacker has credentials to change file permissions
Your attacker is smart enough to know about Hashi Vault
Your attacker wants your credentials

The first assumption is probably the first major flag that you should notice in a secure environment. If someone is accessing your server files, that's a pretty major issue that needs to be looked at. There are also many ways you can control what people see through CHMOD, CHROOT, etc.

Now, the second assumption takes the first and says they not only have access to the server, but they have root/sudo priveleges. This is a major step of compromise and it means any native tools you could build into the server can be overwritten or reverse engineered. At this point you can't remediate the vulnerability because you've really lost the keys to your house already.

Steps three and four, once assumption two are complete are fairly straight forward. They can start to write application and API calls to glean credentials and harvest what they need. But, what's more likely is they'll go after any data they can fetch and then move onto their next target.

So, is it a potential vulnerability. Yes. Is it the highest priority vulnerability? No. Configure the best you can to the community best practices and keep your system safe from attackers and you should be golden. This is a last defense type vulnerability that's more like sending one or two guys in front of the hordes of Mordor and not having the hope of Frodo and Sam coming to save the day. It's pretty dismal.


Purpose of two-way encryption of JWE If we look at encryption format and standards of JWE following RFC-7516, we can see that it uses a 2 way encryption method.
So what are the benefits of this compared to just using RSA? Are computation (decryption) time not significantly affected?

JWT supports RSA encryption
I'm not familiar with the term "2 way encryption", but I assume you mean symmetric encryption (AES).
The JWE spec does support RSA encryption, it's just not that commonly-used, for reasons I'll describe below.
From RFC 7516 that you linked to -- section 3.3 Example JWE

The Content Encryption Key is encrypted to the recipient using the
RSAES-OAEP [RFC3447] algorithm to produce the JWE Encrypted Key.

And if you click through to RFC 7518 which defines the list of crypto algorithms supported by JWE, you see that there are two RSA-based encryption methods available for JWE:

4.2.  Key Encryption with RSAES-PKCS1-v1_5
4.3.  Key Encryption with RSAES OAEP

Why do you never see JWEs with RSA encryption?
RSA can only encrypt messages up to (roughly) the size of the RSA key. For example RSA 2048 can encrypt up to about 2048 bits (256 bytes, actually a bit less depending on padding scheme). JWTs are often longer than 256 bytes. So when you say "encrypting with RSA" what you usually mean is a hybrid mode where you encrypt the content with AES and then encrypt the AES key with RSA. The reason to add the extra RSA layer around AES is where you want to encrypt for a different person; for example Alice wants to encrypt a message for Bob, but Alice does not know Bob's private key.
In all of the webapps that I've seen where the contents of the JWT are sensitive and need to be encrypted, the server that creates the JWT is also the one that consumes it. Basically, the server is asking the user to hold on to the JWE and hand it back later. In this case you can just use AES without the extra RSA layer because you are encrypting for yourself. As mentioned above, if you have a case where the server generating the JWT is different from the one consuming it, and the contents are sensitive and need to be encrypted, the JWE spec does support RSA-based encryption.


Regarding Windows password and Chrome's 'Remember password' Feature Google Chrome browser helps in password management by prompting users to remember their passwords for the websites. These saved passwords can be accessed from the browsers "settings" menu, and to do so Chrome asks user for the Windows password. I understand this is for providing more security.

I read somewhere that the Windows password is hashed using NTLM hash. In order to view the saved passwords in Chrome, I have to provide my Windows password, which is fine. I believe that Chrome must be encrypting the saved passwords using my Windows password.

Now the question is how Chrome automatically fills the web page with the saved password without prompting me for the Windows password.
How does Chrome decrypt the saved password for the website? This is really confusing.

Is my Windows password not hashed and Chrome has access to it for decrypting the saved passwords? Or does Chrome save passwords in plain without any encryption?

On Windows, your Chrome saved passwords are encrypted using DPAPI.  This mechanism ultimately derives a key from your Windows account password to keep the data secure, and so once you've logged in, the data can be decrypted by applications that rely on this store.

So, Chrome doesn't have access to your Windows account password at all.  It relies on the fact that you're logged in be able to access the decrypted password data for filling in the password fields for forms.  If you try to view your saved passwords, because there are clearly very sensitive pieces of data it has you enter your password, and Windows verify that it's correct to better assure that not only is it you who are logged in, but also you who are currently sitting in front of your computer at this moment, because you're the only one who should know that password.  So, at this point, it doesn't actually need the password to decrypt the data, it's just a security measure to help protect your passwords from casual prying eyes.


Is monitoring registry hives enough to detect new malware installation? Is checking the state of the supporting files of the Windows registry hives enough to detect if a new software/malware has been installed on the computer or a given Windows regsitry key has been modified ?

By checking the state I mean verifying for example the last modification date, the size of the file and so on. It is something I can do with this Python function, for example.

It could be helpful to remember that the supporting files of the Windows registry hives are SAM, security, system, software, default and ntuser.
Maybe the best way to ask the question: what is the full ASEP list to survey for any eventual malware (or even legitimate software) installation ?

There are just too many ways in which malware can persist on a Windows machine without touching the registry. For example:
Windows Startup Folder
Although it is the most simple and obvious to be found, still I am describing it here just to show that this technique doesn't require touching the registry. In Windows family of operating systems every user has a particular statup folder in which any executable or shortcut file placed will be automatically executed by the operating system upon user login. For Windows XP and Windows Server 2003, the starup folder path is:

C:\Documents and Settings\"User Name"\Start Menu\Programs\Startup

For Windows 7 and Windows 8, the path is:

C:\Users\<User Profile folder name>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

If the malware is placed in the above locations, it will be executed every time the user is logged in and this technique doesn't require any modification to the Windows registry.

Trojanize Binaries
The malware can also infect pre-existing binaries and embed itself with the auto-executable executable files. For example, replacing uTorrent.exe with a trojanized uTorrent.exe in which the malware is embedded with the main executable results in execution of the legitimate program as well as execution of the malicious malware file and no mofification is required to be made to the registry (assuming that uTorrent.exe is in the auto-executable files list).

DLL Hijacking
Just placing the malware DLL file at a particular location can also result in the execution of the malicious DLL file. This attack is commonly known as the DLL Hijacking in which the malicious DLL file is placed in a location that is searched first by the OS before it gets to the legitimate DLL path. Again, no changes is required to the registry for executing the malicious DLL through DLL hijacking.

We haven't even touched the BIOS persistent malware even though those techniques have also been publicly demonstrated. In short, there are too many techniques and methods through which malware can be executed automatically at boot time. Once the attacker gets hold of the machine, it is usually futile to detect it at that point. The detection should then move to the network and outgoing traffic from the machine should be analyzed. Note however, that you cannot run netstat, wireshark or any other tool on the compromised machine as rootkits can hide itself from any tool running on the compromised machine. Therefore, keeping in view the concept of defense in depth, you should analyze and protect your assets from the identified threats at multiple locations and hope that not every location can be compromised at once by the attacker.


What is simplest way to transfer files (company computer security is excessive)? I work indirectly for a Japanese government as an English assistant. They block all known internet email, file stores like dropbox, and have recently stopped the use of USB flash drives.

I used to use microSD but several schools don't have the readers. I am currently transferring files using fileconvey but saving a picture of the entry code is a pain.

These are just my own Word files- not control over download. Is there somewhere where I just upload and download from a public website? They don't really care about internet security as they have outdated Internet Explorers and no discernable security software.

I'm afraid this is not the expected answer, but mine will simply be don't.

You are asking for a workaround to circumvent a security policy! If you were an employee, that would be enough for serious sanctions including the risk of being fired.

The correct way to deal with problems like that is to kindly express your needs to your manager or your contact in the organization, explaining that you cannot work because of the security policy and asking what is the recommended way. If the answer is what you want to do is exactly what this policy wants to forbid you will have to analyze one level up with your manager or contact to see how you could change your way of work to comply with the security policy.

There is always a balance between useability and security, and each organization puts the cursor somewhere because of its own security requirement and accepted risk. And if you work (even indirectly) for an organization, you have to fully respect its security policy.


How the inability to modify the title of javascript alert() function helps in anti-phishing I was using javascript in one of my web apps and wanted to display an alert on the screen using the function alert("some message") with a custom title.

example:

but as suggested by many websites, it is not possible since it is a security/anti-phishing feature of js.

Can somebody please explain, how the above mentioned feature contributes towards security (anti-phishing) in the web app?

tl;dr: It (mostly) doesn't.

The real reason why you can't modify the title is that there is no title in the spec. An alert is meant to display a simple message, not to create a complex new window.

If there would be a title parameter, it would not have any impact on security if you were able to change it. An alert is a very weak element for phishing attacks, as it can only display a simple text message (you can't even insert clickable links, so you would need to tell a user to copy-paste a link - except that copying is disabled in some browsers). Apart from being very limited, there is no reason to believe that a user would have more trust in an alert box than in a website regarding phishing attacks.

The impression that it may have an effect on security may come from the fact that browsers decide to include the originating website in the title. So an attacker may for example host JavaScript on their server that displays an alert with the title "google.com says: [...]". But I don't see a real danger here. There is no possibility to enter data in an alert. And even if there were, a user who trusts the alert would likely trust a simple phishing site without an alert as well.

As an alert is part of the browser ui, not the website ui, customization of the look and feel of an alert may provide a danger of impersonating the browser, not another webpage. So an attacker may set the title to "Important security notice" and the message to a description to copy-paste a given URL to install a "security patch". As the alert seems to originate from the browser itself, a user may follow it. But even that seems rather far-fetched to me (and being able to edit the title of a message seems a minor point here; such a user may be just as easily fooled by a message displayed inside a website itself, which has a lot more possibilities to style a message and to receive data entered by a user).


What is the point of spam mails containing nothing but random letters? I recently started replying to spam (as proposed by James Veitch), logged into an old email account and noticed (much to my delight!) a couple of hundred spam mails. Oddly enough I stumbled upon an assortment of mails of the following pattern:

All mails are sent from (supposedly) randomly generated accounts (plausible name, gibberish address) from GMail or AOL, and contain nothing but 20ish random lower-case chars. No links, no attachments, no automatic confirmation.

Contrary to to similar (1) (2) questions this is not a forwarded message from a form - but a standalone mail sent to my account.

I like to understand a scam before I try to waste a spammers time, but this does not make sense to me. It might be a way to probe for valid e-mail addresses, but the addresses this mail was sent to (I blacked them out here) feel a little to idiosyncratic to be generated (for Example: "gaaaabiiiiie@web.de" (not the actual name)). I guess if I answer my E-Mail will be "validated" and I will receive a lot more spam in the future, but aside from that, I do not see any value in sending an e-mail like this.

Update from them comments: There is no visible sign that the account was compromised, running some common decryption methods over the chars did not yield a result either. I think I might try to either answer one of the e-mails or write to some of the other addresses, that I found in the CCs, whether they can provide me with some more examples.

Spam mails containing nothing but random letters can be used to determine the filtering and defensive capabilities of a target.

By analyzing how the system reacts, the attacker can gain valuable information on how much useful (for him) spam he can later send and successfully received by the target via a more elaborate attack.

So think about how your system reacts: will it block spam after 10, 100, 1k attempts of such junk delivery or not at all ? This is one of the important indicators that is used in the reconnaissance.


Storing credit card information for later manual processing I am rebuilding a clients eCommerce site using Wordpress and WooCommerce as the framework.
Their current eCommerce site takes the credit card information and stores it for later manual processing. To "secure" the data it sends halve the credit card number through email and stores the rest.
The client wishes to be able to manually charge the credit cards through their financial service software due to negotiated rates. This eliminates the option to use a payment gateway like stripe.

Their current process appears to be a valid practice according to a post by webengr on this thread: https://groups.drupal.org/node/22389.

  "Many of you are probably aware how zencart/oscommerce does it. The
  basic offline cc processor for zencard saves part of the credit card
  then emails the other part.
  http://tutorials.zen-cart.com/index.php?article=67 There have been
  discussions about it this is good enough to meet the 'PCI compliance'
  Supposedly, your business is PCI compliant as long as you are not
  storing Track 1 CC data which consists of the full CC number, name,
  expiration date."

Is this truly a legitimate practice?

How can I securely store credit cards for later manual processing while adhering to PCI standards?

Is there a service that can store the credit card details and transaction via tokenization. Then login to retrieve the card details by the token and manually charge them through their financial service provider?
What other security practices do you suggest? Deeper answers then using SSL.

The relevant sections of PCI DSS v3.1 are as follows:

  3.2 Do not store sensitive authentication data after authorization (even if encrypted).

However this is allowed if

  There is a business justification and
  The data is stored securely.

Also

  3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a
  chip, or elsewhere) after authorization. This data is alternatively
  called full track, track, track 1, track 2, and magnetic- stripe data.

However, storing the CSV after auth is a complete no-no:

  3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card used
  to verify card-not- present transactions) after authorization.

Regarding the display of the card number itself, it is OK to show the first six and last four digits:

  3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only
  personnel with a legitimate business need can see the full PAN.

The rest of requirement three (3.4.1 to 3.7) describes how you can store card data. The long and the short of it is that you must store it encrypted using industry standard accepted encryption protocols. Full disk encryption is acceptable. Then it comes down to key management. This is the tricky part. The key for PCI DSS is to document how this is going to work and how this meets these requirements.


Create a SSL certificate and sign it with a personal certificate which in turn is signed by a certificate authority I have a personal certificate which is signed by a certificate authority. This certificate is unrestricted with respect to its allowed purposes. Is it possible to create a SSL server certificate on my own and sign it with my personal certificate?

Supose the root certificate authority belongs to the trusted ones of those installed in a web browser. Suppose further that there are no other warnings e.g. timestamp warnings. Will the browser show the "green bulp" even when the "chain of trust" has four or more instances?

Which tools would be appropriated to create such a certificate?

There is another question What kind of certificate do i need to be able to sign my own subdomain certificate. This question has its primary focus on wildcard certificates and on how to uniquely identify multiple sub domains within the same domain. In contrast I ask for the prerequisite which a personal certificate must have and a tool to create a SSL server certificate signed by this personal certificate. The question about subdomain certificates has no answers refering to these aspects to date.

Thank you

Depends on the value of the Certificate Basic Constraints field of your certificate. Most probably it will be  Is not a Certification Authority. However, you can get a CA type certificate which is allowed to issue more certificates. The main CAs (top level) have certificates with the value of Certificate Basic Constraints of the form

Is a Certification Authority
Maximum number of intermediate CAs: unlimited

Sometimes, you see certificates of the form

Is a Certification Authority
Maximum number of intermediate CAs: 0

which means that they can issue certificates, but they can't issue certificates which can issue certificates. In other words, they can only issue certificates of the Is not a Certification Authority type. For example, Google signs each of its subdomains separately using such a certificate.

You can also find

Is a Certification Authority
Maximum number of intermediate CAs: 1

which means that they can issue certificates of the Is not a Certification Authority and certificates of the Maximum number of intermediate CAs: 0 type.

Check with your CA to see if you can get an Is a Certification Authority certificate.


Isn't Ubuntu's system prompt for my password spoofable? Sometimes, Ubuntu shows the following window:

This window can be caused by some background processes running, such as an automatic update, or a process which reports bugs to Canonical which manifests itself this way:

Since those are background processes, the first window is not shown in response to an action I performed myself, in a situation where I was expecting the system to ask me for the password. This means that:

From the perspective of the user, there is no guarantee that the prompt comes from the operating system; it could be any malicious program which had only a limited permission to show a window, and which, by prompting for my password, will gain unlimited access to the entire machine.
By prompting the user for a password regularly, the system teaches the user that giving his system password whenever some application asks for it is a perfectly natural thing to do.

My questions are:

Is there any safety mechanism in Linux in general or Ubuntu specifically that prevents any application from displaying a dialog which looks identical to the system one, asking me for my password?
How should such windows be designed to increase the safety of the user? Why not implement a system similar to Windows' Ctrl+Alt+Del on logon?

Your points are all good, and you are correct, but before we get outraged about it we need to remind ourselves how the linux security model works and what it's designed to protect.

Remember that the Linux security model is designed with a multi-user terminal-only or SSH server in mind. Windows is designed with an end-user workstation in mind (but I've heard that the recent generation of Windows is more terminal-friendly). In particular, Linux convention does a better job of sandboxing apps into users, while in Windows anything important runs as System, while the Linux GUI (X Server) sucks at security, and the Windows GUI has fancy things like UAC built-in. Basically, Linux is (and always has been) a server first and a workstation second, while Windows is the other way around.

Security Models

As far as "the OS" (ie the kernel) is concerned, you have 7 tty consoles and any number of SSH connections (aka "login sessions") - it just so happens that ubuntu ships with scripts to auto-start the GUI on the tty7 session, but to the kernel it's just another application.

Login sessions and user accounts are sandboxed quite nicely from each other, but Linux takes a security mindset that you don't need to protect a user from them-self. In this security model, if your account gets compromised by malware then it's a lost cause, but we still want to isolate it from other accounts to protect the system as a whole.

For example, Linux apps tend to create a low-privilege user like apache or ftp that they run as when not needing to do rooty things. If an attacker manages to take control of a running apache process, it can muck up other apache processes, but will have troubles jumping to ftp processes.

Note that Windows takes a fundamentally different approach here, largely through the convention that all important things run as System all the time.  A malicious service in Linux has less scope to do bad things than a malicious process running as System, so Windows needs to go to extra efforts to protect someone with admin rights from "them-self".

GUI environments and an X Server that was not designed for security throw a wrench into this security model.

Gnome gksudo vs Windows UAC, and keyloggers

In Windows, when a user-process requests privilege escalation, the kernel throws up a special protected prompt whose memory and keyboard / mouse bus is isolated from the rest of the rest of the desktop environment. It can do this because the GUI is built-in to the OS. In Linux, the GUI (X server) is just another application, and therefore the password prompts belong to the process that invoked them, running as you, sharing memory permissions and an input bus with every other window and process running as you.

The root prompt can't do the fancy UAC things Iike lock the keyboard because those either need to be root already, or require totally re-designing the X server (see Wayland below). A catch-22 that in this case is a downside of separating the GUI from the kernel. But at least it's in keeping with the Linux security model.

If we were to revise the security model to clamp down on this by adding sandboxing between password prompts and other processes running as the user in the same GUI session, we could have to re-write a great many things. At the least, the kernel would need to become GUI aware such that it is capable of creating prompts (not true today). The other go-to example is that all processes in a GUI session share a keyboard bus.

Watch me write a keylogger and then press some keys in a different window:

➜  ~ xinput list
⎡ Virtual core pointer                      id=2    [master pointer (3)]
⎜   ↳ Virtual core XTEST pointer            id=4    [slave  pointer  (2)]
⎜   ↳ Logitech K400 Plus                    id=9    [slave  pointer  (2)]
⎜   ↳ ETPS/2 Elantech Touchpad              id=13   [slave  pointer  (2)]
➜  ~ xinput test 9
key release 36
key press   44
hkey release 44
key press   40
ekey release 40
key press   33
lkey release 33
key press   33
lkey press   39
okey release 33
key release 39
key press   66
key press   31

Any process running as you can sniff the password in another process's prompt or terminal and then call sudo on itself (this follows directly from the "no need to protect you from you" mindset), so increasing the security of the password prompts is useless unless we fundamentally change the security model and do a massive re-write of all sorts of things.

(it's worth noting that Gnome appears to at least sandbox the keyboard bus on the lock screen and new sessions through "Switch Users" as things typed there do not show up in my session's keyboard bus)

Wayland

Wayland is a new protocol that aims to replace X11. It locks down client applications so that they cannot steal information or affect anything outside of their window. The only way the clients can communicate with each other outside of exterior IPC is by going through the compositor which controls all of them. This doesn't fix the underlying problem however, and simply shifts the need for trust to the compositor.

Virtualization and Containers

If you work with cloud technologies, you're probably jumping up and down saying "Docker is the answer!!". Indeed, brownie points for you. While Docker itself is not really intended to enhance security (thanks @SvenSlootweg), it does point to using containerization and / or virtualization as a forward that's compatible with the current Linux architecture.

Two notable linux distributions that are built with inter-process isolation in mind:

Qubes OS that runs user-level apps inside multiple VMs separated into "security domains" such as work, banking, web browsing.

Android that installs and runs each app as a separate low-privilege user, thus gaining process-level isolation and file-system isolation (each app is confined to its own home directory) between apps.

Bottom Line: From the perspective of an end-user, it's not unreasonable to expect Linux to behave the same way as Windows, but this is one of those cases where you need to understand a bit about how the underlying system works and why it was designed that way. Simply changing the implementation of the password prompts will not accomplish anything so long as it is owned by a process owned by you. For Linux to get the same security behaviours as Windows in the context of a single-user GUI workstation would require significant re-design of the OS, so it's unlikely to happen, but things like Docker may provide a way forward in a more Linux-native way.

In this case, the important difference is that Linux is designed at the low level to be a multi-user server and they make the decision not to protect a user from them-self, while Windows is designed to be a single-user workstation, so you do need to have inter-process protections within a login session. It's also relevant that in Windows the GUI is part of the OS, while in Linux the GUI is just another user-level application.


Recommended authenticated stream cipher for minimum overhead? I'm running my TCP/IP protocol secured by encrypting each packet with AES128/CBC, bundling a SHA256 HMAC over that packet.

This causes quite a bit of space overhead for small packets, so at first I was thinking of running AES in CTR-mode and still use the HMAC, but it would be much better to run some sort of stream cipher with integrated authentication.

What are my best options in keeping overhead small?

Use any authenticated encryption mode.

That could be a stream cipher with built-in support for authentication (not what I would recommend; all of the candidates are still bleeding-edge), any standard authenticated encryption mode (e.g., GCM, EAX, etc.); or use encrypt-then-MAC with AES-CTR and a suitable MAC (e.g., AES-CMAC or SHA256-HMAC).  Any of those will be fine.  You have not given us any requirements that would rule any of those out.  All of them allow you to select the size of the MAC tag, so you can control the overhead vs. security tradeoff.

But really, you'd probably be better off using TLS or DTLS -- at least, most folks probably would be.  (I know you said you don't want to, but I haven't heard any compelling technical reason not to use them.)


Freebsd: Separating apache service and www-data(htdocs) with jails, is it worth it? Is it worth separating www-data and apache service from each other, in jails?

I currently have this setup:

Freebsd 9

1x Public ip (jails are in private ip's, nat'ed)

2 separate domains, managed by 1 person each.

Jail1: apache service
Jail2: mysql service + database files

I've been thinking about adding:

Jail3: www-data(htdocs) with a nullfs mount into jail 1 (apache), read only. This jail will only be accessible through ssh, via a filtered port.

The idea is to separate the available content and the public facing apache service. Should someone be able to gain access to the apache jail, they will not be able to upload or modify content, considering they are located on a completely different jail.

I think separating ssh login and the apache service adds an extra layer of security. Someone who would ssh in to upload their files would not be able to disrupt the apache service. It would also not give an attacker the ability to tamper with apache.

However, I'm not certain if it's worth it. Maybe chmod gives same security as the above?
How would you secure your webserver when having apache, mysql, freebsd and jails?

I don't know if it is worth it, either.

I think taking regular backups of your web content might give you some of the benefits of jailing off the web-content from the Apache server, and backups might be easier to implement.  Backups don't prevent a compromised Apache server from modifying the web-content, but it gives you a way to roll back to an uncompromised state if you should get compromised.

Ultimately, only you can decide whether it is worth the effort, but my sense is that jailing off the web-content separately probably isn't worth it.  It won't help with the most common kinds of vulnerabilities.  These days, vulnerabilities in the Apache server itself are relatively rare.  Instead, the most common case is vulnerabilities in the web application (e.g., in PHP/Ruby/Java code), and jailing off the web content won't help with those kinds of vulnerabilities.  Therefore, I think I'd recommend that you focus your hardening efforts on defenses and mitigations that help with application-layer vulnerabilities in your web applications.


Can anybody recommend any gems for checking security vulnerabilities? I want to check one of my RoR projects for security vulnerabilities.
So can anybody recommend any gems for my needs?

Yes.  You want Brakeman, a tool that scans your RoR code for security vulnerabilities

I recommend reading the OWASP Ruby on Rails Security Guide.

You could also try any web pen-testing tool; they are not language-specific.  There are many of them.  They only find low-hanging fruit, not all security problems, but it can't hurt to use them just in case they find anything your other methods missed.  Search on this forum to find more information, e.g.,
What tools are available to assess the security of a web application?.


How can citizens prevent government-led Internet blackouts? The United Nations now considers Internet access a basic human right. [PDF]

Despite the questionable effectiveness of Internet blackouts in silencing a populace and preventing uprisings1, it's worrying that governments can flick a kill switch, as they did in Egypt on 27 January 2011. To that end...

Can concerned citizens take any security measures to prevent government-led Internet blackouts, and if not, what methods can they use to establish secure Web access when their country's ISPs go down?

1: Conan O'Brien famously said that, if the Egyptian government wanted people to stay at home and do nothing, they should turn the Internet back on. [source: YouTube]

Preventing government-led Internet blackouts is highly unlikely, since governments have very close ties to the telecom industry for a reason.

By the time Effects-Based Operations on that scale are in play, the likely outcome of a conflict is already decided. Voice communication would be of much more value, and that's a completely different question in my opinion.

To answer your question though, while satellite internet access as Thomas Pornin points out is possible, using dail-up connections over a land-lines or mobile phones to international access points that in turn connects to a encrypted channel would be the most likely solution. International dial-up numbers will only work with international calling service that's working and methods to pass the audio signal to the access point via the phone. Here's an example of instruction on how to connect, and a list of dail-up ISPs access points.

Ham radio users also might be of use, for example, Telecomix, a group of Europe-based Internet activists, were aiding Egyptian protesters for days.  They were trying to establish contact by amateur radio or shortwave, and then forward the audio signals from modems in Egypt to the Internet.


How could I totally secure a connection between two nodes? I'm building an authentication server in python, and was wondering about how I could secure a connection totally between two peers totally? I cannot see how in any way a malicious user wouldn't be able to copy packets and simply analyze them if he understands what comes in which order.

Admitting a client server schema. Client asks for an Account. Even though SRP, packets can be copied and sent later on to allow login.

Then now, if I add public - private key encryption, how do I send the public key to each other without passing them in an un-encrypted channel?

Sorry if my questions remains noobish or looks like I haven't minded about the question, but I really have a hard time figuring out, how I can build up an authentication process without having several security holes.

Basically, the solution you're looking for is going to involve some sort of offline transfer. The two computers that are the endpoint nodes of your secure tunnel must be "introduced" to each other, exchanging some secret that will allow one side to initiate a connection in such a way that only the other node could understand it.

While this shared secret could be the symmetric key in itself, this can be problematic; symmetric algorithms are most secure when nothing about the key is known, even the fact that it's the same key as was used for another communication. An attacker could watch multiple "conversations" between the nodes, and if he knows the conversations use the same key and IV, and if he can guess the plain text (which he is likely to do as the information sent in the initial stages of communication is fairly boilerplate), he can use the ciphertext to reverse-engineer the key. For this reason, the symmetric key must be renegotiated often, even on the same secure channel, depending on how much data is sent across.

The go-to solution is asymmetric or public-key cryptography. Understand one thing; public keys are meant to be public. You could spray-paint your public key on the side of your car and drive it through Black Hat or DEF CON, and all anyone could do is attempt to connect to your endpoint securely (which is no more than they could do to any other TLS-secured endpoint, and they wouldn't get far here; keep reading). The private key is needed in any public-key scheme in order for data to be decrypted efficiently (and thus for information to be at risk).

Now, you may not publicly distribute this certificate; you could, quite plausibly, implement a simple variant of the basic TLS scheme where the normal first step, the client's request for the server's certificate, would be ignored by the server. Instead, the client must already have a certificate for the server "pinned" in the OS certificate store, and would not (could not) verify it had the latest version. It would then be able to negotiate a secure connection without a single bit of actual data being sent plainly (the packet data would still be in a well-formed IP packet).

Conceptually, it would work as follows; the client would have the public key of the server, which it was given offline (here, the only difference between "client" and "server" that we care about is that the client is the one initiating communication; both computers can be "servers" in other senses of the word, such as file servers in the cloud). The server would have the public key of the client, which it received offline. The client encrypts a request using the server's public key, which will contain the client's certificate. That request goes to the server IP, and only the server can decrypt it, even if someone else were sniffing or spoofing traffic on that same IP address. The request can contain a nonce, such as a simple counter value, preventing replay attacks (the server can ignore multiple requests from the same client with the same nonce, though it must decrypt each request it receives to determine this, which could make it vulnerable to DDoS).

The server would then use the client certificate, which it can independently verify as an authorized client because an exact copy of the client cert lives in the server's OS store, to send a symmetric key negotiation. From this point the scheme is virtually identical to two-certificate TLS negotiation; the server sends the client the key negotiation request, the client receives, sets up its cipher, and returns either a symmetrically-encrypted acknowledgement or the other half of the key-exchange protocol so the server now knows they're talking the same language. From then on, client and server can communicate using the symmetric channel. All this, without a third-party observer seeing any packet data in plain text.

Now, this is just to create a secure channel. Even if the client node has a static IP, it's always good to subsequently verify, after negotiating the secure tunnel, that the human controlling the computer on the other end is someone authorized to use the system. Credential exchange like username/password, or the entry of a time-limited key value generated by a fob, are common and perfectly feasible means to authenticate the user of the authenticated computer(s).


Encryption as bijective data masking function Context
I'm building data lake from scratch within a small team (3-6 data engineers). I want to mask PII data when copying data from prod to dev/test environments.
I'm particularly interested in the case when ETL join, srk generation, deduplication logic depends on PII columns. So I believe I need bijective (no collisions, consistent) data masking.
Question
From point of data in-use protection, is there any better approach then deterministic encryption for consistent data masking in my case?
Considerations
In case of HIPAA, PCI or other regulations that enforce encryption at-rest, I can use both:

non-deterministic encryption at-rest, managed by storage
deterministic encryption for PII columns only, managed by me on moving data from prod

In scope of this question lets forget about subject removal requests (GDPR), so I consider lookup/translate tables as a big overhead. Testing should be automatized - so format preserve masking isn't required.
UPD (what is considered "better")
Could you very superficially assess the degree of security with deterministic encryption option? Would it be "math PhD with 10 huge servers may brute force in 1 month" or "average business analyst on personal mac may brute force in a few days"?
"Better" = just enough security (loosen) + less team reasources to implement & support the solution + distinct/cosnsitency properties
"Just enough security" = at first I hoped to achieve resistance to brute force attacks. But if that isn't possible completely...
"Just enough security (loosen)" = brute force risk/impact reduce + column-level restrictions for part of personnel + data download restrictions + full-fedge access to data only through audited notebooks/queries + employee trainings
Performance isn't critical at all (my case - batch processing, it's performance on write which happens pretty infrequently).
Statistical values of encrypted data also don't matter.

In general, you don't want to use deterministic encryption for non-uniform data (so cryptographic keys are okay, but other data is not).  That's because secure encryption tells us nothing about the contents of the data except possibly its length, so it shouldn't be possible to determine anything about two messages based only on their encrypted versions.
However, with a deterministic encryption method, two identical messages encrypt to the same thing.  That's bad, because if we take a large set of city names, the most common encrypted values are generally going to be the largest cities in the region.  For example, in the United States, the most common cities will be New York, Los Angeles, Chicago, and Houston.  If we also see first and last names encrypted deterministically, with a large enough data set, we can easily deanonymize data.  For example, two people in the same city with the same uncommon last name might be related.
That's why this approach isn't secure and shouldn't be used, and it's why ECB mode can't be used for data.  Moreover, if you use certain types of encryption, such as CTR mode with a consistent nonce (or another stream cipher), you make it very easy to recover the plaintext via crib-dragging attacks.  You need to use a secure mode with a suitable nonce for each different piece of data.
So there isn't a secure way to do what you want to do.  If you don't have a better suggestion than deterministic encryption for your test environment, I'd suggest generating test data independent of your prod data and using that.
Because modern encryption modes are not designed to encrypt multiple pieces of data with the same nonce and still protect the information, if you want some way of obscuring data which is unique, I would use something like HMAC-SHA-256 with a fixed and secret key.  For things like phone numbers, which are unique or nearly so, this provides a secure way to obscure the data and provide a one-to-one correspondence with it, but it isn't invertible.  This is secure because it's unlikely that people will be able to deanonymize your data, so it's okay for things like phone numbers and email addresses, but not for data which multiple people will share in common and which differ in frequency, such as names or city locations.  For those, any deterministic technique will be a problem.  If your data set is large enough and contains enough personal fields, an attacker will almost certainly be able to discover the identity of at least some of your users with at most a couple of days' worth of work.
I fully agree that using encryption or some other cryptographic method is better than not doing it, but if you're using these techniques to obscure personal data that isn't unique or nearly so, then you need to treat your development data as just as sensitive as your production data because its exposure will expose your users.


How would you store a 4 digit pin code securely in the database? I'm familiar with password hashing, using salts, bcrypt etc.

But it doesn't seem like this would work to store a 4 digit pin code since the attacker could try all 10,000 combinations quite quickly.  Is there something I'm missing or how is this commonly done?

If you are worried about a "leaked database" scenario (rather than the online cracking vector, which can be mitigated by per-user, per-IP, per-site rate-limiting and lockout) then you are right that hashing is not enough.

Even using the most complex sequence of hashes & salting e.g. bcrypt(pbkdf2(sha256(pin),salt1),salt2) you are still going to be vulnerable to anyone who can see (e.g. from a source code/docs leak) what algorithms are used and who can find your salts (normally stored in the same DB/table) -- they can just run the same series of hashes, and even if it takes a minute for each that's only 7 days to try them all. So you would basically be relying on security-by-obscurity.

In this case it would be worth encrypting the password hashes with a secret key (which can be kept separately from the source code, only accessible to trusted "production security operations" users, never re-used in pre-prod environments, changed regularly, etc.). That secret key will need to be present on the server which validates/updates PIN codes, but it can be kept separately from the user/pin database (e.g. in an encrypted config file), which means that Little Bobby Tables won't automatically get access to it when he snarfs the whole of T_USERS via SQL injection, or when someone grabs a DVD with a DB backup on it from your sysadmin's desk.

[Normally encrypting the hashes is not recommended, because its better to use a secure hash, good salt and strong password/phrases, and encrypting the hashes can give a false sense of security. But if you can't have strong passwords then there aren't many other options -- beggars can't be choosers...]

You could combine the PIN with a password -- but in that case why bother with the PIN at all? Just require a strong alphanumeric password. (If the PIN is used in combination with a smartcard or token or similar, of course, then it can add to the overall security.)

We could use a bigger (6/8 digit) PIN. Its not feasible to make a digit-only PIN be secure from brute force: at 1B hashes per second, we'd need 16 or more digits to push the brute force time beyond a year. But adding a few more digits might be enough to make the online attack easier to detect and block -- with only 10K combinations its going to be hard to set "slow-force" thresholds low enough to make an attack infeasible. Unfortunately, you have likely have physical constraints (hardware selection) which preclude longer PINs.


GPG warns about unprotected subkeys while using monkeysphere Issuing monkeysphere subkey-to-shh-agent GPG warns me:

gpg: about to export an unprotected subkey

then it asks for the passphrase and everything works fine.

What's the meaning of "export an unprotected subkey"? What are the security issues related to this warning?

Looks like it's an issue with monkeysphere and ASCII armoring in gpg:

http://permalink.gmane.org/gmane.comp.security.monkeysphere/401

  Chatted with dkg on irc, turns out monkeysphere just doesn't like "armor" in one's ~/.gnupg/gpg.conf - dkg seemed to think this was a bug that wouldn't be that hard to fix.

ASCII Armoring is just a term for binary to text encoding.
Wikipedia article on binary to text encoding

GPG is just complaining that the exported key lacks this encoding, which the comment from the mailing list backs up if the author isn't using it elsewhere.


How to detect suspicious tokens collected by a hacker I previously asked a question here What's the use of adding a challenge to a one time password algorithm?

Let's suppose that a hacker has succeeded to collect tokens. Is there a way to detect suspicious activity with them ? For example if the user creates another token and uses it and hackers use previous tokens, could server detect this as weird because user shouldn't have used new token before previous ones ?

Sure, but this makes a certain set of assumptions.

The OTP is event-based, not time-based
You have to be tracking previously used tokens
You have to track expected future tokens
The user doesn't have the ability to reset their OTP sequence with the initial seed

In theory with an event-based OTP once you use it anything generated before it is unsuable because the server should only be expecting OTP's generated after the current one. So if an attacker collected unused OTPs they wouldn't work after the user authenticates with the latest OTP.


Is this the correct way to use AWS Cognito? I am doing the following in my React/Node App:

Using the User Pools for a Cognito App that I have created
Calling the /login endpoint with response_type=token in my React App
Once I receive the JWT token, I pass it to my node/express server in a header (my server is using ssl)
On the Node server, using cognito-express package to call cognitoExpress.validate(accessTokenFromClient, callback) to validate the token
If the call is successful, saving the user details (email etc) and the jwt in localStorage in the React App

And then, for every call to my server, I am repeating steps 3 and 4 above (validating jwt) to ensure that the user is Authenticated.

My concerns with the above approach is:

I am unsure if the cognito-express is actually calling Cognito, or is it just decoding the jwt and making a decision on its validity locally
I tried leaving the session open overnight, and I expected that the call to cognitoExpress.validate(accessTokenFromClient, callback) would fail (because the jwt expires in a hour), but it didnt. Does this mean that an expired jwt token is considered as a valid claim
If the user was Authenticated and his JWT has expired, how do I refresh the JWT without asking him to login again?

The cognito-express calls Cognito to get public JSON Web Key (jwks.json) from your user pool which it then uses to validate your JWT. The address is derived from your pool-id and region you provide to the library.
As far as I can tell this appears to be a bug in cognito-express. The number they pass in maxAge option is supposed to be in milliseconds but the library they use (node-jsonwebtoken) says a numeric value gives the expiration in seconds. Might want to raise an issue at their github site to clear this up.
You should have received a refresh token along with access token when first logging in. You should pass this refresh token to Cognito to receive a new access-token as mentioned in the documentation. You'll have to do this yourself as cognito-express doesn't handle this part. Basically you'll need to keep track of the expiration in your app and make a call to Cognito at or slightly before expiration.


How do iTunes movie rentals work? I've been wondering how iTunes movie rentals work from a security standpoint.  Given that the "rented" files are actually downloaded to the user's computer and then played from there, it seems like there is no way to prevent the user from saving the files indefinitely.

It's possible that the files are stored in some proprietary format (something like CSS), but this could easily be subverted in the long term by reverse engineering the code that plays them (as happened with DeCSS).

I'd be very glad if someone could point me to some references analyzing this system.

DRM systems tend to all work according to a variation of the same basic principles:

Contents are encrypted with a symmetric cryptography algorithm, such as for example AES-128.
The content key, along with a machine-readable description of usage rights (such as "play for 48 hours") is delivered to the user's device upon content purchase.
This key+rights bundle is often called a "license", and is itself encrypted with public key cryptography. This implies that the user device possesses the private key to decrypt this license.
Upon content playback, there is necessarily a "trusted" piece of software running inside the playback app - in this example iTunes. "Trusted" is in quotes because Apple trusts it, not you!
This piece of software, sometimes called an "agent", is in charge of decryption and - importantly - enforcement of the usage rights. In this example, it will perhaps self-destroy the key after 48 hours.
Agents, due to their nature, usually come heavily armored against attacks, to defeat reverse engineering attempts: decompilation will yield garbage results, debugging is made impossible, etc.

So... To answer your question: yes, the content and the decryption key are both on the device (at least for a while) but there's a machinery working against any attempt to put them together. People have occasionally succeeded in the past, but the bar is getting higher all the time.


Torrent "bad seed" attack by Sony, how does it work? Sony recently saw a large amount of data stolen. In order to prevent the stolen data from being spread using torrents, they are doing what was called a bad seed attack. What is this attack? Is this a known attack or some term they coined for what is happening in this specific case?

Here's an excerpt from an article relating to the attack:

  (...) that starting yesterday, “all of a sudden we saw files matching the SHA1 signatures of the Sony torrents starting to be populated across all the torrent sites.” (...) files were intelligently designed to have the same signature as the GoP file torrents (...) [The SHA1 signature is in the metadata provided with the seed, not a result of a file that causes a SHA1 "collision" by matching the file's exact hash.]

From what I understand, they are not using SHA1 collisions; the original file was replaced and they simply re-calculate the hash which is provided with the file. (Or hashes, are these per block or per file?) The client checks a block after downloading it, realizes it is fake, and attempts to re-download it possible from a different seed. This goes on until all correct blocks are downloaded. Is this correct? So the clients can still get the files, it will just take a lot more time since fake data is constantly being downloaded?

Correct.  As explained in that article the torrents use the BitTorrent protocol to share Sony's stolen data.  Each piece that is downloaded via a seed is linked with an index into the file, and the hash of that portion is checked and verified.  However, I don't believe its this hash that they are referring to in that article.  Below I'll describe the process of downloading a file via BitTorrent.

.torrent File
The BitTorrent protocol itself says that the .torrent file contains two fields of information:

announce: URL of the Tracker
info: Maps to a dictionary of keys

Each piece of data in the dictionary is used to piece together the original file.  This means that a file is split into predetermined pieces, and each piece is generally a power of two.  This dictionary contains all the information about each piece, the length, and the SHA1 hash of each piece to verify a complete download.

Tracker
When you attempt to download a file with BitTorrent it will attempt to do a Tracker GET Request.  In response, there is a lot of information about what peers are currently available for the download.  Typically a compressed version of the list of peers that can be used to download the file.  Connections are made to the peers in order to download each piece, and once all pieces have been received the Torrent client is notified.  Each piece is considered to be complete when the SHA1 hash of the data is verified.  As stated before, this hash value is provided in the info dictionary.

This SHA1 hash is not the hash that is being spoofed.  One other piece of information that is included in the Tracker response is a field called info_hash:

  info_hash
      The 20 byte sha1 hash of the bencoded form of the info value from the metainfo file. Note that this is a substring of the metainfo file.
  The info-hash must be the hash of the encoded form as found in the
  .torrent file, regardless of it being invalid. This value will almost
  certainly have to be escaped.

Keep this in the back of your mind, we'll come back to it.

Peers
The Peer protocol is what's being spoofed.  Each peer must establishes which piece of the file is downloaded by that peer using an index.  There is a handshake for establishing this connection, and it involves sending the value of info_hash.  The client downloading the file verifies that this matches the SHA1 hash of the bencoded info field of the .torrent file.

What Sony allegedly did is put out fake files with the correct hash values to establish connections to clients attempting to download them.  The files can be bogus because the client must download the entire piece in order to verify that portion.  When the check fails then a download for that piece must be restarted.

As you can see (and it's mentioned in that article) this can be a problem for web servers.  The constant downloading of portions of the file with literally no end can end up causing major bandwidth usage.  This can results in a DDoS of the web server.


Alternative Email Provider As a continuation to Why would someone trust DuckDuckGo or other providers with a similar privacy policy? it seems like we already have a secure way to make a search without writing history and etc. at least it's written in duckduckgo privacy policy.

My question is do we have the same alternative for Gmail, which at least assures that he doesn't read our email's and then offer an adv based on them and so on. I am looking for alternative for Gmail for which privacy and security is the main thing.

Promises of anonymity are only as good as they get. If you want to have some reasonable guarantee that your email contents won't be read by the email provider, then encryption is the right tool. See OpenPGP and S/MIME. In any case, an email is between two persons, and even if you have a "privacy-preserving" provider on your side, you cannot have the same guarantee for the provider used by the people you send emails to, and receive emails from. There is no guarantee of protection for emails in transit, either; only encryption will bring you a comprehensive solution for the whole emailing system.

Of course, regardless of encryption and other measures, an email must still be transmitted, which means that outsiders can still see the destination address, which can be quite revealing.


Buffer Overflow in the C program I'm preparing for an introductory information security examination in university and this is one of the examination questions on Secure Programming.

Here is the question. Sorry the original condition of my document is badly scanned before it was handed to me.

I have several discussions with my friends, and they suggested this solution for (a).

Fill the first 50 characters of B with non-null characters and the 51st element with a null terminator. The length of the string represented will be 50, as shown from strlen(B), this causes the branch with strncpy(A,B,C) to occur, which will copy the first 50 characters of B into A.

Later on when the loop is called, number of loops equal to the length of B, there will be a Buffer Overread as it reads outside the bounds of the array A.

As C is an unsigned char with bounds 0 to 255 while strlen returns unsigned int with bounds 0 to 2^32 – 1, the extent of Buffer Overread will differ.

(b) will require me to assume this is the case in (a), and will require me to answer it like this:

When printf() is called, it will result in an infinite loop as with the same configuration, the '\0’ cannot be found in the array.

I’m not sure whether my logic is correct, but the worst part is I’m unable to replicate this.

Just running the code segment on MacOS Mojave, as shown below, already gives me an “Abort Trap, and many people call this Buffer Overflow.

I’m not sure about my logic and the reason why I cant replicate the problem, can someone help me out?

int main() {
    char buffer[2];
    char str [3] = "sa";

    if (strlen(str) <=2) {
        strcpy(buffer, str);
    }

    printf("%lu\n",strlen(buffer));

    return 0;
}

Your assumption is correct.
The issue is with the logic in the for() loop.
if you run the following code you will find it runs beyond the value of C in the exercise provided. I have added notes for you in the requirements of the exercise.

main() {

unsigned char b[1500];
unsigned char a[50];
unsigned char C;

int i;

bzero( (char *)b , 1500);

/* lets fill b[X] with null values */
for (i=0; i <= 1024; i++ ) { /* no less than 1024 */
        b[i]='0x0';
}

/* put the letter A in b[X] */
for (i=0; i < 50; i++ ) {
        b[i]="1"; /* only numeric chars */
}

C = strlen(b);

if ( C <= 50 ) {
        strncpy(a, b, C );
        printf("b = %lu\n a = %d\n ", strlen(b), strlen(a));

        for ( i=0; i < strlen(b); i++ ) {
                printf("%d\n", a[i]);
        }
        printf("the value of i in the loop:  %d\n", i);

}

}


What is the correct way to seed CSPRNG functions? When using CSPRNG (crypto secure pseudo random number generation) functions seeding is an important step. So what is the best way to seed a random number function?

As anywhere in engineering, there's no "unique" best way; there's always going to be tradeoffs between:

entropy of the source of randomness,
rate of the entropy (i.e. how many bits/second can you get?),
suitability of the source distribution,
computational resource and energy usage,
lack of side-channel attacks on the entropy generation,

and finally, and really not unimportant,

cost.

For example, if you had a truly random source of entropy that you could ask arbitrarily often per second, you'd need to do little CSPRNG – you'd basically have a CSRNG, nothing pseudo about that! All that the generation would do would be a bit of distribution shaping to get uniformly distributed bits, which is what most crypto algorithms need.

Now, since you don't have that, in general, you'd want a source that is

uncorrelated, actually even
unpredictable,
unmanipulatable, and
doesn't have any side effects, neither whether it's currently working, nor about the random data it's producing.

As such, high-quality sources used where it actually matters are often of a quantum nature: spontaneous emissions of photons in excited matter, often.

However, as anything, "the best possible" will set you back a couple thousand dollars, not fit in your rack server, laptop or smartphone, and actually be resistant to ... no attack anyone would ever try to do, realistically.

So, as always: Model your threads. Then define the number of truly random bits per second you'll need. See whether built-in methods (CPUs these days have truly random number generation – is that enough for you, assuming that you can isolate that CPU well enough to make any kind of side channel attack impossible?), together with state-of-the-art entropy pools. For all things I can imagine, Linux' /dev/urandom, using the ChaCha20 algorithm on such hardware sources, is cryptographically secure!


Should an invalid user name be logged? While authenticating, should attempts with invalid user names be logged? OWASP Logging Cheat Sheet says that authentication failures must always be logged. I can observe several programs doing this, including login on Linux:

login[1234]: FAILED LOGIN 1 FROM tty2 FOR foo, Authentication failure

It has happened that I accidentally typed in the password in the user name field which is then logged. Should a (web) application always log invalid user names? Why would it not be sufficient for an authentication system to log only invalid authentication attempts for valid user names?

Yes. But on the other hand you don't want the log file to potentially contain the passwords, which would happen if someone botched the login and sent the password instead of the username.

What I think might be a viable compromise could be to log:

attempts with valid usernames and invalid passwords, logging the username but not the password.
attempts with invalid usernames (which might be passwords or whatever), logging the username as "INVALID".

The rationale is that several attempts with a single valid username will tell you of a possible bruteforcing against that username; a swarm of attempts against the INVALID username will warn of a large-scale "username with obvious password" attack, which, if you have a proper password policy, is irritating but harmless. Even more so the attempts against well-known users.

It is conceivable that someone might be attempting to bruteforce a single invalid username; if that's a concern, you might log invalid usernames as (partial and/or salted) hashes. The value of this cleartext information, even if captured by hostile parties, would be essentially nil.

A very small number of attempts on the INVALID username may be due to users misspelling their own names, or entering the password instead of the name; or paranoids that intentionally botch their first login believing this to protect against credential capture.

Especially if quickly followed by a valid login from the same address (unless it's a system masquerading a large network...), an occasional authentication error of this kind could be considered noise and ignored.

(You might further distinguish a small set of "valid invalid names" such as info, admin*, Administrator, guest, if you wanted, but that's probably overkill).

Also, for the truly paranoid, you could pad all valid usernames and the string "INVALID" to be the same, fixed length (say... 20 characters?). If by any chance an attacker could be able to remotely observe the log file's growth, he would thus be unable to tell whether a username was existing or not on the system.


Box web application security review - legality? is it legal to do a security review/pentest of a web application that we bought and operate on our servers? Meaning, the whole infrastructure is ours + we bought a licence for the software. Can we do an in depth review of it? Or would this be breaking some laws against reverse engineering etc.?
I'm interested in USA and EU laws.

Many thanks

Depends what kind of assessment you want to do.  Maybe you should change your title to indicate "Black Box" or "White Box" or both.  I've learned that vendors have a very loose definition of "security review" on their software so it is important to do your own assessment if you have the resources.

Code Review

The Vendor's code is theirs and you aren't allowed to decompile it without their permission.  Most vendors are not willing to share their source code.  All you can do is ask them for their report of their own internal source code review.

Static Application Assessment

There are ways to do security assessments without their decompiled code. Static code analysis like with Veracode is done on compiled code and the service never sees the source code.  It helps triage the results if you can see the source code, though.  Most often, I pass these results on to the vendor.
The best situation is if security assessments (static or dynamic) are written into the contract with the vendor, but it is legal to upload a compiled program to such a service.

Dynamic Web Application Assessment

A dynamic (black box) scan is totally allowed on an application in your environment and this should be your first step.


Does Username + Password + Pin improve login security? I've been asked to add a feature to a website to require a pin for users. The site currently uses username and password. If a user wants to change their password they need to supply the current password OR use a "password reminder" feature that sends a one-time-login token to their e-mail address.

There is a request to add a numeric pin code (at least 4 digits) so that user's would authenticate with username+password+pin code. We would need to add the pin code into the account management form and, I guess, let users change the pin if they can remember their previous pin OR they use the one-time-login feature.

Three questions:

Does this actually help security in some way?
Is it more effective if the pin is on the main login screen or a second page in a multi-step form?
If we can easily enforce a password policy, (requiring a digit, special character, etc.) is that more or less helpful?

I'm interested in lots of perspectives here and will choose an answer that presents pros and cons to these strategies.

1) More authentication has all the Pros and Cons usually associated with it (more information is harder to hack, but harder to remember). With a pin, people are extremely likely to use birthdays and other easy to remember numbers, so social engineering might make it easier to break than a password or actual 2-factor.

2) Do you have other systems in place to prevent brute forcing? If not, you should place it on the primary page. XXXXXXXX#### is harder to guess than XXXXXXXX then #### (simple math: you'd have to guess "AAAAAAAA" 10^4 times before concluding moving on to "AAAAAAAB" in the first, but only have to do it once in the latter. Multiplication of possibilities versus addition). If so, perhaps some benefit is gained placing the PIN on page 2 because the PIN could be sent on a more secure line?

3) Password rules, while nice in principal, fail in practice for much the same reasons as seen in 1. Social Engineering, incrementation of passwords, and writing them down on a sticky note by your desk. There are plenty of other questions about best practices for password rules (I use 14 character passphrases generally), but all passwords are weak to social engineering and forgetful users.


Apache: Can I revoke certain client certificate on certain subdomain only I would like to know if we can make the client certificate valid for certain sub domain (Virtual Host). For example if I have two client certificate A, B.

A is valid for subdomainX but not for subdomainY.
B is valid for subdomainY but not for subdomainX.

A certificate is like a passport: it is either valid or not, i.e. you cannot selectively revoke it only in specific areas. But you can specify which certificates/passports are accepted as authentication in which areas. This can be done for example by not accepting any certificates issued by a specific CA (SSLCACertificateFile) but additionally restricting the subject using SSLRequire. For more information about this see the Apache SSL documentation, specifically the question: "How can I allow only clients who have certificates to access a particular URL, but allow all clients to access the rest of the server?" which shows how to apply such certificate restrictions to specific Locations only.


Securing a file from getting stolen in an Android application? I have a secret file which I cannot encrypt (because I am using it in a third party library) in an Android app which I want to protect from reverse engineering. The app will go public on Google Play store. The app can authenticate a user and later download this secret file. But as this file cannot be encrypted, is there a way where I can protect from reverse engineering?

I thought to download an encrypted version of the file and decrypt it in JNI layer to a new file and later use the new file in 3rd party library but the risk is any legit user can root the phone and gain access to the decrypted file.

You are out of luck here. If you want the file to be used on users phones, you will have to live with the fact that the file can be stolen. Encryption doesn't really help here, since you need to store the key somewhere on the phone. A sneaky user can just steal the key and decrypt the file themself.

You can make it more or less complicated to gain access to the file by obfuscating in various ways, but in the end you are playing a loosing game here. If the contents of the file must not be stolen, you need to rethink your architecture. Whatever is done with the file has to happend on the server side instead of on the client, so that the client no longer needs the file.


Why do ATMs accept any PIN? The other day I tried to withdraw some cash from an ATM in a hurry and punched in a wrong pin. I realized that only when I hit the "ok" button, but to my surprise the ATM did not complain. It showed the usual menu, asking me to select an operation. It's only when I selected withdrawal I was prompted that the pin is incorrect, and asked to re-enter. Which I did and received the cash.

Why do ATMs allow entering any garbage for a PIN, selecting an operation and only then complain?

EDIT: to add more information about some points discussed in answers and comments: the country where this happened is New Zealand. The card is a chip card which also happens to have a magnetic band, and I have no idea if the ATM can read the chip or not.

This answer applies when the ATM uses the card's magnetic stripe, not when the card's chip is used.

The keyboard of an ATM is a completely separated device with special hardware security features (like self-destroying chips if someone tries to open it, etc.) because it's the bottleneck of the whole ATM security.

When you enter a pin, the ATM itself won't receive the PIN in plaintext, but rather get the PIN encrypted. When it sends a transaction to the main server, it cryptographically combines the encrypted PIN with the amount of money specified in the transaction to prevent attackers from modifying this amount.

If the ATM would have verified the PIN before the transaction (by sending it to the server), the specification of the amount of money couldn't be securely related to the knowledge of the PIN.

Therefore, the ATM can't verify whether the PIN is valid or not until it attempts to issue a transaction to the main bank servers (who know how to decrypt or otherwise verify the encrypted PIN).


Encryption & protecting data from myself (and hackers)! I'm trying to figure out a decent encryption strategy for a small business application. My main goal is to expose myself to as little unencrypted PI as possible.

I have no idea if I'm overthinking this and there's an easy way, so I thought I'd ask. I'd also like to hear if any of my thoughts are complete rubbish.

I've thought of 2 strategies thus far:

When a user logs in, they're asked to input a master decryption password. This password is used to decrypt the private key and a random string is generated & stored in a cookie (or perhaps in local storage + transmitted with every post request). The private key is re-encrypted with the random string and whenever encrypted data is requested the cookie string is used to decrypt the key, then the data.

Disadvantage: As the server admin/hacker, I could obviously intercept the master password and decrypt the key, then the data.
Advantage: Pretty straight forward.

The public key only is stored on the server. Between the server and the client is a reverse proxy which parses the content (similar to how ESI work). This proxy server would contain the private key and decrypt the data before serving to the client. The keys on this server wouldn't be managed by the same admin.

Disadvantage: As the proxy admin/hacker you could obviously intercept the data as it goes through. You would also have private key access.
Advantage: As the proxy admin/hacker you wouldn't have credentials to the application, thus you would only be able to sniff data that is requested by the end users.
Advantage: In a business environment, it's likely that this server can be much more easily protected against external sources. No incoming connections could be allowed at all.

The following are treated as a given:

All transport is secured by SSL.
In all scenarios I would have access to data as it was input. This could be mitigated by using JS public key encryption.
Actual application authentication is fit for purpose. I.E. Social engineering, brute force etc are all discounted. Browser-based issues/bugs are not discounted.
The encrypted data needs to be accessible by a team of authorised people.
It needs to be accessed through a browser.
The whole disk is encrypted at rest, which is no benefit to, say, breaching root via SSH.

I've discounted the following:

JS decryption—from what I've seen, this just means the private key is exposed to the end user.
Symmetric keys & pub/priv keys unencrypted on server, DB on another server. I'm not really sure of the value of these. As an Admin, or a hacker, I would have everything I need to decrypt the MySQL data if I were to breach the application server.
Third party Key servers: This just seems to pass the buck to someone else being able to see the content (though I am wondering if there's a multi-step process that could work in conjunction).

The solutions you suggest can all be broken, given that they only move the trust somewhere else. You need a cryptographic solution that ensures the following:

Your server is able to accept and transmit encrypted material to the correct users.
The user has access to the encryption key.
The server has no access to the encryption key.

This requires in-browser JavaScript crypto, or a separate client-side program. Obviously, there is the possibility for a malicious admin to replace the JavaScript with a version that sends the key or original plaintext to the server, but this will always be a risk.

Depending on the type of data being stored, there is already a rather simple solution which is used by many paste websites like Zerobin and 0bin, as well as the popular Mega file host: client-side encryption. JavaScript in the browser creates a symmetric encryption key and appends it as the fragment (anything past the octothorpe) of the URL. The fragment is only visible to the browser, not the server. JavaScript in the browser encrypts data using this fragment and uploads the data to the server. The result is that you need the full URL in order to view the page, and the server is unable to decrypt.

A URL may thus be represented as example.com/path#fragment. Your ISP sees example.com, as this is what you send to the DNS server. Even with TLS being used, the domain is still sent in the clear as a result of SNI. /path is only visible to the server you are sending it to, assuming you are using TLS. This is what the server uses to determine what to send back to the client. The last part, #fragment, is only visible to your browser.

Take this example URL from Zerobin:

zerobin.net/?5cd884d7e1409f31#25LMCTnmrN3H/BPcebRjH6Gl05Sklj91CssV45YwQ/o=
|   host  |    identifier    |            base64 encoded key              |

In this example, the domain is, obviously, the address of the server. The identifier is the path which specifies what encrypted paste is being requested. When the page is retrieved, the fragment is never sent to the server. When fetching a file, all the server sees is this (in this example, using cURL rather than a web browser):

GET /?5cd884d7e1409f31 HTTP/1.1
Host: zerobin.net
User-Agent: curl/7.56.1
Accept: */*

This tells the server to retrieve the encrypted post and serve it, along with the JavaScript required to decrypt it. If the key is not correct, or the key is not present, the code on the page will be unable to decrypt it. This is intended to ensure that the plaintext is only visible to someone who has the URL. It is up to them to decide whether or not the URL should be distributed widely or kept relatively secret. This technique could be easily modified to use a password rather than a URL fragment, but if the issue is simply reducing PI, this should be plenty.

More information about this specific information is on the Zerobin project page.

With sufficient engineering, this can be made to store far more than just text pastes. Mega for example supports accessing storage like a filesystem. There is even a utility which mounts your online user directory as a filesystem using FUSE, allowing interaction using generic filesystem actions, all the while ensuring the server does not know what is being accessed. Your application could be made to do this if this fits your requirements.


eCryptfs: what if I remove ~/.ecryptfs I'm learning how to use eCryptfs: https://wiki.archlinux.org/index.php/ECryptfs

I get things as below from the link:

  This is used to derive the actual file encryption master key. Thus,
  you should not enter a custom one unless you know what you are doing -
  instead press Enter to let it auto-generate a secure random one. It
  will be encrypted using the login passphrase and stored in this
  encrypted form in ~/.ecryptfs/wrapped-passphrase. Later it will
  automatically be decrypted ("unwrapped") again in RAM when needed, so
  you never have to enter it manually. Make sure this file does not get
  lost, otherwise you can never access your encrypted folder again!

So I did a simple test:

ecryptfs-setup-private
mkdir -p ~/test
mount -t ecryptfs ~/test ~/test
cd ~/test && vim data
umount -t ecryptfs ~/test

For now, I did get an encrypted file, which means that ~/test/data was unreadable.
Of course, if I mount it again, I can read it.

Now, I delete ~/.ecryptfs: rm -rf ~/.ecryptfs.
Then I try to mount it: mount -t ecryptfs ~/test ~/test

To my surprise, I can still mount it and read the ~/test/data.

Now I'm confused. I thought I could move ~/.encryptfs into some USB to keep my secret data secure. But it doesn't seem to work because I can still mount it even if I delete ~/.encryptfs. Am I doing something wrong?

A reading of the manpage and a quick skim of the source to confirm indicates that (among other things) ecryptfs-setup-private creates a directory with encrypted data at ~/.Private, creates a mountpoint for decrypted data at ~/Private, and encrypts the encryption key with the login passphrase at ~/.ecryptfs/wrapped-passphrase. These paths are not configurable.

What you've done is create an ecryptfs directory at ~/.Private with a wrapped passphrase, then created a separate ecryptfs directory at ~/test using your passphrase directly as the key (bad idea). If you want to test that wrapped passphrases work properly you will need to use the ~/Private directory instead of trying to create your own.