Security flaw while importing certificate? Recently the company where I work changed its way for users to access the internet. Windows users log in an Active Directory server, and in order to use the internet, they can use any browser with the proxy option disabled. For linux users, there is an exception: we have to import a certificate people from Security Information area generated for us. My questions are:

1) What's this certificate for? I think this can be a silly question, but I've always thought certificates weren't for client, only for server. What I mean is: if I try to access google.com via https, then my browser will verify google's certificate if it's good or not. Can you see that, in this point of view, there is only server certificate?

2) If I don't import it, every site access attempt results in a certificate validation error. Why is that? AFAIK, certificate validation error occurred only when server certificate was invalid or outdated.

3) Is there any flaw in this situation? For example: can I use this certificate in order to try a MITM attack?

4) Windows users don't need to import this certificate, whilst Linux users do. Linux users need to authenticate every 12 hours, whilst Windows users don't. May someone write something to explain what's going on here?

My company uses a product from https://usercenter.checkpoint.com/usercenter/index.jsp in order to manage the accounts, to filter websites etc.

EDIT:

After Steffen's answer, it occurred to me: the certificate I had to import is the same for all Linux users. Given the fact that I have the certificate, A) can I "extract" (or export or get or whatever) the private key from it? If so, B) can I, after sniffing the network traffic, use it to decrypt the packets that I occasionally get?

1) What's this certificate for?

For SSL interception at the firewall, i.e. the SSL connection will be terminated at the firewall and the firewall will do a new SSL connection to the server. All the certificates you get in your intercepted connection will be signed by this CA certificate you've imported and are therefore considered trusted. This way the firewall can analyze even SSL traffic.

  2) If I don't import it, every site access attempt results in a certificate validation error. Why is that?

Because your host does not trust the CA certificate of the firewall which is used to create the new certificates for the intercepted SSL connections.

  3) Is there any flaw in this situation? For example: can I use this certificate in order to try a MITM attack?

Anybody who has access to the private key of the CA certificate can MITM the connection.

  4) Windows users don't need to import this certificate, whilst Linux users do. Linux users need to authenticate every 12 hours, whilst Windows users don't. May someone write something to explain what's going on here?

With windows the proxy CA  certificate is automatically propagated to all machines using a policy. And there is probably some process to which maps an IP address to the user currently logged on the machine so no manual login is necessary.

  .. Given the fact that I have the certificate,
  A) can I "extract" (or export or get or whatever) the private key from it?

No. You have the certificate only. This includes the public but not the private key. The is the same with all the other CA certificates you have on your system or in your browser: they are used to verify a certificate only which is done using the public key in the certificate.

For more information about such firewall based MITM see Can my company see what HTTPS sites I went to?


Strange google gmail activity logs So I was reviewing the recent activity logs on my GMail account and came across an IPv6 address:

United States (IL) (2607:fb90:1704:602f:4b7d:75c3:d50f:2fd4)

I live in another state, so how can this be possible if the type was of mobile access. When I look at ARIN search I get:

http://whois.arin.net/rest/net/NET6-2607-FB90-1/pft

T-Mobile is accessing my GMail account? Is that weird or no?

Updates:

Yes, I have T-Mobile as my phone provider.
Everytime I access GMail from my phone, it lists the correct IP of my state, the ones from Illinois are from completely different days.

I figured it out, when you are connected to a wireless AP the gmail applications default to using the better connection so it uses the routers located here with their IP.

When I m connected to the T-Mobile network I send it over to the company in Illinois.

I know it seems self evident but both my work and home connections are remembered on the phone and there's no where else i use it much so it makes sense to see the sporadic dates associated with that IPv6.

Still interesting to know where my data goes when I'm connected to their network.


Is knowing the salt a problem? I understand that adding a salt would thwart the use of rainbow tables.

I don't understand the time it would take to create a rainbow table for a certain salt and of course this is dependent on the password size limit you use, the salt size, the hash method and also the computational power. Therefore this question could just be irrelevant.

However, theoretically if someone had access to all salted rainbow tables for all passwords up to x characters and the salt up to x characters and the attacker knew the salts then this would make it possible retrieve the passwords wouldn't it?

The value of salt is not in its secrecy, it's in its differentiation and the added complexity. You've touched on this a bit.

First, two passwords hashed with different salts have different resulting hashes. Therefore, an attacker cannot look at a password table and discover users who share the same password.

Second, as you write, a rainbow table could be pre computed for a large set of password inputs, allowing fast, O(1) time, password recovery. However, this is often for unsalted passwords.

Third, the salt for a password hash is unique to that hash and should be the same size (bit length) as the hash algorithm. A single rainbow table is the size of all password inputs. Assuming 8 character passwords, case sensitive alphanumeric plus symbols (let's say 10 extra) so that's 72 characters. 8*log2(72) is about 50 bits. So, the rainbow table storage for sha-1 hashed passwords is 50+160 or 2^210 bits.

At 2^202 bytes of storage, that's already larger than all the current storage on the planet. I think we can conclude two things: 1) not all passwords are placed in a rainbow table and 2) unsalted rainbow tables are already fairly large.

Now, creating rainbows for every possible salt means requiring 210*160 or 2^33600 bits of storage. Where to put all that data (other universes) pales in comparison to the time required to create them (beyond the end of our universe).

Rainbow tables per salt ain't going to happen.

The proper attack is to capture the password database and run a dictionary attack against individual entries using the non-secret and password specific salts.


Lock-down/Always-on VPN recommendation? I'm trying to create a design for a secure machine, basically a Microsoft PAW, however this machine needs a VPN for use while in a home office. It will essentially only be a "clean-source machine" to further remote to a VM with tools within the work location.

Setup:

The PC is to be used for doing admin tasks on on-premise servers by RDP'ing to a virtual admin-desktop as a jump host.
The PC should NOT reach ANY online service. ever... (updates it should get from WSUS and other services in the on-premise network after its connected).
VPN server will be placed behind the same firewall as the virtual desktop.
User of the PC will be normal user only, with no local admin rights.
Users have the skills to take shortcuts (if found) to bypass security measures.

Q1:
What VPN software (server/client) would you recommend to be installed (maybe preferably as a service on the client), to create an always-on connection?

Q2:
Are the proposed solution safe from user tampering? I.E. would the user be able to change configuration files etc. and gaining access to other servers of similar server software?

Q3:
Is using the Windows Firewall as a"Kill-switch" or "Lock-Down" a workable way to go, if blocking everything except the VPN software exe, or maybe better, the IP to the VPN server?

Q1:  I'll echo this same question.  The closest I have found is Microsoft Direct Access but I haven't dug in to see if it is a viable solution.  Maybe that will get you started on the right path?

Q2:  If the user(admin) has admin rights to the PAW, nothing is safe from tampering.  You will need to configure the PAW so the administrators using it do not have administrative rights to it.

Q3:  I'm reaching here because I just don't know for sure, but I think if you use Direct Access you can force all network traffic to go through the VPN connection.  what you are trying to prevent is called "split-tunnel" where VPN traffic is only used for IP addresses associated with your org and everything else goes out the home internet...this is bad.

I hope that helps some even if it isn't a complete answer!


Does HTTP Strict Transport Security (HSTS) make any sense in server to server communication? We occasionally get findings for not having HSTS enabled on our HTTPS interfaces, but since these interfaces are server to server only, would enabling HSTS make any difference security wise?

Why HSTS?

The weakness HSTS is designed to protect against is clients that first connect to a server by making a request over HTTP, and are expected to be redirected to the HTTPS version (or a 404). An attacker can MitM that request and instead of sending the redirect send the (possibly modified) site over HTTP.

Connections over HTTP can be opened for many reasons:

Attacks like SSL-strip.
People entering the HTTP address into the URL bar
Hardcoded links to HTTP.

Do any of these affect a server? The third one might, but it depends on whether you have full control of all the software that connects to your server or not.

If you have full control

Just make sure all URLs that are ever used are to HTTPS. If they are read from a config file, explicitly check that they are not HTTP. This eliminates the need for HSTS. While you are at it, you should make sure you only accept secure cipher suites and perhaps think about implementing certificate or public key pinning.

If you do not have full control

Let's say other people write software that connects to your server. You do not know if these people know what they are doing. They might accidentally make a HTTP request somewhere.

If the libraries they use actually interpret and enforce HSTS headers (it is the client that is responsible for enforcing HSTS) these people would be more safe with HSTS turned on. But it is still sort of an edge case - if you give 404 answers and not redirects on HTTP requests it is hard to imagine why anyone would write software that makes them. I also suspect most libraries ignore the HSTS headers. But who knows!


What is the (literally) lightest way to run a second secure system? My goal is to have two separate systems where one is secure even if the second one is full of malware. My current approach is to have two separate laptops and the only way these two communicate with each other is by sending text messages (no files) to each other via email - this kind of minimal text-based communication is a necessity.

I will travel a lot and thought about how I could lighten my pack.

Option 1: Since it is easy to swap out the SSD on the more powerful laptop, I could simply carry two SSD drives (one with the secure system and the second one with the less secure system). What I think I know: The two drives share the RAM and the BIOS. They also share the input devices, the display and a number of other hardware modules but I guess that is less relevant here. Did I overlook anything here?

Option 2: Same as option 1 but I would boot into the "secure operating system" from a USB stick while the less secure hard drive is still plugged in. This would be less effort but would it provide the same level of security?

Option 3: Same as option 1 but I would swap out the RAM also.

Option 4: Allow a raspberry pi to use the display and the input devices of my laptop without "getting in contact" with the RAM, the hard drive etc of my Laptop. Is that possible?

My questions are:

a) Is there another option? Which option provides the best balance between security, weight savings and least (one time and ongoing) effort?

b) For the option you would suggest: What are the remaining security holes? How rare/difficult would a successful attack be and how does the security level compare to the existing baseline security (the "secure system" is online and receives text-based emails from the less secure system - I can not change this)?

You could actually do what you proposed, but they are a pain in the ass, Ok, except 2, this is not that big deal and I actually use it as well for carrying portable desktop in hostile environments. The thing is you can do some more things, which, in my point of view, will give you greater flexibility.

Don't get a USB for live boot, get an external hard drive, install an OS normally, encrypt it all and enjoy full functionality (preferentially Linux).
If you get to use a live USB, use an amnesiac OS LIKE Tails Linux and save anything you want directly to an external drive.
Use virtual machines. One laptop, one physical drive. You can choose many different ways to make your host system communicate with a VM and you can also encrypt the vms' virtual drive. That way you can actually choose which will be the secure OS and which will be full of malware (use the VM for that reason - that's how malware analysis is usually done btw). It will save you money and carrying weight.
Get 2 laptops
Make great use of that raspberry you mentioned. I don't know any way you can use your laptops' hardware on you rpi, but you can get a big power back, an external screen and a set of mouse/keyboard and have a very handy and light system ready to roll EVERYWHERE! No joking, this is the best thing i ever created and I'm traveling with this when I know I won't really need my laptop but may need a terminal.


For zero-deployment via GitLab Piplines - What kind of unix User? I want to implement a zero-deployment strategy for my websever.

My first attempt was to create a specific user (deployer) for that:

# Create user deployer
sudo adduser deployer
# Give the read-write-execute permissions to deployer user for directory /var/www
sudo setfacl -R -m u:deployer:rwx /var/www

With GitLab and some tutorials like this or this, I try to automate the process of deployment.

However, I got stuck because my user deployer needs sudo rights to fire some specific commands.

Now, I wonder can this be an issue? Because I give gitlab the private ssh key to the user deployer, so gitlab can connect to the server.

Because theoretically gitlab can be hacked and therefore my sever as well.

What do you think? Or is the risk so small so I don't need to worry.

The basics
Yes, if you store access credentials for your server in Gitlab, and Gitlab gets hacked, then your server may get hacked.  If the user who is deploying your application needs root access, then you have no choice but to give root access to gitlab (or adjust your application so root access isn't necessary).
User access level
You seem to be specifically concerned about giving Gitlab root access to your server.  While that certainly should be avoided if possible, this isn't necessarily the largest concern.  After all, if the only thing your server does is host your application, then someone who breaks in as the deployer user already has access to everything of interest.  At that point in time making the user root as well doesn't really make it that much more dangerous.
The next step
In an ideal world it wouldn't be a question of "servers" anyway.  For instance, if you are running on a dedicated server somewhere then having root get compromised can certainly be a pain.  However, if you go a step farther along and are having a VPS or a Kubernetes cluster provisioned from (say) a Docker image, then having any one "server" compromised is less of a hassle.  You simply fix up the root issue that caused the compromise and re-deploy on brand new "servers".  Obviously breaches are always bad and I'm not trying to say otherwise, but my point is that in well run infrastructure there can be much less concern about "servers", which is a good thing.
Should you put access keys in Gitlab?
Whether or not the risk of having your Gitlab account compromised is something you should worry about is a question that only you can answer.  Here's the question you need to ask yourself: "Is the benefit of automating my deployments worth the additional risk of my server being compromised?"
This is effectively a simple risk assessment.  Of course to answer that you need to know the likelihood of a compromise, which is harder to answer.  To be clear though, Gitlab itself being hacked is (IMO) less likely than security mistakes on your part, i.e.:

Make sure you are using a strong unique password on Gitlab
Enable a secure 2FA account
Make sure you follow best practices regarding storing secrets for CI/CD scripts

Also keep in mind that this is only one of many possible ways a server can be compromised.  Making sure that your CI/CD pipeline is well secured is only one priority, and if at the same time you have an open FTP server running on your server, or your application isn't following the basics of application security, then you have bigger fish to fry.
In the end though, only you can decide if this extra automation step is worth the increased risks for you.


Metadata-free Email: How can SENDER directly, anonymously, and securely ask RECIPIENT’s mail provider to deliver a metadata-free email? If I want to send emails to friends who use Google, Yahoo, AOL, etc., how can I currently use my local email client to send a metadata-free* email to them?

E.g., is it possible to bypass my own mail provider and directly contact my friend's mail server with an encrypted mail with only one identifying header, TO: friend@mail.com? Upon decryption, they realize it's FROM: me@mail.com, sent at TIME, with SUBJECT: subject.

*Metadata-free means the only devices that know SENDER (IP address, username, etc.) contacted RECIPIENT are devices that belong to SENDER or RECIPIENT. An anonymous email account does not pass this test and is thus vulnerable to analysis of its email contacts and traffic.

Would self-hosted mail servers help in any way?
Is SMTP the bad guy making this idea impossible?
Are mail providers the bad guys?

All help appreciated!

Reviving a forgotten question

Nearly all mail servers in today's world are configured to throw out messages which fail to include that information.  The primary reason is simply to prevent spam.

The third best thing you could do is if your friend had their own mail server and you have an account on that server as well.  In this case your client would connect directly to their server and the transfer would be within that same machine.  However the mail server should also be configured to only allow secure connections (ssl/tls) as well.

The second best is to not use email at all but rather use a chat or voice type program that can establish a direct connection between your two machines using encryption with a pre-shared key that wasn't transmitted in the clear.  Of course, traffic monitoring would show that data was transferring between you and your friend even if the contents were hidden.

However, if you are truly paranoid, the best thing is to just talk to them in person by whispering directly in their ear... while in a room that is shielded from all outside means of snooping.  Then again you'd need assurances that your "friend" wasn't going to share the contents of the conversation with a third party AND for anyone actually watching your movements they would still be able to know you two met each other.


Allowing a website MIDI access from Chrome A video website that I occasionally use has gone mute. I received this prompt to give this website MIDI access:

Is this safe to grant? Youtube and other websites do still play sound without any special permissions, but I'm not sure what the risks wold be if I allow this.

It is mostly safe, unless a new exploit has been found recently.

You're right to worry. There have been exploits using MIDI, like this one in Windows, and this one in Chrome, both of which were particularly nasty. They've both been patched for some time, but you never know when a new attack will be discovered.

Personally I wouldn't allow it unless I really wanted to hear the music-- and given that it's MIDI and not WAV or MP3, it is probably pretty horrible.


Ways to keep AES encryption key safe.? I am using AES encryption to secure some sensitive data. For that i have to provide a certain key for encrypting and decrypting.

It's not safe to keep the key somewhere on the server. So instead of entering the key directly, I would like to convert the key and later convert it back again to it's original when entering it while encrypting or decrypting the value.

I thought of doing the key conversion via PHP. Is it a good practice or are there any other suggestions?

Depending upon your budget, you may want to look as a hardware security module. This would be a device connected to the server which stores the key and does encryption, it not part of the operating system and it would more or less be like magic black box.

You could also use another server which has the sole purpose of doing crypto, and again functions as a black box. With a very tight firewall config and other checks, this may also be effective.


Will Veracrypt work on a LUKS encrypted system? I have LUKS disk encryption on my linux installation. I would like to encrypt files on a usb by using Veracrypt. Will having Veracrypt installed on top of my LUKS installation have any bad effects? Will it work properly?  Will both the standard volume and hidden volume options work properly? And lastly is doing this secure and private? Or should I just use LUKS to encrypt usb flash drives?

You can encrypt your USB drives using Veracrypt for as long as you install Veracrypt software on your Linux (so you would be able to access them from Linux).

You are using LUKS to encrypt partition(s) on your hard drive but once you boot-up the system, you can work on it just as it was not encrypted and use Veracrypt.

You need to distinguish the difference between the system/partition encryption and file/container/folder encryption. First is LUKS (I know, you can use Veracrypt to do it, but since you have your system encrypted by LUKS, there is no point to encrypt it again with Veracrypt), the second is Veracrypt - very good for file/container/folder encryption on a host system or portable drives. It is important to remember, that you would need to install Veracrypt OR put portable package along with encrypted files on any system that would need to access your portable (for instance USB) drives. You would also need admin rights on these systems to use portable package.
You can copy the encrypted containers wherever you like.

LUKS has nothing to do with your USB drives, Veracrypt has, you can encrypt them with any Linux compatible software you like. You can even encrypt files you keep in the cloud to protect them from being viewed by unauthorized individuals (in case of security breach) or personnel of your cloud provider.

Both types of volumes will work fine and yes, it is safe.


Spoof IP address after a TCP handshake established Is it possible to spoof the IP once a TCP handshake was performed successfully?
For example:

Perform the handshake

Use the session with the same IP which performed handshake but on
different machine and network then send a request e.g POST HTTP request

The response is delivered to the spoofed IP and processed by server

Thanks in advance!

Certainly! If you're able to spoof valid sequence numbers this is in possible. This is essentially the TCP Sequence Number prediction attack:

The attacker hopes to correctly guess the sequence number to be used by the sending host. If they can do this, they will be able to send counterfeit packets to the receiving host which will seem to originate from the sending host, even though the counterfeit packets may in fact originate from some third host controlled by the attacker.

That's also why there's been a push to ensure that sequence numbers are hard to determine for an outsider.


Most secure way to isolate computer on network I handle personal client information. Stuff that shouldn't get lost.
Because of this, I have had to be careful not to download or install anything that is in any way uncertain. One data stealing virus on my computer could essentially affect all of my clients. I use PDFs, Microsoft Word and Excel for storing the information, and Firefox for communicating with clients via email.

This is a problem, as I've come to a point that I have to test out several pieces of software that do fall into that uncertain category.

To keep my clients' data completely separate from the software I will be testing, I can set up a second computer.

Worst case scenario the testing computer gets hacked.

If they both connect to the same internet line, what can I do to prevent it from doing anything to any other computer on the network?

I agree with Neil Smithline that you should clarify the parts you are having trouble with, but I think i understand enough to give you a few answers.

For separating your computer from the rest of the network, look at setting up a hardware based firewall on your network.  I know of Fortigate and Zyxel Firewalls (Note: it takes time to learn how to configure these well).  Both can be configured to separate or treat your computer differently when it comes to internal and external traffic.  They are very complex though, so it can be a difficult learning curve.  Also it can leave holes or other issues if not configured properly, so it can be overkill.  Just an idea though, in case you want to try it out.

Anything past that is getting into good IT common sense 101.  Such as with AV/Malware scans, encrypting hard drives, configuring software AV/Firewall, and possibly other things that count more as opinion rather than best practice.

So as far as keeping client data separate, all you can do is make sure your work computer is separate from your personal computer, and make sure what you do on your work computer is controlled and monitored.  That part will be up to you, because there isn't just 1 answer (hence why Neil suggested to be more specific).


Security Audit on AWS - question on findings Just wondering about an assessment I'm doing regarding a client's AWS environment.
I'm new to AWS to I'm having to learn a lot on the go.
I used ScoutSuite and got some findings, specifically:

EC2:
*Security group whitelists AWS CIDRs*

IAM:
*Inline group policy allows iam:PassRole *
Inline role policy allows iam:PassRole *
Inline role policy allows sts:AssumeRole *
Managed policy allows iam:PassRole **

The tool doesn't provide any rationale about why these findings are relevant and what they are. Just wondering if anyone has any opinions if these are even findings worth reporting or the rationale behind them.

The EC2 findings refers to: AWS Security Group for your EC2 instances have an unknown or too permissive CIDR origin allowed for inbound/outbound traffic. This audit rule expects another Security Group reference as originator or destiny of the traffic that pass through it.

When an unknown CIDR is found, the Unknown CIDR caption is added to the report, which facilitates detection of EC2 security group rules that whitelist network traffic from untrusted IP ranges.

ref-link-1: https://github.com/nccgroup/Scout2/wiki/HowTo:-Use-with-a-list-of-trusted-CIDRs

=========================================================

The IAM findings refers to: IAM Role Policy Too Permissive

Inline group policy allows iam:PassRole
Inline role policy allows iam:PassRole *
Inline role policy allows sts:AssumeRole *

NOTE: You've probably set an IA policy something like the ones show below

"Statement":  [
{
  "Action": [
    "iam:PassRole",
    "iam:AssumeRole"
  ],
  "Effect": "Allow",
  "Resource": [
    "*"
  ]
}
  ] ,
"Version":  "2012-10-17"

"Statement":  [
{
  "Action": [
    "iam:*"
  ],
  "Effect": "Allow",
  "Resource": [
    "*"
  ]
}
  ] ,
"Version":  "2012-10-17"

Ensure that the access policies attached to your IAM roles adhere to the principle of least privilege by giving the roles the minimal set of actions required to perform successfully their task.

Providing the right permissions for your IAM roles will significantly reduce the risk of unauthorized access (through API requests) to your AWS resources and services.

PassRole: To pass a role (and its permissions) to an AWS service, a user must have permissions to pass the role to the service. This helps administrators ensure that only approved users can configure a service with a role that grants permissions. To allow a user to pass a role to an AWS service, you must grant the PassRole permission to the user's IAM user, role, or group.

AssumeRole: A trust policy for the role that allows the service to assume the role. For example, you could attach the following trust policy to the role with the UpdateAssumeRolePolicy action. This trust policy allows Amazon EC2 to use the role and the permissions attached to the role.

ref-link-2: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html

AWS Security Audit Open Knowledge bases:

kb-link-1:
 https://www.cloudconformity.com/conformity-rules/

kb-link-2:
 https://github.com/cloudsploit/security-remediation-guides


Is it possible to know imei number of other mobile using any sort of wireless technology? Are there methods to grab imei numbers of mobiles irrespective of smart or ordinary using Bluetooth or similar wireless technologies.
Case : other mobile may not have Bluetooth or possibly switched off...

Note : this information is being collected for finding solution to a problem.

Businesses that are worried about mobiles being used in unauthorised places uses technology that might be useful to you.

I wrote an answer on the Academia StackExchange with some products but I think only AirPatrol (though I note on the site AirPatrol now says they don't collect IMEIs, check with your sales rep) and Libelium will be relevant. Some of these you can buy multiple sensors to work out which "zone" the mobile device is being used in.

These will typically list the IMEIs of broadcasting devices and as they do not interfere with them or broadcast on licensed spectrum themselves I believe are legal (but IANAL). Still I'd be surprised if they were illegal to operate given they sell them!


CSRF on anonymous forms We have a site which has a form on it asking for a piece of information (a state, selected from a dropdown - which changes the screens returned). Anonymous users interact with this form.

When we scan this site with Acunetix, it reports that the form does not have CSRF protection. My question is, does it need it? I thought we only needed CSRF tokens for logged-in users, and in cases where the form can modify data on the backend?

No, you don't need CSRF token

Csrf token is used to certify a request is approved by a user. If there is no gain between sending this request by your own and sending this request being another user on the network, Csrf is useless.


Hardening a asymmetric key based authentication process The process involves two interested parties A (client) and B (server) and the attacker M. M is capable of intercepting all the communication between A and B (Man in the Middle) and even modify it. However A's private key has not been compromised.

Success of authentication process depends on A's capacity to sign an arbitrary packet sent by B with it's private key.

The authentication process proceeds as following:

A establishes TCP connection with B.
B calculates a nonce and associates it with the incoming connection from A.
B already has A's public key.
M connects with A.
B calculates a nonce and associates it with the incoming connection from M.
M initiates authentication process, B generates a new nonce based on the nonce generated in step 5 and some internal state and sends it to M.
M sits idle and waits for A to initiate the authentication process.
A initiates the authentication process, B generates a new nonce based on the nonce generated in step 2 and some internal state and sends it to A.
M intercepts the communication B -> A in step 8 and replaces the nonce with the one it received in step 6.
A signs the the packet and sends back to B.
M intercepts the packet A -> B of step 10, blocks it from going through and replays it as it's own.
B verifies the nonce and the signature and identifies M as A.
M masquerades as A.

What can be done to prevent M from becoming A in eyes of B?

My understanding is that both A and B have a private key that is incorporated into the final shared key at both the beginning and end of the handshake process.  This means that if you try to jump into the middle of the handshake, that you will still be lacking A's private key.  So, while you can trick B into thinking you are A, the data you get will still be encrypted and you will not have A's private key to be able to finish the decryption.  Since you can't decrypt it, you can't change it to any new meaningful values even if you successfully make yourself the man in the middle.

The real issue comes into play when you can trick A into thinking you are B because then you can pose as a fake version of B long enough to collect login credentials, then pass them along to the real B.  That way you can login as A with a new connection using your own private key.  The only thing I know of that would sort of prevent this is to have B send A a verification method the first time you connect that is able to verify that B is B, but that is not always practical depending on your use case.


Is my .pfx file a keystore I have a .pfx containing my server certificate for the HTTPS server, and the private key, protected by a password.

Can we say that this file is a keystore?
When I search keystore I only find articles about Java keystore.

Yes, a PFX file (which follows the PKCS#12 cryptography storage format) such as the one you have does contain a key so it would be a keystore.

You can use PKCS#12 files natively as a keystore for most crypto implementations - for instance for its usage as a keystore in Java see the accepted answer for "Keystore type: which one to use?" for a very illustrative description on the various types of keystores.


How can Authy use Google Authenticator QR I was just reading around and found it really fascinating that Authy can use Google Authenticator implementations anywhere.

How does Authy does this? Isn't this a security risk?

The use of apps other than Google Authenticator is not, by itself, a security risk, provided you trust those apps.

The purpose of 2FA is to prove that you have some physical object (in this case, your phone), in addition to knowing something (the password).  This makes it more difficult for an attacker to compromise your account, because they are less likely to simultaneously know your password and have your phone.

The TOTP protocol used by Google Authenticator basically works like this (for full details, see RFC #6238):

You scan a QR code which contains some secret.  The site provides this secret to you, and also stores it server-side (preferably encrypted, in an HSM, or in some other "reasonably safe" storage; RFC #4226 has some interesting discussion of the difficulties here).
When you need a new one-time-password (OTP), you perform some cryptographic operation (an HMAC) based on the secret and the current time.
That cryptographic operation produces a value which can be converted into an OTP.  You provide that OTP to the website, which generates an OTP by the same process.
If your provided OTP matches the OTP which the website generates (or the OTP it would have generated a few time steps into the future or past, to allow for clock skew), then it is accepted.  Otherwise, it is rejected.

This is an open standard, and by design, anyone can implement either half of it (client or server).  However, a malicious client implementation could hand the secrets over to an attacker, who could then impersonate you for 2FA purposes, so you should only use client apps which you trust.

All that being said, I have some pretty strong reservations about Authy in particular.  When I last investigated it, it stored the secret from step (1) in the cloud by default.  This is intended to be for convenience, so that if you lose or replace your phone, you won't have to reconfigure TOTP on all of your accounts.

But it also means that you are defeating the core purpose of 2FA: You are no longer proving that you both have something and know something.  Instead, you are proving that you know something (your password), and have authenticated with someone else (Authy's cloud storage).  This is a weaker security model because it makes Authy a point of failure for all of the other sites.


What is the status of Certificate Transparency? I am reading a bit on the certificate transparancy project initiazed by google. (More info at http://www.certificate-transparency.org), this technology tries to introduce transparency in the creation of CA certificates. Their goal is that all SSL Certificates would be logged in multiple, publicly available logs run by independent companies and that browsers would only provide trust to certificates that are logged. Domain owners and interested parties would monitor the logs to detect certificates that were either misissued by the CA or not actually authorized by the organization (source).

I can't find a lot online on the adoption of this technology, is it really a game changer that in the future will prevent hacks like the digicert incident? Or is this just an initiative that isn't widely adopted?

http://www.certificate-transparency.org/known-logs

As of today (January 25, 2018), adoption of Certificate Transparency is not ubiquitous, but it is starting to gain momentum. Let's Encrypt logs all their certificates to CT logs, and several major CAs like DigiCert and Comodo run their own CT logs. Google Chrome already displays Certificate Tranparency information in its Dev Tools, and Firefox plans to add support in the near future.

Starting in April 2018, Google Chrome plans to start enforcing the use of Certificate Transparency in all newly issued certificates by refusing to treat them as valid unless they're included in at least two distinct, qualified Certificate Transparency logs. Once that happens, Certificate Transparency adoption will undoubtedly take off rapidly, as very few site operators will be willing to use a certificate that is not trusted by Chrome.


Detecting POODLE and BEAST using nmap Need your expert advice for the following -

POODLE - We can deduce if a server is vulnerable to poodle if it
supports sslv3  protocol and uses CBC Ciphers.
BEAST - Any server supporting sslv3 OR TLS 1.0 and uses CBC
Ciphers.

Is my understanding correct? I understand these attacks are exploited on client side but still if a server can be made vulnerable by any means it is vulnerable.

Now, comes the detection part - AFAIK server does not send the complete list of cipher suits to
    the client but only sends the selected one based on the cipher suits
    presented to it by the client.

Now, using nmap ssl_enum_ciphers script we can list the cipher suites used by server.

This is what nmap documentation says about ssl_enum_ciphers script:

This script repeatedly initiates SSLv3/TLS connections, each time trying a new cipher or compressor while recording whether a host accepts or rejects it. The end result is a list of all the ciphersuites and compressors that a server accepts.

Some servers use the client's ciphersuite ordering: they choose the first of the client's offered suites that they also support. Other servers prefer their own ordering: they choose their most preferred suite from among those the client offers. In the case of server ordering, the script makes extra probes to discover the server's sorted preference list. Otherwise, the list is sorted alphabetically.

So, if the server's preferred cipher is RC4 and client provides a CBC cipher (Only one) will it select CBC or rejects the request?

If it chooses CBC then ir-respective of the cipher ordering (nmap's output) then it is vulnerable (?).

If it chooses from client's ciphersuite ordering then definitely it is vulnerable (if it accepts CBC cipher) (?).

Based on above statements, can we infer the following -

If server supports sslv3 and we have a CBC cipher anywhere in the
cipher list given by nmap, can we say that the server is vulnerable
to POODLE?
If server supports sslv3/tls 1.0 and we have a CBC cipher
anywhere in the cipher list given by nmap, can we say that the
server is vulnerable to BEAST?

What i am trying to understand is that based on nmap's output can i infer if it is vulnerable just seeing if it contains CBC cipher or is there any other sophistication involved?

So, if the server's preferred cipher is RC4 and client provides a CBC cipher (Only one) will it select CBC or rejects the request?

If the server supports the CBC cipher that the client provides, the CBC cipher will be used. Otherwise, the connection will fail.

  If it chooses CBC then ir-respective of the cipher ordering (nmap's output) then it is vulnerable (?).
  If it chooses from client's ciphersuite ordering then definitely it is vulnerable (if it accepts CBC cipher) (?).

Every SSLv3 connection to this server using CBC cipher will be vulnerable to POODLE. For BEAST it is a bit more complicated as browsers may implement client-side mitigation.

  i) If server supports sslv3 and we have a CBC cipher anywhere in the cipher list given by nmap, can we say that the server is vulnerable to POODLE?

No. To be vulnerable to POODLE, the server must have support for a CBC cipher using SSLv3. If the server only supports RC4 with SSLv3 and CBC ciphers are only supported using TLSv1+, it won't be vulnerable to POODLE.

  ii) If server supports sslv3/tls 1.0 and we have a CBC cipher anywhere in the cipher list given by nmap, can we say that the server is vulnerable to BEAST?

Yes, but BEAST attack is not anymore a problem as every modern browser implements client side mitigation of the attack.

  What i am trying to understand is that based on nmap's output can i infer if it is vulnerable just seeing if it contains CBC cipher or is there any other sophistication involved?

Finally, yes:

SSLv3 + CBC = POODLE and BEAST
TLSv1.0 + CBC = BEAST

Example 1, the following configuration is only vulnerable to BEAST with TLSv1.0 if one of the CBC cipher suite is used:

PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack
| ssl-enum-ciphers:
|   SSLv3:
|     ciphers:
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.0:
|     ciphers:
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: C

Example 2, the following configuration is only vulnerable to POODLE and BEAST on SSLv3:

PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack
| ssl-enum-ciphers:
|   SSLv3:
|     ciphers:
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.0:
|     ciphers:
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: C

Example 3 from nmap documentation, the configuration is vulnerable to POODLE on SSLv3 and BEAST on SSLv3 and TLCv1.0 is a CBC cipher suite is used:

PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack
| ssl-enum-ciphers:
|   SSLv3:
|     ciphers:
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.0:
|     ciphers:
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: C


CSP Violation ms-appx-web:// We have a java application which allows users to upload attachments and save it on the server. The application has a content security policy defined like this:
base-uri 'self'; child-src 'self'; form-action 'self'; frame-ancestors 'self'; connect-src 'self'; font-src 'self' https://fonts.gstatic.com; frame-src 'self'; img-src 'self' http://www.google-analytics.com https://www.google-analytics.com https://ssl.google-analytics.com data:; media-src 'self'; object-src 'self'; script-src 'unsafe-inline' 'unsafe-eval' 'self' http://www.google-analytics.com https://ssl.google-analytics.com; style-src 'unsafe-inline' 'unsafe-eval' 'self'; default-src ASTERISK;

Recently we got a CSP violation which is -
<CR>csp-report:<CR> Referrer: <CR> Blocked Content Source: ms-appx-web://<CR> Violated Directive: font-src 'self' https://fonts.gstatic.com<CR> Effective Directive: font-src<CR> Status Code: 200<CR>

Can someone help me understand what is ms-appx-web and why did it come out to be the blocked content? Why does the CSP say that font-src is violated?
I have the below understanding -
Allowed fonts are the ones which are inside the application- "SELF" and from "https://fonts-gstatic.com" .. for some reason  the user tried to attach a pdf document having a font not supported by application/google fonts. That font may be defined in windows i.e. ms-appx-web://
Is the above correct?

ms-appx-web:// is an internal scheme of Edge for browser plugins, it's not a subject of CSP regulation. It's just an error in some Edge version or in the some plugin/extension.


I am signing (HMAC) outgoing webhooks to allow users to verify their source, should I also sign outgoing responses? To allow api users to verify the authenticity of outgoing webhooks, I am using a similar model to slack:

Concatenate timestamp and body, HMAC with pre-shared key, add timestamp and HMAC digest to headers.
Recipient does the same, and compares to the digest in the header.

I can either implement this exclusively on outgoing webhooks, or I can implement it as middleware that performs this process on both outgoing webhooks, and responses to requests.

Is doing the latter good practice? A good idea?

This is a bad idea.

You are essentially (ab)using symmetric cryptography to implement asymmetric cryptography. In your approach, the following problems will arise:

If you only have one key, then every client you distribute the key to can effectively impersonate you
If you have one key per client, you need to worry about key generation, storage, exchange, deprecation, etc.

A much better idea would be to use any asymmetric cipher (Elliptic Curves, RSA, etc.). The scheme would then work as follows:

You generate a private and public key pair, and distribute the public key.
You sign the timestamp and body, then send it off to your client(s).
The client(s) use your public key to verify the signature, and thus both the authenticity and integrity of the message.


Which part of a self-signed certificate can be trusted? I want to ensure the sender of Document B is the same person as who previously sent me Document A. Both documents are signed with self-signed certificates. I'm not interested in knowing the real-world identity of the sender.

When I open the self-signed certificate with a certificate viewer, it shows the certificate's subject, issuer, serial number, subject key identifier, public key (very long gibberish), SHA1 digest of public key, X.509 data, SHA1 digest (of what?), and MD5 digest (of what?).

I know the issuer of the self-signed certificate can put arbitrary things into (i.e., fake) "subject," "issuer," "serial number" fields, so they are meaningless. But I don't know anything about other fields.

If the certificates contained in those two documents have, for example, exactly same "SHA1 digest of public key" string, does that mean they are indeed signed by the same person? Can an attacker fake it?

Public and private keys are linked in such as way that if two certificates have the same public key, they were created using the same private key.

So if you assume that the private key is indeed kept private, the part you can trust in the certificates to identify the creator is the public key, and by extension the digest of the public key.


Question about a "Password Space" definition I am currently reading the "Green Book" (http://csrc.nist.gov/publications/secpubs//rainbow/std002.txt) of the "Rainbow Series" and have a question on chapter "C.4 Password Space".

From this chapter:

S = password space

A = number of alphabet symbols

M = password lenght

S = AM

To illustrate: If passwords consisting of 4 digits using an alphabet of 10 digits (e.g., 0-9) are to be generated:

S = 104

That is, 10,000 unique 4 digit passwords could be generated. Likewise, to generaterandom 6-character passwords from an alphabet of 26 characters (e.g., AZ) :

S = 266

That is 3.089 * 108 uniques 6-character passwords could be generated.

My question:

I thought that the 10 000 is the solution of 10^4 (because there is an alphabet of 10 and we have a password consisting of 4 characters). Anyway as we see in the next example there we have 26 characters and a 6-character password -> how do we get "3.089 * 108"?

I would be very glad, if someone out there has an answer for that question. Thx in advance ;)

The Answer to my own question:

Unfortunataly the official source posted in my question is not formatted very well.
The corrections are:

S = AM -> should be formatted like this S = A^M

Therefore further formatting changes:

S = 104 -> 10^4

S = 266 -> 26^6

3.089 * 10^8

The answer

"3.089 * 10^8" is correct in scientific notation but it doesn't represent the exact result which is 26^6 = 308.915.776.

Thx @ Tom Leek who answered my question too.

It is a mere typographic problem. The document is in ASCII text but was obviously converted from another format, probably automatically, and was poorly reviewed afterwards. All the "exponents" suffered. Let's put it right:

  Password length and alphabet size are factors in computing the
  maximum password space requirements.  Equation [2] expresses the
  relationship between S, A, and M where:

  S = password space
  A = number of alphabet symbols
  M = password length

  S = AM    [2]

  To illustrate: If passwords consisting of 4 digits using an alphabet
  of 10 digits (e.g., 0-9) are to be generated:

  S = 104

  That is, 10,000 unique 4-digit passwords could be generated.
  Likewise, to generate random 6-character passwords from an alphabet of
  26 characters (e.g., A-Z):

  S = 266

  That is 3.089 * 108 unique 6-character passwords could be generated.

Indeed, 26 raised to the power 6 is equal to 308915776.


Should I use Suhosin for PHP? Suhosin can be used to increase the security of your PHP application. I can really see the use of it when you are using shared hosts, with multiple (possibly evil) people running their PHP apps there.

When you are only having one web app, your own, is there any advantage in using Suhosin?

Personally I always run Suhosin on all my servers.

My main reasons are

Adds sha256() functionality to PHP.
Does some really good stuff in regards to filtering uploads done via PHP.
Disables some of the nasty PHP functions like eval(). Which is good as although you may very well not use it you can never tell what developers will get up to.
Also every other reason listed here is a good enough reason to run it.

Looking at the benchmark results for Suhosin the performance loss is insignificant at least to me.


Using same CSRF token after relogin I am testing a website and observing the following behavior while intercepting and re-sending the request using postman.

CSRF token is generated for each request
User logs out. Generated CSRF token doesn't work
User logs in. A new CSRF token is generated. But the old token is also still working.

What are the security implications this might have?

This looks like a sloppy design to me, that degrades performance by storing more tokens than necessary. But I don't see a security issue.

Why? To bypass the CSRF-filter the attacker would need to know the value of a token. But there is no leaking of that info in your example, just multiple tokens. Only difference is that an attacker has two in a billion instead of one in a billion chance of guessing it right.

One thing to investigate further, though: The CSRF token should be tied to the session. That it still works after login makes me suspicious. Does any CSRF token work with any session ID? Then you have no CSRF protection at all. Or doesn't the session ID change when you login? Then you have a session hijacking problem.


How to get my GNUPG Elgamal private key exponent? I have tried googling around. The closest solution I get is:

private.key contains the private key file.

$pgpdump -i private.key

But this only gives me the following:

ElGamal p
ElGamal g
ElGamal y
Encrypted Elgamal x
some other information of crypto

It shows the value for p,g,y, but not x. How can I find out the value of x?

This indicates your private key is encrypted with a passphrase. pgpdump does not decrypt private keys to display them.

With GnuPG 1 and 2, you can at least export unencrypted subkeys using gpg --export-options export-reset-subkey-passwd --export-secret-subkeys [key-id]. This will also print the secret x part of your key. For GnuPG 2.1, this option was removed.

I'm not aware of a similar option for primary keys without changing GnuPG's source code.


Securing private IP space As we all know, routers that you buy from the store come preset to hand out IP addresses using DHCP, generally on one of three networks: 10.0.1.1/24, 172.16.0.1/24, and 192.168.1.1/24. I personally restrict DHCP to a smaller range and use DHCP reservations based on MAC address to make touching network devices through SSH, RDP. etc. easier. I am about to re-IP my network (to de-conflict it with my lab setup), and I got to thinking, is it more secure to use a random network within the private IP space (e.g. 10.143.97.1/24 or 172.26.248.1/24) than using the defaults that nearly every networking company uses?

I think the answer is somewhere between "maybe" to "no, but it couldn't hurt." While I would think that it would make it harder for someone with malicious intent to get to the router admin page, I also realize that anyone with wireshark can see the source/destination IPs, so they can figure out the network topology (at least the wireless part of it) that way. MAC filtering, a strong passphrase, and encryption all help secure the network, so I don't think using a random network would necessarily help, but I don't see it hurting either.

The security measures which are the primary subject of your question here (MAC filtering, non-standard IP addressing) basically equate to "security through obscurity".  They are very weak against a dedicated attacker, and so should not be relied upon as the only security functions in your system.

That said, even security through obscurity has its place in a proper defense-in-depth approach.  Anything you can do to make it harder for an attacker to compromise your system, while not having too much impact on the usability of the system, may be considered worthwhile.

My own home setup uses all of the things you've mentioned, and then some:

MAC address filtering
Non-standard network ID (doesn't even end in .0)
Restricted (smaller than /24) subnet
Reserved DHCP addresses for all registered devices
WPA2 security on the Wi-Fi network
63-character random-generated PSK
WPS disabled on the APs

Those last three items, plus reasonably strong physical security on the house, are the real things keeping unauthorized users off my network from the LAN side.  As long as WPA2 remains fairly secure, nobody's going to be sniffing my traffic over the air let alone joining my network any time soon.  If there ever comes a time that WPA2 is broken, and a suitable replacement is not available, I'm fairly comfortable that any wireless attacker (unless they are deliberately targeting me personally, or specific data residing on my network) is likely to move on to another victim before they bother trying to get into my network.

The only real down-side to these extra security measures is that it can be a bit of a hassle to get new devices onto the network - especially smartphones and tablets.  For most people, adding a new device goes like this:

Select Wi-Fi network, enter PSK from memory, hit "connect".
(There is no step 2.)

For me, it goes something like this:

Log in to the router's configuration page
Figure out how to obtain the MAC address from the new device.  Add it to the MAC address filter on the router.  If there aren't any slots left in the filter (it seems Linksys routers are limited to 32), pick an idle device to remove from the filter to make room.
Pick an IP address to assign to the device, add it to the DHCP reservations on the router.  If no IPs are free, pick an idle IP to un-reserve and reassign.
If the new device is a laptop or desktop, plug in thumb drive, copy and paste PSK to the new system, click connect.  If it's a smartphone, tablet, or other limited-function device, load the text file with PSK on my laptop, enter the 63-character random PSK manually on the new device, and click connect.  Repeat this step until successful.

So, adding a new device can be tricky - occasionally to a problematic degree.  Fortunately, it's not something that happens often.  Other than this, the added security measures really have no impact on the usability of the network for authorized users.

What do all of these extra measures actually buy you?  Perhaps just a warm fuzzy feeling.  Is it worth it?  That's for you to decide.


Base64 encode diffences in BCrypt implemenations I was reading the source code of several BCrypt implementations and found that two common c implementations have a difference in their base64 encoding of for the salt.

What is the effect, if any, of the differences on line 18 and line 22 of the two base64 encoding implementations below.

Original implementation

/**
 * Original BCrypt implementation
 * http://mail-index.netbsd.org/tech-crypto/2002/05/24/msg000204.html
 */
function encodeBase64_a($input) {
    $itoa64 = './ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
    $i = 0;
    $output = '';
    while (true) {
        $c1 = ord($input{$i++});
        $output .= $itoa64{$c1 >> 2};
        $c1 = ($c1 & 0x03) << 4;
        if ($i >= 16) {
            $output .= $itoa64{$c1};
            break;
        }
        $c2 = ord($input{$i++});
        $c1 |= $c2 >> 4 & 0x0f;
        $output .= $itoa64{$c1};
        $c1 = ($c2 & 0x0f) << 2;
        $c2 = ord($input{$i++});
        $c1 |= $c2 >> 6 & 0x03;
        $output .= $itoa64{$c1};
        $output .= $itoa64{$c2 & 0x3f};
    }
    return $output;
}

OpenWall implementation

/**
 * OpenWall implementation
 * crypt_blowfish-1.2
 * source: http://www.openwall.com/crypt/
 */
function encodeBase64_b($input) {
    $itoa64 = './ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
    $i = 0;
    $output = '';
    while (true) {
        $c1 = ord($input{$i++});
        $output .= $itoa64{$c1 >> 2};
        $c1 = ($c1 & 0x03) << 4;
        if ($i >= 16) {
            $output .= $itoa64{$c1};
            break;
        }
        $c2 = ord($input{$i++});
        $c1 |= $c2 >> 4;
        $output .= $itoa64{$c1};
        $c1 = ($c2 & 0x0f) << 2;
        $c2 = ord($input{$i++});
        $c1 |= $c2 >> 6;
        $output .= $itoa64{$c1};
        $output .= $itoa64{$c2 & 0x3f};
    }
    return $output;
}

Differences side by side:

+------+-------------------------+------------------+
| Line | Niels Provos            | OpenWall         |
+------+-------------------------+------------------+
|   18 | $c1 |= $c2 >> 4 & 0x0f; | $c1 |= $c2 >> 4; |
|      |                         |                  |
|   22 | $c1 |= $c2 >> 6 & 0x03; | $c1 |= $c2 >> 6; |
+------+-------------------------+------------------+

Do the differences have any effect? do they affect compatibility?

There's no difference here. Niels' implementation just goes one step further to verify that the correct bits are set/unset, by using & as a bitmask:

10010111 >> 4 = 00001001 (OpenWall's outputs this value)
0x0F = 00001111
00001001 & 00001111 = 00001001 (Niels' implementation outputs this value)

11010111 >> 6 = 00000010 (OpenWall's outputs this value)
0x03 = 00000011
00000010 & 00000011 = 00000010 (Niels' implementation outputs this value)

Notice that 0x0F masks all but the four rightmost bits, whereas 0x03 masks all but the two rightmost bits. Then consider that the shifts leave 4 and 2 bits remaining respectively, on an 8-bit value.

As such, as long as $c2 is an 8-bit value, the bitmask is unnecessary and the two implementations are equal.


Is there something like DynDNS for a DNS service? I run a small DNS server (pihole) at home behind a firewall, with some custom filtering. It mainly filters ads and trackers, plus some top level domains I want to avoid navigating to. I have an IPv4 address (not fixed) with my ISP and could use DynDNS for HTTP traffic to my home.

Now I would like to use my home-based DNS server on my mobile phone when traveling. How could I possibly do that?

Since the IP is not fixed, I will not be able to provide a fixed IP for DNS resolution. I would need something that gets the IP first. Like DynDNS for DNS.

Does such a dynamic IP resolution for DNS exists?

Note: I would like to not use a VPN connection since I do not need to re-route the subsequent traffic to my home, I just want to use my DNS server.

Note2: I already use noscript and the like in the browser, but I want to get rid of unwanted connections (ads, trackers) in apps too.

You have a chicken-and-egg problem here. To dynamically resolve the IP for your DNS resolver, you need a DNS resolver. Such DNS resolver chaining doesn't exist.

Unless you're going to patch the firmware of your mobile phone for some kind of DNS bootstrapping, you may want to set up a resolver somewhere else, like, on a dedicated cloud instance with fixed IPv4/IPv6 address. AWS, DigitalOcean or the likes provide those for a negligible cost.

To tie that somehow to the information security which is the topic of this SE site: to secure the communication between your phone and your DNS server you should use DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH), because most of the cellular and Wi-Fi networks would attempt to track what sites you visit. Here's how you can set up a DoH server under CentOS 7 in less than 10 minutes.

Another approach would be to set up a VPN server at home, with your DNS server of choice, and connect to the Web services through that VPN. This way you will get your DNS chaining, as well as probably more secure (or, at least, predictable) browsing experience. However, you would need to learn about how to set up an OpenVPN (or IPSec, or whatever you prefer) server, which might take time.


SSL handshake: what makes it unforgeable? I understand the ssl handshake flow, but still need few verifications:

If I'm trying to forge another handshake the client will fail because, and only because the certificate I'll send him back is not trusted?
I understand that the session keys (symmetric) are used to decrypt/and encrypt the data.

Where are those stored in the client?
If I go to a client computer, get this session key, can i decrypt all the data sent to the server? (I mean, isn't the traffic encrypted with the public key from the server?)

Also, I understand that the handshake can be sent during the flow to keep it more secured, if the certificate is not trusted, does the connection ends now? (because in the first step, i understand that the user can decide to go further with a warning in his browser that the certificate cannot be trusted).

1) I'm not sure what you mean.  There are numerous reasons a handshake could fail, however it should be noted that generally an untrusted certificate will not result in the handshake failing, but rather an indication of a lack of trust in the connection.  A shared session key can be determined even if the server being connected to is untrusted and fails certificate validation.

2) It could vary by client, but probably just in memory.  Yes, if the session key is stolen from either the client or the server, then the session can be monitored.  This is why it is important that your client machine be secure.  If the attacker controls the server or your client, SSL won't do you any good.  Note, this is actually how some enterprise firewalls work.  They use an SSL certificate on the firewall and then communicate the session key to both the server and the client so that all parties on the line can read the traffic.

3) As answered in #1, the lack of authentication of a connection is simply a failure to validate the recipient, it is not a failure of SSL to establish an encrypted tunnel.  You still have a secure connection between you and the third party, the identity of the third party simply can not be validated and is thus untrusted.


I forgot my 7z password I used 7zip to encrypt a 200mb archive of my code used a combination of some of 7 possible words and no numbers or caps. So  823543 possible passwords. What is the best free program I can use to recover my password that allows me customize the words it uses.

I assume I have an answer.

You need to perform a dictionary attack.. Kind of..

The problem is you generally need a hash. If you have one, but I doubt it, then I will give you the answer in an instance. But I doubt you have that in your case. You might need a program specialized for 7zip like  7zCracker.

Again, a standard Dictionary Attack software might not help you in your specific task, but in the end that's what 7zCracker will do, it will just check for success in a different way.

I am no pro, so I apologize  for any mistakes or inconsistencies. Give it a shot with 7zCracker and tell us how it went.


What does Google do to prevent SQL injections? I'm a newbie when it comes to security but I've been interested in SQL injection and in particular in how to protect from them. I've read a lot about how to prevent your website from SQL injections, but I was wondering what Google in particular does to prevent hackers using search. What kind of measures do they take to minimize this (if they do so at all)?

SQL Injection doesn't work on Google because they don't use SQL for search - they use BigTables instead (something they wrote)

They do protect against injection in general, however, by using appropriate filtering and never creating queries by combining strings, but rather by passing parameters.  Read OWASP on SQL Injection.

They likely use a Web Application Firewall (WAF) at some level as well, just as additional protection against programmer errors.


Understanding digitial certifications q1) Does that mean that every time information is exchanged, both the original data + digital certification is sent? Meaning data + signature for each and every exchange.

q2) Can any kind soul here please explain why we need to encrypt the one-way hash on the original data, since the hash itself is irreversible ?

If the (a) original data + (b) hash data + (c) hash algorithm is sent over to the receiving party, with (b) and (c), the receiving party is already able to know if (a) is being tampered with, so why the need for encryption ?

=========================================================

Is the purpose of encrypting the hash data is done so that, if someone is able to fake/change (a), he will not be able to change (b) and (c)?

-- is the hashing algorithm encrypted as well?

But again, the original data, and digital signature can all be fake and sent over to the recipient.  So why do we need the private key encryption ?

or

Is the sole purpose for authentication purposes so that one who has a public key knows that this piece of encrypted hash information is signed by the person that issues this public key (has the private key) since he/she is able to decrypt it.

Please advise.

You are essentially correct in your last paragraph:

Is the sole purpose for authentication purposes so that one who has a public key knows that this piece of encrypted hash information is signed by the person that issues this public key (has the private key) since he/she is able to decrypt it.

Though, as mentioned in comments, and in various places around the internet, the idea that a signature is "signing with the private key" is not quite right, it's like saying that a motorcycle is a mechanical horse; it's kinda right (and if you're talking to someone from the year 1685 then it's probably the best you can do) but it's also completely wrong.
So I'm not sure where you got that image from, but I would be wary about anything else they've said, since they are clearly over-simplifying.

I think you already have the core idea, but I'll try to add some more context.
Let's say you're in some sketchy foreign country and a complete stranger walks up to you and says "Hi @Noob, I have a letter for you from your mother." Before you open the letter there are two things you probably want to know: 1) did this letter really come from your mother? And 2) did anyone modify it before giving it to you? In information security these questions are known as authenticity and integrity, respectively.
Digital signatures accomplish both authenticity and integrity, let's talk about integrity first.
Data Integrity
With this question we want to prove that the message has not been intercepted and modified while in transit. To do this we will use cryptographic hash functions with the idea that if two messages have the same hash code, then with a 99.99...% chance they are the same message. (The 0.0...01% chance that two properly formatted English messages have the same hash is actually exploitable, and is called a hash collision attack, but we'll ignore that here.)
So when I send a message, I'm going to attach to it a hash of the message so that the recipient can compute their own hash of the message and check that they match (that's the right-hand-side of your image "Identical hash validates data integrity"). But what's to stop the mail-man from replacing both the message and the hash with new ones? Well, we'll solve that at the same time that we solve authentication.
Data Authentication
In this question we want to prove that the message which claims to be from your mother, did actually come from your mother. To do this, we usually get the sender to include something that only they could have done, for example you sign paper by scribbling your name in a way that nobody else could possibly copy, ancient kings would press their rings into wax (assuming that nobody else has a copy of that ring). With digital signatures we are going to sign a small piece of sample data and send it along, that way anybody can try decrypting it with the public key in the sender's certificate and make sure that it matches the original sample data. Now, instead of signing any random piece of data, we'll sign the hash of the message and kill two birds with one stone. When we check that
decode(received_hash, sender_public_key) == hash(received_message)

we are actually verifying both authenticity and integrity in the same step, since the only way this will pass is if the sender owns the matching private key and the message has not been modified.
~~ Edit in response to your comment: ~~
How do I know that the public key that I have is actually for my friend, and not for an attacker pretending to be my friend?
That's what certificates are for.
The question has a different answer depending on the type of trust model we're using, so let's look at the two main ones:
Web of Trust
This is the system used by PGP where each user creates a certificate for them self and gives it to their buddies. The first time you give your cert to someone you have to do it carefully, like on a USB stick in person, or once they have it, have them encrypt something for you and make sure you can decrypt it properly.
Once you have a certificate that you trust for someone, then you can encrypt for them and verify their signatures without any problem.
There's also the Network of Trust (aka "Web of Trust") idea: you can add your signature to anyone's key to endorse that it's genuine. Let's say I'm good friends with Bob, and he has endorsed Alice's cert, then I'm probably OK to trust Alice's cert.
Hierarchical Trust - Public Key Infrastructure (PKI)
This model gets it's trust by having all certificates generated by trusted servers (called Certificate Authorities). In this model, the job of the CA is to make sure that the person is who they claim to be, before issuing the cert to them. For example, if someone submits a request for a certificate tying pub_key to bob@example.com and 1-800-123-4567, then the CA might send a one-time code to bob@example.com and make sure he can get it, and might try calling 1-800-123-4567 and ask "did you just order a cert?"


Implicit flow login from SPA Looking at the implicit flow to login with https://github.com/IdentityModel/oidc-client-js and https://github.com/IdentityServer/IdentityServer4.Samples/tree/release/Quickstarts/7_JavaScriptClient . The process begins with forwarding to a server side login page.

I'm aware that there are advantages of not having to make changes to the SPA if additional providers are used, but are there any more reasons why you're encouraged to use a server side login page? It seems as though the implication is that it's more secure, but I don't understand why.

I presume you're referring to an OAuth 2.0 Implicit Flow.

I think you're wondering why you need to direct away from your SPA for the user to authorize your app (by logging in, and usually selecting permissions to grant your application).

OAuth, as a protocol, is designed to allow a third-party to authenticate a user's identity. To use Google OAuth as an example, the user leaves your site and goes to Google, so that you can't steal their password or perform other actions on the user's behalf. They've left your site and entered the site of their trusted identity provider, who you are also implicitly trusting by allowing them to authenticate your user's identity.

If you are authenticating with your own server, there may be no need to use the OAuth protocol. Just allow them to submit their username and password directly. They're already trusting you to handle their username and password by signing up for your service.

The only good reasons I'm aware of to use your own OAuth provider on your site are:

Centralizing identity in a micro-services architecture
Exposing an identity provider for third-parties to use
Using a pre-packaged software solution as an identity provider, so you don't have to roll your own identity and authentication solution

Edit: Here's a a better resource on implicit flow. RFC 6749 Section 4.2

And here's an ascii-art diagram of how the implicit flow works. Note that the authorization server is distinctly a separate entity in this diagram, and that the authentication step is directed toward this server.

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier     +---------------+
 |         -+----(A)-- & Redirection URI --->|               |
 |  User-   |                                | Authorization |
 |  Agent  -|----(B)-- User authenticates -->|     Server    |
 |          |                                |               |
 |          |<---(C)--- Redirection URI ----<|               |
 |          |          with Access Token     +---------------+
 |          |            in Fragment
 |          |                                +---------------+
 |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
 |          |          without Fragment      |     Client    |
 |          |                                |    Resource   |
 |     (F)  |<---(E)------- Script ---------<|               |
 |          |                                +---------------+
 +-|--------+
   |    |
  (A)  (G) Access Token
   |    |
   ^    v
 +---------+
 |         |
 |  Client |
 |         |
 +---------+


How anonymous would this be? I use a laptop running tails/tor to go to a public wifi spot like a coffee shop and set up a new email account on protonmail. Then I take that laptop to a park in the middle of the night where there's an xfinity hotspot and sign up for the free hour pass using that email. No cameras, no people, no harddrive in the laptop. Then dispose of the laptop after use.

Let's examine your risk factors step by step:
I use a laptop running Tails/Tor
This is a solid anonymization between you and the end user. Provided of course you don't overtly supply identifying information.
set up a new email account on protonmail
ProtonMail requires an alternate Email, SMS, or Donation to get past their anti-spam human check (At least using Tor they do). Both SMS and Donation are a direct link to you so that leaves an alternate Email. What's the trace on that alternate Email?
go to a public wifi spot, like a coffee shop
You laptop MAC address is potentially recorded in the coffee shop router. It's possible you spoofed it, and finding that particular coffee shop and correlating the MAC with other activities is a pretty low probability, but technically possible.
laptop to a park in the middle of the night where there's an Xfinity hotspot and sign up for the free hour pass using that email.
Many parks are closed at night, so you will stand out to any park cameras and security. Xfinity will have your MAC, again unless spoofed. If you have in the past or ever in the future reuse your MAC on Xfinity or Coffee shop outside of Tails, correlation is possible, albeit again a pretty high bar.
Increased complexity is not necessarily better. In many cases it's actually worse.
The whole Park/Xfinity thing not only doesn't help, it's detrimental. If you are already running Tails and connecting to Proton Mail, just do your download then and there. Attribution back to the coffe shop is protected by Tor. Additional skulking doesn't help, it hurts. There's no reason to destroy your laptop under this scenario, but you certainly can if you like.


How do openvpn/easy-rsa generated keys map to RSA algorithm variables? I was reading up a little on openvpn and pki infra and am confused by some of the questions posed by my colleague. :)
This answer did help me understand more: https://security.stackexchange.com/a/12369/66224

But I am still stuck with some questions. Searching hasn't helped much.

1.1. In the openvpn with pki process, we create the ca first, which gives us the ca.crt and ca.key; more importantly, we get a dh2048.pem and a crl.pem.

1.2. Then we go about creating files (.keys and .crts) for the entities (here, entity means openvpn client or server; basically, a 'client' for the ca)

PKI uses RSA which is as follows (copied from:http://docs-legacy.fortinet.com/fweb/admin_hlp/5-0-0/index.html#page/FortiWeb_Help/how_to_apply_PKI_client_auth.html)

2.1 n = pq; p,q = big primes

2.2 phi = (p-1)(q-1)

2.3 e < n, such that gcd(e,d) = 1

2.4 d = e^(-1) mod phi

2.5 (n,d) is the private key

2.6 (n,e) is the public key

I see that the ca.crt is a key, dh2048.pem is a key, client.crt is a text and client.key is again a key.
How do these map to the algorithm variables above?
Thanks.

EDIT1:

An addendum to the question.

The openvpn manual says that both the openvpn server and the openvpn client authenticate each other. I have also read that the CA can be completely offline for security purposes. So, how do they contact the CA if needed? Based on RSA (and since it involves computation) I am assuming that they never contact the CA. Then how does the solution work?
Thanks.

EDIT2:

If RSA is what is followed in PKI, how is a trusted time service a requirement in PKI infra?
Thanks.

Creating a Certificate Authority

When you create your Certificate Authority certificates you will get ca.crt and ca.key files.  The .crt file is the self-signed public key, and the .key file is the private key file.  It's not quite as simple as this.  Both files are base64 encoded, and the data underneath is DER encoded.  Since you are likely generating X.509 certificates.

Really all you need to understand is that you have a self-signed certificate whose public portion is stored in ca.crt and the private portion is stored in ca.key.  Remember that you need to keep ca.key secret  All of the big primes, GCD operations and what not is all taken care of by whatever you're using to generate the certificate.

The dh2048.pem is not a key, it is the Diffie Hellman parameters for the server.  These have nothing to do with your RSA keys, and are only used for when Diffie Hellman is used to connect to your server rather than RSA.  The difference between the two can be found in the Key Exchange section of How does SSL/TLS Work?  These should have nothing to do with PKI.

The crl.pem is generated to be your Certificate Revocation List.  Any certificates that you revoke that have been signed with your CA are added to this file.  In your OpenSSL configuration (I'm assuming you're configuring OpenSSL, but the idea applies to any configuration) this CRL file will be pointed to.  That way it will know where to check for revoked certificates.

Signing Certificates

Now that you have a Certificate Authority you can begin signing certificates of users for your system.  Users do this by generating their own RSA keys client.crt and client.key.  These keys should be generated whenever a new user is introduced to the system.  Again, the .crt is the public portion of the key, and the .key is the private portion.  The client.key must be kept secret by the new user..

To sign the certificate of a new user a Certificate Signing Request (CSR) is made.  There is a command in OpenSSL to do this.  The request contains the public key of the user to be added, and some other public information needed by the request.  The client's certificate will be added to the appropriate authorized lists on the server, and a new signed certificate will be produced.  This is what the user will have to import into their browser to visit PKI enabled pages.

There's a great tutorial about Public Key Infrastructure on OpenSSL's site for future reference.

Hopefully this clears some things up.  Each variable you've mentioned in the RSA algorithm is generated when you create a certificate.  Public certificates don't contain them all, but the private portions generally do.  For implementation purposes you won't need to worry about them.  Just remember that there is a public and private key pair.

To Answer your 1st Edit

The exchange of CSRs and the resulting certificate is generally performed using some type of secure copy (scp).  The server and client must be in communication with each other.  The statement that "the client and server authenticate each other" is not really correct.  The client wants to be a part of the infrastructure so it must prove its identity to the signing server.  As the Certificate Authority, it is its responsibility to verify the identity of the client before processing the CSR.  The CSR itself should have all the information needed to verify the identity of the client to be added.

To Answer your 2nd Edit

RSA is only the public key algorithm used for key generation, encryption/decryption, and signing.  Public Key Infrastructure is a collection of standards and services required to implement a secure infrastructure.  A trusted timing service is most likely one of many requirements.  Much like a Certificate Authority is a requirement.


How risky is to use non-free wireless network driver? Intel wireless network adapter in my computer requires a non-free driver to work. I don't want to install non-free software to my debian system. However it is a notebook and without wireless network it is not very useful for me.

I wonder how risky is to install this driver with regard to surveillance. I mean, do you think it is actually possible that wireless network driver may act maliciously and let some authority or third party collect the data my computer transfers via wireless network?

I suspect that such behavior would cause a scandal if detected, therefore it seems unlikely to me to some extent. On the other hand we have become more familiar with scandals about big IT companies in recent years.

Or is this question fundamentally meaningless because hardware may act maliciously by itself and there is nothing we can do about it, which makes using non-free or free driver irrelevant?

Do you think it would be meaningful not to use wireless network hardware installed to my notebook but try instead to find another solution because of this non-free driver?

A closed binary is harder to audit than something you have source for, so technically you add some risk by doing this.

However, you may already be taking equal or greater risks:

Are you compiling Debian from source yourself or downloading a binary ISO?
Are you auditing the source code yourself or just assuming someone else has done it, like everyone assumed someone was checking the OpenSSL source.
If you're building from source, how do you know the compiler is OK?
As you mention, how do you know someone hasn't tampered with the hardware?
Is your BIOS open source? (I would have linked to that weird farming laptop Stallman used to use but apparently he has a ThinkPad now.)

As always, you must evaluate your threat model and assess the risk for yourself.


Correct way to generate password salts in PHP 5.3 on Linux given my constraints? In examining our database storage of hashed passwords with salts, I note a high rate of salt collisions, i.e., there are far too many cases where two table rows have the same salt stored.

One remediation is to immediately begin generating "better" salts as we store new salted-and-hashed passwords.

We run PHP 5.3 in production. That means we probably can't use libraries which say they require PHP 5.4+. (I say "probably" because our CentOS integration does include some PHP 5.4 features. We're investigating compatibility of various libraries.)
We do not have libsodium available at this time.
We do have both the mcrypt and openssl PHP extensions installed and enabled.
I have read through all of Scott's blog posts at Paragonie. The most relevant is How to safely generate random strings and integers in PHP.

I believe my best option for creating a password salt in these circumstances is to use mcrypt for obtaining bytes from /dev/urandom:

$salt = mcrypt_create_iv(16, MCRYPT_DEV_URANDOM)

assuming 16 bytes is appropriate for the salt. The PHP documentation does not even say if that first parameter is in bytes! But it does appear to be so.

We have a few tens of millions of users, so allowing for 100 million salts should be reasonable.

Given my constraints, can anyone suggest a better approach than taking 16 random bytes from /dev/urandom via mcrypt extension?

To be sure, we are also working on other upgrades to get us to better library availability, stronger hashing, etc. That's outside the scope of this question.

So what do you want from your salts?

They should be somewhat unpredictable to prevent pre-computation attacks.
They should be globally unique.
They should be as small as possible as it needs to highly scale.

The only assumption you need to make is that /dev/urandom is secure and at least provides statistically random numbers (which it should). This is a reasonable assumption as otherwise nearly everything (crypto related) on your system would be broken, as very most of them use /dev/urandom. It further needs to be assumed that mcrypt basically just forwards /dev/urandom's output.

To satisfy property #1 you'd need to have at least 128 bit (=16 bytes) salts, but this would leave you with a good probabilty of a collision after having observed 2^(128/2)=2^64 salts, which may be too soon for you to be really sure that they're unique. I thereby propose to use 32 byte (= 256 bit) salts that have 128 bit collision resistance making it really unlikely to ever re-use any salt and salt will still be reasonably small (you could also use 512-bit salts...).

As far as password hashing is concerned you may want to have a look at the related competition.


How to select a random node when nodes are untrusted in a distributed network? Assume in a distributed network, where the nodes are not trusted and are identified by their public keys, we intend to select one of them in a random process. In such a situation, all of the nodes have the same chances to be elected.
Since the system is not centralized and there is no trusted server performing the election process, how to select one of the nodes truly randomly (where each of the nodes is able to manipulate the client code such that they would be elected in all the rounds)?
Complementary explanation: I mean that as there is no trusted and centralized server to perform the randomness process, thus it is performed locally in each node by a client code, such that each node can be able to manipulate the client code to be always elected. Assume there are 10 nodes, each of which has a client code to perform a decentralized randomness process. What happens if one of them manipulate the code to be elected in all the rounds? And how to prevent such malicious behavior?

If you have anonymous nodes, then you have the problem of spawning fake nodes under your control. That is, you have worse problems than a node voting for itself.
So some kind of reputation is needed for each node. I am a fan of "bartering exchanges", where transactions happen within a local group. Trust grows from that small group succeeding to add value equally for each other. That group can form a group identity for performing larger transactions with larger groups, but initially starting small between those groups.
It's important that fair trade is used as the basis for gaining trust. Therefore if a relationship is asymmetric, then it won't last
I don't know what your network is doing so I can't help more without knowing what "value" is exchanged. But I want to assure readers that this value need not mean "money". In the digital world, computing resources may be exchanged, disk storage may be rented, and human laboured services can be rendered anonymously. With a "bartering" model you don't track a currency, but rather trust and equality.
When it comes to vote that occurs within a trusted group, then that groups outcome is signed by group members and shared onward to other peer groups, and so on. Barter trade value is the reputation that either validates the vote or multiplies the weighting of the group vote.


Some explanation on Maimon Scan I'm facing this question:

  When could the Maimon Scan be usefull?

As I had no idea of what it was, I went into Nmap's manual and saw the explanation:

  The Maimon scan is named after its discoverer, Uriel Maimon. He described the technique in Phrack Magazine issue #49 (November 1996). Nmap, which included this technique, was released two issues later. This technique is exactly the same as NULL, FIN, and Xmas scans, except that the probe is FIN/ACK. According to RFC 793 (TCP), a RST packet should be generated in response to such a probe whether the port is open or closed. However, Uriel noticed that many BSD-derived systems simply drop the packet if the port is open.

So, what I understand from this is that, many BSD-derived systems just drop the packet instead of sending an RST back so using the Maimon Scan would set that port as Open, right?

If that's correct, then, I don't get why asking such question. I mean, it would always be very usefull using it against BSD-derived systems, right?

The scan does not open the port, it tests if the port is open or not.

This is useful for enumeration, it can not only help enumerate that the target host may be a BSD derived system, but that the port that is being targeted is open, which you can tell by the absence of a reply.

For example.

If you send FIN/ACK to a port then the port should reply with a RST as the FIN/ACK is out of state or the port is closed, but if you do not get such a reply then it may indicate that the target host is a BSD system and the port is open, as it has been observed that many BSD derived system simply drop the segment if received on an open port.


Why is it okay for Google Authenticator to provide scratch codes? It is my understanding that the scratch codes that Google Authenticator provides in case you lose your phone are a one-time password but a password nonetheless. If an attacker gains access to them (in addition to your main password or key), can't he log in and then reset Authenticator, synchronizing it with his own phone to give himself permanent access? How is using Authenticator for MFA any better than using two fixed passwords or using single-factor authentication but appending the scratch codes to your original password?

In case context matters, I have an EC2 instance that I've configured to require both an ssh key or password and a code from Authenticator when I ssh into it.

The idea behind two factor authentication is to use something you know and something you own to authenticate.

In your example you're usually using your normal password (something you know) and your phone (something you own). In the case of backup codes, they should be downloaded once and printed off in case you lose/forget your phone as something you own. However Google allows you to view them again, probably as users were losing them. Ideally a new set of backup codes would be generated in this case.

  If an attacker gains access to them (in addition to your main password
  or key), can't he log in and then reset Authenticator, synchronizing
  it with his own phone to give himself permanent access?

Yes he can which is why a strong password in the first place is a good idea. As Google asks for this when making changes to the way you sign in. If an attacker has stolen your session or is performing a man in the browser attack, they still need your password to make changes. If they have your password it's game over.

  How is using Authenticator for MFA any better than using two fixed
  passwords or using single-factor authentication but appending the
  scratch codes to your original password?

Authenticator is better as it isn't a static password appended together, essentially making it a single factor. Use of one time passwords makes the opportunity for an attacker to use them much smaller. Backup codes are also one time, once you've used one you can't use it again.

So what's the best way of using authenticator?

Don't use backup codes - This reduces flexibility however.
Get a hardware token - As Google Authenticator is just implementing OATH TOTP and HOTP you can get a programmable OATH hardware token. This reduces the attack service further as it's a completely disconnected token, an attacker can't use your phone for authentication.

What about other authentication methods?

Personally I use a Yubikey together with Duo Security Linux Integration for SSH authentication. It works a treat.

You can also use a Yubikey directly with Google Authenticator.

Finally, like most things in life you have to compromise. Some authentication can be really easy to use at the expense of some security, others can be annoyingly difficult to use but are very secure. Try and figure out what matters to you and find the best compromise.


Does a customer who uses a cloud service provider with ISO27017 compliance, need their own certificate to be compliant themselves? ISO 27017 advises both cloud service customers and providers. Microsoft Azure is compliant with ISO27017.

Let us say that a cloud service customer who uses Microsoft Azure wants to be compliant with ISO27017 - I assume that he/she is not automatically compliant with ISO27017 by virtue of Microsoft's certificate.

I am having trouble understanding the apparent dichotomy between ISO27017 being a standard regarding the relationship between cloud service customers and providers, yet each party apparently needs their own certificate.

Or do we say that there are really two certificates - one for "giving" and one for "receiving" and each party needs its own certificate.

From the overview of ISO 27017:

  The standard advises both cloud service customers and cloud service providers, with the primary guidance laid out side-by-side in each section.

Thus, the standard clearly has guidances for both. Given that a cloud service provider can not fulfill the requirements on the customer  the customer clearly can not automatically be compliant just by using the right cloud provider.

This is similar to safety of a car: just because the vendor has to implement several safety measures the car is not automatically safe. It also depends on how the customer drives so there are requirements for this too.


Why would a software need my IP address in authentication token? I was looking at the authentication token used in my network requests to a software that we use at work. I noticed that this is not a general JWT OAuth token but some XML based token. I guess, old way of doing things. I am particularly interested as to why do they need my IP address?

Is there a legitimate security reason to need it? My guess is to ensure that no other machine can reuse the token.

Is there a legitimate security reason to need it? My guess is to ensure that no other machine can reuse the token.

That is a pretty good guess! Depending on how the software is implemented, it could be that the software is restricted to internal use (within the company) & there is IP whitelisting enabled at authentication level of the software.

Therefore, an intruder would need to have the token itself and prior information on having the IP address as part of the token as well.