Designing a PKI environment For our company I was given the task to design a durable, structured PKI environment for mainly client authentication purposes.

We need a Root CA with a couple of Intermediate CAs, like this:

Enterprise Root CA

Purpose 1 CA
Purpose 2 CA
Customer CA

Customer 1 CA
Customer 2 CA

Can anyone explain some best practices for these questions in a modern (~2016) environment?

Should I use RSA or EC certificates? Do all certificates need to be of the same type to sign intermediates?
What are the preferred key lengths for these certificates?
Is there a schema to use for serial numbers?
What are the typical expiry dates for Root CAs and Intermediate CAs? I don't think they should expire at the same date, preventing a future headache?
What if a, for example, Customer CA expires? Do I need to re-sign all underlying certificates?
How does Customer 1 create a keypair that can be signed by our Customer 1 CA so it can be used for client authentication? What exactly is needed for a CSR?

Thanks.

You have a lot of questions combined into one here, and I won't attempt to answer all of them.

Regarding serial number schemes, I am aware of an installation that originally said "we have two signing machines, let's add a prefix of 100000 to the numbers generated by the second machine.  Turns out that it didn't take as long as they planned to consume a hundred thousand serial numbers, and their scheme collapsed.  Serial numbers can be quite long.  I'd recommend using a hash of the public key as the serial number, or at least a significant fraction of it (it needs to be large enough to statistically assure yourself that you will avoid collisions, taking into account the birthday paradox.)  They only need to be unique, not sequential.

Root CAs are often set for 10 or 20 years of life; they are trotted out only to sign Subordinate CA signing certificates, and are kept physically locked in a safe the rest of the time.  SCAs are set to expire more frequently, as they're installed in on-line systems and are in constant use, exposing them to more risk.  But each signing certificate needs to expire after the lifetime of the longest certificate they issue.  If you try cutting them too close, you will run into problems when they all expire at the same time.  In a related caution, you want to make sure your subordinate CA certs don't all expire at the same time.

I'm unsure why you show "customer certificates" signing other "customer certificates".  A certificate that can be used for signing has a tremendous amount of authority, and you typically would not risk delegating that to a third party.  If you have that kind of relationship, it would be more common to offer a signing service to your clients who need certificates.

It's also time to think about CRLs and/or OCSP responders.  You also need to consider tracking your certificates.  You can issue them all day long, but I assure you most of your clients will forget to request new ones until the day the old ones expire.  If you keep a list of issued certificates in a database, along with the requester's email addresses, your security team will be able to send out warning notices a month before the certificates expire.

Finally, there are enterprise certificate management products in the marketplace that can manage all of these requirements for you.  While this is not a forum for making specific product recommendations, I suggest at least searching the market to see what's available.  They will likely provide answers to other questions you didn't know you should ask.


openVPN extremely slow, PPTP/IPsec/etc. as fast as expected I am using a VPN service that I have tested with my main tower pc to show connection speeds way above 150 MBit/s with openVPN, PPTP, IPsec, etc.

With my OnePlus One Smartphone, Android OS 6.0.1, Cyanogen OS 13.1.2 I get around  I get around 20-40 MBit/s on my normal WIfI (no VPN), using IPsec around 20 MBit/s in both direction (I have a 450 download, 20 upload connection). But as soon as I connect through any kind of OpenVPN protocoll, my download speed collapses to 0.5-2 MBit/s. The upload speed strangely does not change and stays as 20 MBit/s. The problem is 100% reproducable with my smartphone, as soon as I activate the connection, the download speed collapses, as soon as I disconnect, it instantly ramps up again. To remind you: the problem ONLY occurs with any kind of openVPN connection, when I am using PPTP, IPsec, L2TP, etc. there is no significant decline in connection speed. And it only seems to slow down DOWNLOAD speed, not UPLOAD.

Are you using TCP or UDP?  Usually with OpenVPN you get much better bandwidth performance over the existing physical connections because there is lower overhead and OpenVPN can correct most issues anyway.  Unless you were experiencing major connectivity issues then use UDP to speed things up.
It should look like: proto udp as a line in your server and client configs.


Is it safe to give multiple virtual credit card numbers to the same vendor? There are situations when I have to give several virtual credit card numbers linked to my real credit card to the same vendor. Can a vendor guess the real credit card number by having multiple virtual credit card numbers?

You asked,

  Can a vendor guess the real credit card number by having multiple virtual credit card numbers?

The answer is no.

By looking at your temporary numbers, they could determine which network and bank issued the card (from the BIN, the first 6 digits). But they would not be able to tell your various cards apart from any other cards issued for that product by that bank, and there would be no relationship discernible between the temporary cards and your real card based on knowing the card number(s) alone.


Why can't Google Forms be used for elections? I have been looking into secure online voting systems for a fairly small-scale (though extremely important) leadership election (~1000 voters).
 I have been researching End-to-End auditable voting systems and the such, but then I started to think about why can't something like "Google Forms" be used. It is easy to control voter identity and making sure voters only vote once as everyone eligible to vote has a company Google Apps account.
If I'm not designing say the presidential election, then why can I not use Google Forms?

In general, we can't use a third-party vendor's website for public systems, since anything can happen beyond our control.

If we host a site similar to Google Forms and it was managed by us, we may conduct elections using a centralized system.

As far as usability goes, it would be good, but in terms of security, it's a bad option, since we can't trust the results beyond our control. Apart from that, anything may happen. For example, you may bribe Google to change the results or online voting usually suspects for cheating.

Kindly have a look at this answer, which describes many types of cheats which are good examples of how online voting can be misused.


Does File-Based Encryption offer comparable security to Full-Disk Encryption on Android? Between version 4.4 and 9, Android supported Full-Disk Encryption (FDE). On Android 7, a new system called File-Based Encryption (FBE) was introduced, and was subsequently made mandatory on Android 10.

The primary upside cited in the page for File-Based Encryption is the usage of Direct Boot, allowing you to use specific features before the device has first been unlocked, such as alarms or similar. As this seems primarily focused on User Experience, I am worried that the security will suffer from this choice.

My question is, does File-Based Encryption offer comparable security to Full-Disk Encryption? Are there any major downsides or flaws with it? And if so, which ones?

Full Disk Encryption (FDE) systems (like Truecrypt, BitLocker and FileVault) encrypt disks at the level of disk sectors. This is an all-or-nothing approach, since the encryption drivers won’t necessarily have any idea what files those sectors represent. At the same time, FDE is popular — mainly because it’s extremely easy to implement. While this could be excellent for PCs, for phones another approach may be necessary as I will explain below.

File-based Encryption (FBE) systems (like EncFS and eCryptFS) encrypt individual files. This approach requires changes to the filesystem itself, but has the benefit of allowing fine grained access controls where individual files are encrypted using different keys.

The main problem with  smartphone is that users are never encouraged to shut down their device. In practice this means that — after you enter a password once after boot — normal users spend their whole day storing all their cryptographic keys in RAM. Since phone batteries live for a day or more (a long time compared to laptops) encryption doesn’t really offer much to protect you against an attacker who gets their hands on your phone during this time.

Of course, users do lock their smartphones. In principle, a clever implementation could evict sensitive cryptographic keys from RAM when the device locks, then re-derive them the next time the user logs in. Unfortunately,  Android doesn’t do this — for the very simple reason that Android users want their phones to actually work. Without cryptographic keys in RAM, an FDE system loses access to everything on the storage drive. In practice this turns it into a brick.

For this very excellent reason, once you boot an Android FDE phone it will never evict its cryptographic keys from RAM. And this is clearly not good.

Starting with iOS 4, Apple included a “data protection” feature to encrypt all data stored a device. But unlike Android, Apple doesn’t use the full-disk encryption paradigm. Instead, they employ a file-based encryption approach that individually encrypts each file on the device.

In the Apple system, the contents of each file is encrypted under a unique per-file key (metadata is encrypted separately). The file key is in turn encrypted with one of several “class keys” that are derived from the user password and some hardware secrets embedded in the processor.

In order to secure things regarding keys, some security special measures have been implemented. If the high security protection class is used, files encrypted with this class key can only be accessed when the device is powered up and unlocked. To ensure this, the class key is evicted from RAM a few seconds after the device locks. This is desirable. In the case of medium security option, the encrypted files are protected until the user first logs in (after a reboot), and the key remains in memory. On low security, the files are accessible even when the device has been rebooted, and the user has not yet logged in.

As conclusion, for mobile phones, there is a relatively safe FBE option and it's up to the user to actually use it.

Read a little more about it here.


Is it possible to create a custom login page for your own Wi-Fi hotspot? How do I create my own open Wi-Fi hotspot/access point with a custom login page similar to those found in commercial hot-spots?

The page would be accessible using Windows or iOS, and users would have to accept terms of use, or submit payment details, or enter a username and password before being able to proceed.

What you are looking for is called a Captive Portal. Basically, it will intercept the first http connections, display the terms etc, require the user to accept them or use a password etc. There are some open source ones available. Don't forget that if the network is unencrypted all users can easily be sniffed/hijacked even if there is a captive portal.


How to force a browser when connecting to a specific domain to be https only using only the client machine? Is it possible to force a client (browser or host machine or etc) to only make https connections to a specific URL/domain?

(preferably non-admin/root fixes if possible)

Here is a fabricated scenario:

Lets say someone hosted a website, and they didn't put in an http -> https redirect and the web-server is serving requests on both 80/443 http/https respectively.

We are the client machine we work at a company and they wont fix the web-server for one reason or another. We do not have other machines to use as a proxy and have no control over the network. Now we could just make a bookmark (or other form of workflow that forces our actions to always reach https) but there has to be a way built in to browsers that can, say, "Do not connect to this domain/url unless using this protocol".

This would be my preferred approach if possible.

This is very frustrating for people who are security focused as accidentally hitting the http version will leak your session ID and if you login there RIP password.

I searched online but surprisingly found nothing.

You've found already that this can be done with an extension like HTTPS Everywhere. And you've found out that the browser will not do this by default. Thus there is the option of "doing nothing with the browser", which doesn't provide the protection or the option of "doing something in the client" which is already a solved problem by installing a plugin. Apart from that there is HSTS preloading where the browser knows that some specific sites will always use HTTPS even if the browser has never connected to these sites before.

If you want something like HSTS preloading but for domains which are not in the HSTS public preload list it is possible in Chrome to add additional domains to the local HSTS list by accessing chrome://net-internals/#hsts. See also Manually enforcing HSTS in Google Chrome.


Challenges in authentications I have a case where I have a set of low compute capable processors connected to a gateway processor. I need a way of authenticating these processors to gateway processor. The main things are:

I need to prevent some other processor from connecting to gateway processor
I am looking at a way where after authentication, I will be using encryption so that sniffing will be impossible
So I thought of doing authentication and then encryption
The main challenges are computing power of the processors are very less. At at time I can send 64 bits of data only. I also need to minimize the no of data send during authentication.
These are embedded processors

You might think of reinventing the wheel and rolling your own protocol. Don't.

This is what SSL/TLS is for. SSL/TLS is a surprisingly lightweight protocol that works great on embedded processors. This is especially true if you control both the client and server in which case you can remove the algorithm negotiation phase and stick to a single implementation.


How helpful is encrypting/decrypting information on an app-server, and sending it to the database encrypted? I just added some code to our app server to encrypt personal information before it's stored in the database. This was mostly done for compliance reasons, but how much of an actual security win is it?

I hear about database dumps all the time, but I'm not clear on how the attackers usually get the database. If it's by getting to a shell and being able to run arbitrary code, it seems fairly simple to go over to the app servers to find the encryption key being used.

I ask this because if it's a real security win, then we should probably encrypt more data before it reaches the database. On the other hand, if it's just theater, I'd rather spend our time improving security in a meaningful way.

(This is assuming the backups for the database are themselves encrypted).

Since there's not been an answer, I'll take a shot at this... but there are other questions about Database Encryption already, so you might want to check some of them out, as well.

As for how Database Dumps are acquired:

Backups
SQL Injection
Open Ports and the related terror of Default Passwords
Production Snapshots used in Development or Staging

While it's possible that an attacker could just acquire the encryption key from disk as you suggest... I cover some ways to mitigate that risk in a previous answer.

As for it's overall effectiveness... I wish I had some statistical resource to call on, but I don't. Intuitively, it would seem to protect your data with most static dump approaches. It increases the complexity requirement for an attacker - which is generally exactly what you want - since they will now need to breach your application layer to get the keys, in addition to the database layer.

The Patreon Breach is generally my favourite example of how Database Encryption helps to mitigate the fallout of a major incident.


In what ways does increasing SSH host key length increase security I have read on a few guides on "how to secure SSH servers" that it is a good thing to increase ServerKeyBits from the default of 768 to 2048.

Most of these guides seem to be for the entry level/novice server admin (which I am) to quickly protect themselves from scripted brute force root ssh login attempts and things like that, and I am trying to understand the point of each security measure.

I've been reading up on how public-key based authentication works, specifically for SSH v2.  I have not seen anything about the SSH server's host key being used in the process of client authentication at all, by that I mean proving that the client is trusted.

It seems to only be used to ensure that the host a client is connecting to is the same one its connected to in the past - that it's not an impostor.

I am wondering, practically speaking, why it is such a big deal to increase the host key to 2048.  Does it make it harder for an attacker to somehow brute force the private host key?
Even if an attacker were able to figure out the private host key, so that a client/or the administrator would be able log into the fake host, how would that benefit the attacker?

Also included in these guides is setting

PasswordAuthentication no

so the user shouldn't even be expecting to enter a password anyway.  If they were so unaware of things to enter a password when they usually don't have to, wouldn't they just blindly accept a different host key anyway?  Then if the attacker had the password, then what?  Password authentication is disabled on the server anyway, so they still wouldn't be able to log in.  From what I read, the attacker would not be able to gain any useful information from the client in the authentication process even if the client trusts the servers identity.

I feel like I am missing something major about how SSH public-key authentication works, because I don't understand why having a long host key seems so important.  Does it make it harder for client credentials to be compromised somehow?  What could actually happen if the private host key is compromised?

Thanks

There is a crucial piece of confusion in your question, which the answers here did not point out: ServerKeyBits has nothing to do with the hostkey. In fact, it is mostly irrelevant today, since it applies only to SSH protocol version 1, which has been obsolete for many years and should no longer be used.

If you’re familiar with setting up an OpenSSH server, it should also be clear operationally that an sshd configuration setting cannot by itself increase the size of the hostkey — which is sitting in a file on disk (e.g. /etc/ssh/ssh_host_rsa_key{.pub}) and is generated once and separately.

The “server key” in protocol 1 is a second RSA key — distinct from the hostkey — used to achieve forward secrecy. It is ephemeral, generated by the server on startup, replaced periodically (once per hour by default), and never written to disk. The client encrypts the symmetric session key with the server key and sends it to the server; this message is authenticated by signing it with the hostkey. In protocol 2, forward secrecy is implemented with Diffie-Hellman instead.

So, an adequately strong server key is important because if an attacker can recover it, he can read recorded SSH sessions or tamper with current ones (since he has the session encryption and MAC keys). And as a previous answer pointed out, 768 bits for an RSA key is far too short by today’s standards.


How can my employer be a man-in-the-middle when I connect to Gmail? I'm trying to understand SSL/TLS. What follows are a description of a scenario and a few assumptions which I hope you can confirm or refute.

Question

How can my employer be a man-in-the-middle when I connect to Gmail? Can he at all?

That is: is it possible for the employer to unencrypt the connection between the browser on my work computer and the employer's web proxy server, read the data in plain text for instance for virus scans, re-encrypt the data and to send it to Google without me noticing it?

Browser on employee's computer <--> employer's web proxy server <--> Gmail server

The employer can install any self-signed certificate on the company computers. It's his infrastructure after all.

Scenario: what I am doing

With a browser, open http://www.gmail.com (notice http, not https)
I get redirected to the Google login page: https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=https://mail.google.com/mail/&ss=1&scc=1&ltmpl=default&ltmplcache=2&emr=1
I enter my username and password
I get redirected to Gmail: https://mail.google.com/mail/u/0/?pli=1#inbox
I click on the SSL lock-icon in the browser...

...and see the following:

Issued to: mail.google.com
Issued by: "employer company name"
Valid from: 01.01.2014 - 31.12.2014
Certification path: "employer company name" --> "employer web proxy server name" --> mail.google.com

Assumption

I'm now assuming that the SSL lock-icon in the browser turns green, but in fact I don't have a secure connection from the browser to the Gmail server.

Is that correct?

Sources

I've read these sources but still don't quite understand it:

Is there a method to detect an active man-in-the-middle?
Preventing a spoofing man in the middle attack?
How does SSL/TLS work?

Summary

Is it possible for someone to be a man-in-the-middle if that someone controls the IT infrastructure? If so, how exactly?
Is my login and password read in plain text on the employer's web proxy server?
What should I check in the browser to verify that I have a secure connection from the browser all the way to the Gmail server?

EDIT, 18.07.2014

Privacy is not a concern. I'm just curious about how TLS works in this particular scenario. What other means the employer has to intercept communication (keylogger etc.) are not relevant in this particular case.
Legal matters aren't a concern. Employees are allowed to use company IT equipment for private communication within certain limits. On the other hand, the employer reserves the right to do monitoring without violating privacy.

You are absolutely correct in your assumptions.

If you are using a computer owned and operated by your employer, they effectively have full control over your communications. Based on what you have provided, they have installed a root CA certificate that allows them to sign a certificate for Google themselves.

This isn't that uncommon in the enterprise, as it allows inspection of encrypted traffic for virus or data leaks.

To answer your three questions:

Yes it is very possible, and likely. How active they are at monitoring these things is unknown.
Your password can be read in plain text by your employer. I don't know what you mean about the web server.
You can check the certificate to see who signed it, as you have already done. You can also compare the fingerprint to that of Google (checked from a third party outside of business control)

Edit:

  How exactly is my employer able to unencrypt that? Could you perhaps
  elaborate on that a bit?

You are using the bad certificate to connect to an intermediary device such as the firewall, that device is then connecting to Google using the correct certificate. The communication is encrypted from your client to the MITM, decrypted, and then re-encrypted on its way to Google.


Does CVEs reported in a Java Update applies also to previous updates? If my application uses JRE 1.8.0_6, that have currently 3 CVEs reported, all later updates' CVEs sums up to 216, and 34 CVEs reported in JRE 1.8.0 in general, what is the number of vulnerabilities my application is potentially exposed to 3, 3+34, 3+216, or 3+216+34, and why?

It is not possible to determine the number of relevant CVE just based on the numbers you show. For example a CVE shown for Java 8u131 might have been just recently introduced in Java 8u130 or it might already have been lurking in the code since Java6. Thus in order to to get which CVE are relevant for your Java version you need to dig through the details of all the later CVE and look for which versions they apply. If they apply already for Java 7 then the chance is high that the bug is also in the older Java 8 version you use.

Apart from that: who cares about the exact number (and only about the number). Relevant for assessing the risk you have when using an old Java version is not the total number of CVE but which of these actually affect your application, how bad they are and how they can be mitigated.


Is it safe to store public key encrypted password in the Mobile Device for authentication purposes? I have a Apache Cordova hybrid mobile app that needs to authenticate users, but we don't want to prompt for credentials every time the app is used.

Some options came to my mind:

Store the password encrypted using public key cryptography, so only the server can decrypt it and perform authentication. However, I understand it's a bad practice that in the event that password gets compromised, the entire suite of applications using the SSO would be compromised.
Use Client Certificate based authentication... Does it make sense?

Are there other choices?

You should look into token-based authentication. That is, tokens issued by an identity provider - not to be confused with security tokens that are generally used with multifactor authentication systems.

This authentication method eliminates the need to store a password in every client, yet provides the convenience of not having to prompt for credentials on every application start. This works by storing the access token on the client, which is presented to the server on every request and expires after a certain amount of time (e.g. 7 days).

This approach is similar to cookie-based authentication (like used with WS-Federation), with the important difference that it isn't prone to Cross-site request forgery (CSRF) attacks.

I highly recommend researching the OAuth standard.


Why does PGP work with the CC field in e-mails? I was wondering how PGP works with a CC. In my understanding, if I send an e-mail to foo@example.com and use baz@example.org in the CC, Enigmail would have to encrypt the e-mail once for every user and send two e-mails.

But in reality, if baz@example.org checks his e-mail he is still listed as CC and not as the main recipient (which would be the case if the e-mail were encrypted once for everyone).

So how exactly does it work?

In the OpenPGP format (that PGP implements), a given email can be encrypted for several recipient with only minute per-recipient size overhead. This is because email encryption actually uses hybrid encryption:

A new random symmetric key K is generated for the email to encrypt.
The bulk of the email is encrypted with a symmetric encryption algorithm, using K as key.
The key K is asymmetrically encrypted with the RSA or ElGamal public key of the recipient.

This is done because asymmetric encryption (RSA, ElGamal) is very limited in processable size, and is also computationally expensive, whereas the symmetric encryption algorithm has no problem processing megabytes of data.

In that setup, if you send the same email to two recipients, then the symmetric encryption with K is done only once; but the key K will be encrypted twice, once with the public key of the first recipient, and once with the public key of the second recipient. Each recipient thus adds only a few hundred bytes to the encrypted email. This is how a "Cc:" can work. Note that it reveals to each recipient who also got the email.

This "Cc:" mechanism is also used when there is only one apparent recipient, because PGP takes care to encrypt the email for both the intended recipient, and yourself -- so that you can later on re-read your own emails from your "Sent" folder. So a basic PGP email already has two recipients.


Does Windows Device Encryption use a new key to encrypt each time? Say I have a machine running Windows 10 with built in Device Encryption enabled. Say I want to reinstall Windows and sell the machine. I am wondering: after the format and reinstall, is a new key generated for the Device Encryption? Or in other words, without having access to the original recovery key, is it remotely possible for the new owner to recover my old files which were encrypted using the original key?
What if I delete a file, turn off Device Encryption, and reenable? Can my deleted file be recovered without the original recovery key?

"Device Encryption" in Windows is a user-friendly name for Microsoft's "BitLocker Drive Encryption", first introduced with Windows Vista and updated with newer Windows releases.

I am wondering: after the format and reinstall, is a new key generated for the Device Encryption?

Yes
When BitLocker is "turned on" (enabled), it generates a new encryption key from the system's cryptographically secure pseudo-random number generator (CSPRNG), which is software that takes a large number of of different inputs, including many transient ones that are not practically controllable or repeatable, and mixes them together constantly such that at any time its output will appear totally random. The output of a CSPRNG should not ever predictably repeat, and certainly won't just because you performed a full reinstallation of the OS!

What if I delete a file, turn off Device Encryption, and reenable? Can my deleted file be recovered without the original recovery key?

I don't know, but it may depend on BitLocker mode
There's two points of consideration here: is the old key gone, and did the deleted file get decrypted-and-re-encrypted?
When BitLocker is turned off (or paused), a key is written to the disk in plain text that can be used to recover the master encryption key. This plain-text key will remain until BitLocker is fully done decrypting the drive (if turned off), or is resumed (if paused), at which point the OS attempts to securely wipe that plain-text key from the storage. If an attacker steals the machine before BitLocker is done decrypting, they'll be able to read the still-encrypted data by using that key. I don't know what happens if you turn off BitLocker and then try to turn it on again without giving the OS time to decrypt the disk first; it might just start re-encrypting with the same master key, but set up new "Key Protectors" (the ways, such as boot-time passwords or recovery keys, that the master key can be retrieved to unlock a BitLocker'd volume). That would not be ideal from a security perspective, but with TPM-only mode (I believe most cases where you see BitLocker as "Device Encryption" will be BitLocker in TPM-only mode) there's no user-facing protectors to rotate so it's possible they don't bother rotating the key either. Certainly that would be faster than fully decrypting and re-encrypting with a new key.
However, if you allow the system to fully decrypt before turning BitLocker on again, it will generate a new key. The old one won't be available anywhere for re-use.
For deleted files in particular, this is an interesting question because BitLocker can operate in two modes, and I don't know which one you'd be seeing. The fastest way to encrypt a disk, used by default on new installs, is to encrypt only the in-use space. BitLocker can optionally encrypt all space instead, which takes longer but means previously-deleted data will not be recoverable without the key. Also, BitLocker does not automatically decrypt files upon deletion no matter the mode; that would obviously be insecure. Your question, however, concerns an interesting edge case: if you have BitLocker enabled only and delete a file, and then turn off BitLocker, does it bother to decrypt the free space? I don't know. If it does, then YES, your deleted file would be recoverable (assuming no overwriting, of course) without the old key; either it would still be sitting around in plain text (if you turned BitLocker on again in "used space only" mode) or it would be re-encrypted with the new key (if turned on again with free space also encrypted). However, if it doesn't - if BitLocker never bothers to decrypt "free" space when turning off - then the deleted file's data would be permanently unrecoverable as soon as BitLocker finished decrypting and wiped the old key.


Based on these email headers, where is this virus coming from? I'm seeing a virus in our network with some strange headers.  Sometimes they are coming (sourced) from a netscaler VIP, other times they seem to come from an Exchange hub server.

How do I determine the origin of this virus?  (workstation, etc)

I'm thinking that this has to do with special authentication of the receive connector (MX Exchange auth?) that allows acceptance of the message.

Received: from EXMB01.company.com ([xxxx:66bb]) by EXHUB02.company.com ([2.2.2.192]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 09:55:26 -0400
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: binary
From: "Dale Chip" <Chip.Dale@company2.com>
Subject: Unpaid invoic
Thread-Topic: Unpaid invoic
Thread-Index: Ac/of6pWLOgzgrBLQM2EB7owtQTxYw==
Date: Wed, 15 Oct 2014 09:55:25 -0400
Message-ID: <18FD6D6FDFA36A40A04B6C1C63B3A2E8B13DD353@MB01.company.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator: <18FD6D6FDFA36A40A04B6C1C63B3A2E8B13DD353@EXMB01.company.com>
MIME-Version: 1.0
X-MS-Exchange-Organization-AuthSource: HUB02.company.com
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 04
X-Originating-IP: [2.2.2.171]
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
X-MS-Exchange-Organization-Recipient-P2-Type: Bcc

Checked it out. Authmechanism=04 is a hexadecimal notation that tells you that the Exchange server did authenticate by IP-address.
With this, I mean that you have configured your Exchange server to treat certain IP addresses or ranges to be "trusted" in the parlance that it will bypass regular username/password authentication and/or eventual spam/virus filters.

The mail originates from a machine with IP 10.130.15.171. This IP could be a intermediate server. Then you might need to check the logs of that server.


Can a Patient's Name, Birth Date, and Study date be sent in a plain text email to a referring doc? I participate in a mailing list where the following question was asked, without satisfactory feedback, and am interested in the correct answer.

Several referring physicians have requested that an imaging center send them a list of patients that are scheduled and completed at the end of each.  They wanted the Patient Name, Date of Birth, and date of imaging study included in the email.

The question is, according to HIPAA, does this information need to be secure/encrypted when transmitted to the referring physician?  Or, is the information limited enough that it could be sent in a plain text email?

HIPAA does not explicitly require emailed PHI to be encrypted.  HIPAA requires "reasonable" protection/consideratoins etc. when emailing PHI.

HIPAA does require secure transit of PHI, which could easily be violated (e.g. using a webmail client over http vs. https).

So it is not directly a breach of HIPAA.  HOWEVER, the bottom line is that unencrypted email is a risky approach.  You are dependent on email privacy policy adherence, you are dependent on never accidentally sending to the wrong person (which is a required event to report as a HIPAA breach), and other concerns.

DIRECT, as mentioned by Freiheit, is a direct exchange protocol on the uptake that not only ensures the proper recipient, but authenticates the sender as a trusted source as well, through pre-established circles of trust, so to speak.

Other basic services such as Zix (very straightforward secure email service that basically emails your recipient a message "hey, some stuff was sent...click here and prove it's you [login to secure server] to read it).

If it's a theoretical debate on your thread, you can say "technically it's legal".  If it's in consideration for building a workflow to share that reason, choose another path.

Some decent opinions/descriptions: http://blogs.hcpro.com/hipaa/2010/01/phi-in-e-mail/


What is the real use of certificates on the web? When you get a certificate from a website you visit, signed by a trusted CA, is it trust-worthy because the CA authority did a background check on them?

But how does this help with spoof websites?

Imagine this:

someone made a fakebook.com and made it look exactly like Facebook
user actually typed in fakebook.com himself (by mistake)
fakebook.com has acquired a certificate from on the trusted CAs
The certificate says it is "Fakebook" and not "Facebook" which is fair
The user sees the green icon and is happy. He goes on to use Fakebook.

To prevent the above, should all CAs manually check the website and see if it is intentionally made to look like another website?

I read about a CA that mistakenly gave certificates to an individual claiming to be Microsoft. (http://en.wikipedia.org/wiki/Certificate_authority#CA_compromise) What does this mean? Someone created a website and used "Microsoft" as the owner name? When users visit websites, its not like they actually see who the owner is. All they care about is whether it is signed by some trusted CA. How does it matter what owner name that guy used to acquire a certificate?

is it trust-worthy because the CA authority did a background check on them?

No.
A SSL certificate is comparable to a passport: it says who the person is and which country the passport issued. But it does not say how trustworthy the person is.

The main use of the certificate is to make end-to-end encryption possible, that is protecting against man-in-the-middle attacks by checking, that that host name in your URL matches the name given in the certificate and that the certificate is issued by a trusted CA. No more, no less.

In most cases the only check the issuer CA will do is to see if you have access to a specific email address of the domain, i.e. hostmaster@example.com or similar. For EV certificates more checks will be done but nobody will do background checks of your criminal history or so.

Therefore the only trust you get from the certificate is, that the owner of the certificate probably owns this domain. And even that is not true in all cases because the CA might be hacked or the site had an insecure configuration so that the attacker was able to get a certificate etc.

In no case you can derive from the certificate if the site itself is trustworthy, if it is able to protect your private data, if it got hacked etc. And a certificate does not protect you against spoofed sites or bad guys claiming to be good guys.


What's the use of challenge password in build-key-server and build-key from Easy-RSA? All the OpenVPN/Easy-RSA tutorials that I've found, advise to setting an empty challenge password while building the key for the OpenVPN server.

Anybody knows why? What's the intended use for the challenge password in Easy-RSA server's keys?
And what about client's keys? I see that a build-key-pass exists to generate encrypted client keys, but no server equivalent exists. Still, both build-key and build-key-pass ask for a challenge password.

"Challenge password" is an obscure and usually useless feature. -> Leave empty.
If your CA allows this, then the Challenge Password will be required of anyone who tries to get the cert revoked. -- But from what I understand there are few (or none?) CAs that actually use this. (Please leave a comment if you know otherwise.) So leave it empty if you're unsure.
What's the intended use of a "Challenge Password"?
As far as I understand it the idea is this:
If you have a rogue admin who has access to the cert and key then that admin could revoke the cert and DOS you.
But if you have a CA that will challenge the rogue admin to supply the "Challenge Password", then the rogue admin may not have that password and then you're safe from that DOS.
(The CP is NOT included in either cert or key. Only in the CSR. And you don't need the CSR for daily operations, so presumably operations personnel might not come into contact with the CSR file and therefore not know the Challenge Password.) (But bear in mind that you still have to worry about a rogue admin who has your cert/key. A lot. So from my understanding you gain exactly nothing from having a "challenge password" in the first place. -- Correct me if I'm wrong. I've got the feeling I'm missing some essential idea here. -- Maybe this is meant to allow revocation by somebody holding just the certificate and the password but NOT the private key.)
Further reading
The (too short) official definition is here: RFC 2985: PKCS #9: Selected Object Classes and Attribute Types Version 2.0, Section 5.4.1: Challenge password
The question comes up regularly:

https://superuser.com/questions/376179/confusion-with-pem-pass-phrase-and-challenge-password
https://serverfault.com/questions/266232/what-is-a-challenge-password

Further source:

Randall Perry, "OpenSSL-Users" mailing list, 2014-05-22, Re: CSR challenge password: What's the point?


How can the parallelization in CTR mode be attained? I am using CTR mode to encrypt/decrypt files. Theoretically CTR mode is faster than CFB or CBC because of its individual operations on blocks. In my case CTR mode takes almost as long as CFB.
How can I attain/implement parallelization in CTR mode? Is it internally handled by the system?

In counter mode (CTR) no single block of cipher is dependent upon a previously calculated block.  Each block can be calculated independently of every other block.

This could be parallelized by splitting the cipher into chunks for individual threads to encrypt or decrypt.  Say you have a 512 byte block of data you want to encrypt.  Using AES128-CTR there would be 32 blocks of data to encrypt (512/16).  Say you want to use 4 threads.  You would send 8 blocks to each thread with the nonce and counter range you want them to process.

As each thread finishes you need to piece the encrypted data bytes back together.  So you'd have to ensure that you know which thread has finished, and where in the block of encrypted data you need to place it.  Once all threads have returned, and you've pieced the data together you're done.

If this is performed already it would be at the implementation level.  So if OpenSSL for example supports parallelization of CTR then it's possible.  This might need to be configured (server-side) or you might have to feed it a parameter (client-side).


Haskell in the security industry? I know of a tool called msf-haskell for security but are there others?

Are there any security tools that are written in haskell?  other
than the one above
How much use will haskell be in industry, rather than using python or ruby?
Can you write exploits in haskell?

Google/Github should be able to help you with this question.
The language a tool was written in only matter if you're looking at the source to extend/enhance/troubleshoot the tool and in that case the usefulness of haskell is increased for people that know haskell and decreased for people who don't know haskell
You can write exploits in any language, you don't even need programming at all to write exploits, in many cases a text/hex editor is all that is required.


How to test post login pages for sql injection using sqlmap I have an application in which post login a page is vulnerable to SQL injection. Post login from the browser I captured the request via burp of that vulnerable page and fed the data to sqlmap. But I'm getting the following error.

[15:45:24] [INFO] testing connection to the target URL
sqlmap got a 302 redirect to 'http://localhost:80/dvwa/login.php'. Do you want to follow? [Y/n]  Y

[8]+  Stopped sqlmap -u http://localhost/dvwa/vulnerabilities/sqli/?id=2

This is the data I entered

sqlmap -u http://localhost/dvwa/vulnerabilities/sqli/?id=2&Submit=Submit --cookie="security=low; PHPSESSID=loif1hgpc539lith3rvbe1coh1" --dbs

Kindly advise hot to fix this.

.

I believe you would need to submit the query with the parameter id

This might help you:
sqlmap -u http://localhost/dvwa/vulnerabilities/sqli/?id=2&Submit=Submit --cookie="security=low; PHPSESSID=loif1hgpc539lith3rvbe1coh1" -p id --dbs


How to change default cipher in GnuPG on both Linux and Windows? How can I change the default symmetric cipher used by GnuPG from CAST5 to another?

I'm using GPG4Win on Windows, but would also be interested in a solution for Linux.

If there is no option in the graphical user interface, edit GnuPG's configuration file instead. In the end, graphical user interfaces for GnuPG don't do anything else but calling the GnuPG command line.

Encrypting to Others

There are two options to set the used algorithms for encrypting to other people: cipher-algo [algorithm] and personal-cipher-preferences [algorithm]. Latter is preferred, as it both takes the other user's algorithm capabilities and preferences into account, and complies to the OpenPGP standard; while cipher-algo enforces a given algorithm.

You can look up available algorithms by running gpg --version, on Windows you might have to call gpg.exe --version and cd to the installation directory before. An example output might include:

Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256

To enforce the use of AES256, edit your gpg.conf file and add following line:

personal-cipher-preferences AES256

Receiving Encrypted Messages

You can also set preferences which algorithms you want others to choose when they send encrypted messages to you. This might only be available on the command line, but will have affect no matter what client application the other is using (but remember: it is only a proposal of your preferences, and not enforced, compare with cipher-algo above).

Start the edit menu using gpg --edit-key [key-id] (replacing [key-id] with your key id, and you might have to use gpg.exe again as described above). Inside, you can use showpref to list the currently set up preferences, and setpref to change them. The user interface for doing so is horrible, and you have to provide a long list of cipher, digest and compression algorithms, while the preferred ones always have to be listed first.

An article on debian-administration.org also describes this procedure, and proposes following preferences, which seem reasonable:

setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed


Is opening both TCP/UDP less secured than just TCP or UDP when needed and why? If application needs opened port X UDP, or X TCP combination. Is there any potential risk by opening both UDP/TCP as I usually am not sure which one the application uses?

So, SSH needs port 22/tcp.  You're asking if opening 22/tcp and 22/udp presents a security vulnerability.  The answer is "no" if nothing is listening to 22/udp. If some other application is listening to 22/udp, an application which you wouldn't want open to other hosts, then it could.  There are such combinations (syslog and rsh share 514, for example).

That being said, there's really not much excuse for not knowing which an application uses.  On Linux, for example, you can use netstat -tunlp or lsof -i to see which program is listening to which port(s), and tune your firewall rules correctly.


Google's Mail Delivery Subsystem sending DSN (Failure) caused by spams sent on my behalf I have been receiving Delivery Status Notification (Failure) e-mails from Google's Mail Delivery Subsystem (mailer-daemon@googlemail.com) containing errors like this:

  Delivery to the following recipient failed permanently:

       lau[snip]@de[snip].com.au

  ----- Original message -----

  X-Received: by 10.98.87.15 with SMTP id
  xxxxxxxxxxxxxxxxx.xx.xxxxxxxxxxxxx;
          Wed, 27 Apr 2016 04:57:09 -0700 (PDT) Return-Path:  Received: from
  ipservice-092-209-025-061.092.209.pools.vodafone-ip.de
  (ipservice-092-209-025-061.092.209.pools.vodafone-ip.de.
  [92.209.25.61])
          by mx.google.com with ESMTP id xxxxxxxxxxxxxx.xx.xxxx.xx.xx.xx.xx.xx
          for ;
          Wed, 27 Apr 2016 04:57:08 -0700 (PDT) Received-SPF: neutral (google.com: 92.209.25.61 is neither permitted nor denied by domain of
  Tal[snip]67@mydomain.com) client-ip=92.209.25.61;
  Authentication-Results: mx.google.com;
         spf=neutral (google.com: 92.209.25.61 is neither permitted nor denied by domain of Tal[snip]67@mydomain.com)
  smtp.mailfrom=Tal[snip]67@mydomain.com Received: from
  www.mydomain.com ([127.0.0.1]) by AMAZONA-BAACCEE with Microsoft
  SMTPSVC(7.5.7601.17514);
           Wed, 27 Apr 2016 13:57:08 +0200 Date: Wed, 27 Apr 2016 13:57:08 +0200 Return-Path: Tal[snip]67@mydomain.com To:
  "lau[snip]@de[snip].com.au"  From: Deshawn
  Talley  Subject: Price list Message-ID:
   X-Priority: 3
  X-Mailer: PHPMailer [version 1.73] MIME-Version: 1.0 Content-Type:
  multipart/mixed;
          boundary="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" X-OriginalArrivalTime: 27 Apr 2016 13:57:08.9903 (UTC)
  FILETIME=[40C0DFC0:01D1A068]

I use this gmail to send form responses in my website to myself via SMTP.
There is no message like this in my "Sent Mail" folder.
Should I be concerned with my account's password?
How can I stop receiving this messages and stop these bots from spamming on my behalf?

You should configure SPF.

The e-mail indicates that someone at Vodafone (92.209.25.61) sent a mail with a mydomain.com address as sender. This should not be allowed, since only your mailservers should be allowed to sent such mail and 92.209.25.61 is not one of them. SPF makes it possible to publish which mail servers you want to allow to sent mail from mydomain.com, using DNS records.

After you have configured that, servers that support SPF will drop the message or mark it as spam if it does not come from one of your mail servers, and you will no longer get the bounce messages.


What is Multi-Perspective Validation? The Let's Encrypt upcoming features page lists the following:

  Multi-Perspective Validation

  Currently Let’s Encrypt validates from a single network perspective.
  We are planning to start validating from multiple network
  perspectives.

I haven't been able to dig up any good information on this.

What is Multi-Perspective Validation?

This will help to protect against BGP Hijacking attacks.

During a BGP hijacking attack, the attacker can re-route the traffic though its own servers, allowing him to perform a MITM attack.

This allows him to create malicious responses to the challenges, which will be accepted by Let's Encrypt, and a certificate will be issued to the wrong person because of this.

Because of the lack of effort to fix BGP despite attacks being committed since a long time, Let's Encrypt plans to test a solution named Multi-Perspective Validation.

Using multiple independent networks to perform the validation will require an attacker to hijack more routes than before, thus raising the cost of a successful attack.


Are URL parameters of GET and POST requests over HTTPS secure? It's well known that GET requests with ?xx=yy arguments embedded
can be altered in transit, and therefore are insecure.
If I change the request to POST, and use HTTPS, then the parameters
are in the body of the message, which is encrypted, and therefore
difficult to hack, correct?
Two more cases concern me.  Suppose GET style parameters were added
to a POST request - would those parameters be reliably ignored?
What about some sort of security downgrade attack? If the URL manipulator
forces HTTPS transactions to fail, and then the client/server "helpfully"
downgrade to HTTP, which would allow the unencrypted POST body to be
manipulated.

TL;DR: HTTPS provides encryption, and it's the only thing protecting the parameters.

It's well known that GET requests with ?xx=yy arguments embedded can be altered in transit, and therefore are insecure.

If you are not using encryption, everything is insecure: HTTP, Telnet, FTP, TFTP, IRC, SNMP, SMTP, IMAP, POP3, DNS, Gopher...

If I change the request to POST...

...it does not change anything at all.

and use HTTPS...

HTTPS changes everything.
Any HTTP request not protected by TLS is not protected. No matter if you use GET, POST, PUT, if it's a custom header, none changes a thing.
For example, this is a GET request:
GET /test?field1=value1&field2=value2 HTTP/1.1
Host: foo.exam
Accept: text/html

And this is a POST request:
POST /test HTTP/1.1
Host: foo.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

field1=value1&field2=value2

What is the difference? On the GET request, the parameters are on the first line, and on the POST, the parameters are on the last line. Just that. The technical reasons behind GET or POST are not the point here.

Suppose GET style parameters were added to a POST request - would those parameters be reliably ignored?

It depends entirely on the application. On PHP, for example, if the application expects $username = $_POST['username'], sending it as GET parameter changes nothing at all, as the application will get the POST parameter.

What about some sort of security downgrade attack? If the URL manipulator forces HTTPS transactions to fail, and then the client/server "helpfully" downgrade to HTTP, which would allow the unencrypted POST body to be manipulated.

Not easy for properly configured servers. If they use the HTTP Strict Transport Security header, it forces the client to only access the site using HTTPS, even if the user forces HTTP and port 80. The browser will helpfully upgrade to HTTPS, not the other way.
Even on servers that not use HSTS headers, if the first access is done via HTTPS, it's not trivial to downgrade to HTTP. The attacker must send a faked certificate, and the client must accept the faked certificate in order to an HTTPS connection be redirected to HTTP. But if the attacker succeeded on this, he will usually keep using HTTPS as the client already accepted his fake certificate anyway.


If we integrate CDR in our email solution, do we really need Sandbox as well? In the case of social engineering attack vector is an email sent with a malicious attachment like XSL file, I am not really understanding where we will need Sandbox solution if we can just use CDR (content disarm and reconstruction) solution (in many cases much cheaper for organization)

CDR and analysis inside a sandbox are both techniques which have their own problems.
Sandboxes can be bypassed by clever attackers by basing the behavior of the malware on environment and time and thus not showing malicious behavior inside the sandbox.

CDR instead somehow must assume what kind of payload is allowed in the first place in order to remove everything which is not allowed. This might lead to removing too much payload or too few - like removing every macros from Office documents or every Javascript from PDF even though there are actual valid  and innocent use cases for both. CDR can also not handle every kind of content, which means that any content it cannot handle either needs to be blocked completely or need to be blindly passed through.

If a very strict configured CDR (i.e. only allow very few and clearly innocent things) works for you then it might be the best option. This would be similar to configuring a firewall to only allow clearly good incoming and outgoing connections. But such very strictly configured firewall is often unusable in the real world since there are not only clearly good and clearly bad things bad there is also a grey area of things which actually might be innocent or bad but where this cannot be trivially be found out: like posts to Twitter might be fine but might also be communication of malware. And the same problem with the grey area exists when using a very strictly configured CDR.

Thus it might be necessary to use the CDR in a less restrictive way so that it does not accidentally destroy innocent content. But this also means more risk that bad content can pass through. This risk then again might be reduced by using additional security measures, like having CDR policies based on the (claimed) sender of the mail or by using a sandbox or similar technologies to further analyze not clearly innocent (but not clearly bad either) content.


Meltdown and Spectre vs. dcache timing and dcache leak issues I've heard an expert (or "expert") laugh the current focus on Meltdown and Spectre off by arguing that dcache timing and dcache leak issues have been known and around for years (so nothing new there ...)

Does such belittlement have (some) merit or is the comparison fundamentally misplaced?

Your "expert" is correct that figuring out memory access patterns by cache timing is nothing new.  But the "expert" has completely missed the point of Meltdown and Spectre by focusing on the method that proof-of-concept exploits are using to exfiltrate data.

At its core, Meltdown and Spectre are about on-demand reading of memory that a program doesn't have permission to read.  This is new -- prior cache-timing attacks had to rely on the target program reading the memory the attacker is interested in, in a manner that the attacker can make use of.  Spectre uses the branch predictor to force a target program to perform the desire reads, while Meltdown uses speculative execution to read the memory directly.

The attacks don't require the use of the cache: other timing-based side effects can be used, but don't have the favorable signal-to-noise ratio of cache timing.


How to analyse packets sent by controller in Wireshark? I want to mimic a replay attack on controller PR402. I connected my computer with this controller via TCP/IP <-> Serial Bridge and I would like to analyse packets sent between computer and controller.

First of all, I send a command "Disarm the system" from software provided by the producer and capture these packets in Wireshark. What I would like to do is to capture this packet, find out how and where this command is located in this packet and perform a replay attack by sending a generated frame to the controller. I am new to Wireshark and I am not sure how to begin analysing these packets - I focused on interface which is connected with controller and have few commands captured.

To be more specific - these are (with my knowledge) steps I need to perform:

Capture data with Wireshark
Analyse them, dump to a file
Generate proper packet/frame
Transfer it to the controller and achieve disarming system

Could anyone give me a tip or recommendation what should I do next to achieve the goals listed above? I am not sure how to capture these data to a file and transfer them next to the controller. If it helps to see any more Wireshark screenshots or connection configuration, just let me know and I will post them.
I upload 2 captures. These are just some packets from running the same command - "Disarm system". I found out that packets from 1st to 8th from the first screen and from 2nd to 9th have the same length and I think there this "Disarm system" command was transmitted. Let me know if this is the right direction of analysis.

I want to mimic a replay attack on controller PR402. I connected my
  computer with this controller via TCP/IP <-> Serial Bridge and I would
  like to analyse packets sent between computer and controller.

Because you're dealing with TCP/IP ↔ Serial Bridge, you can assume the data portion of the TCP packet is what's getting carried over onto the Serial line.  So you can ignore everything except the data portion of the TCP packet.

  First of all, I send a command "Disarm the system" from software
  provided by the producer and capture these packets in Wireshark

I assume you're using Roger's PR Master software or the equivalent.  Two things that you'll want to do:

Repeat the "Disarm the system" command several times, separated by time.  This will allow you to see if the command is an exact duplicate each time, or if it includes something that varies like an incrementing counter or a timestamp.
Perform several other commands, several times each.  Again, are they static repeats or do they morph?  Do they have common aspects (e.g., each begins with 0xb03e) or are they all unique?

  I upload 2 captures. These are just some packets from running the same
  command - "Disarm system". I found out that packets from 1st to 8th
  from the first screen and from 2nd to 9th have the same length and I
  think there this "Disarm system" command was transmitted. Let me know
  if this is the right direction of analysis.

Looking at the first capture, I see several small bits of data being exchanged.  (Going back to what I said at the beginning, you only care about data.  You can tell when a packet has data in this example because PSH (TCP "Push" Flag) is being used on all data packets, and the Wireshark view shows "Len=X" to indicate X bytes of data.

1: You -> PR402 3 bytes (0xbe3e01)
2: You -> PR402 9 bytes (???)
3: PR402 -> You 3 bytes (???)
4: PR402 -> You 7 bytes (???)
6: You -> PR402 3 bytes (???)
7: You -> PR402 3 bytes (???)
9: PR402 -> You 1 byte  (???)

Where a 3 byte message commonly initiates a directional series (1, 3, 6), that might be the command, or it might be a meta-command - e.g., packet 1 means "REQUEST", packet 2 means "DISARM", packet 3 means "REPLY", packet means "DONE".

This is where differential analysis, the comparison of capturing different repeats of the same command and different commands, comes in - if you send "ARM", and packet #1 is still 0xb03e01, then that's not ARM/DISARM, it's an attention/request/etc message.

You know you need to:

  Analyse them, dump to a file

With packets this short you're probably just as well off clicking through each packet in Wireshark and typing in the 1-10 data bytes per packet by hand.

So, go through your captures, and summarize what's saying what to whom, write it out just like I did above (but replacing ??? with actual bytes).  Do that for several DISARM and several non-DISARM sequences.  (If you do something like add a user with PIN, then you should see the user id and the PIN in one of the data packets, which will help you understand how these exchanges think of the data as they're exchanging it.)

Once you have those patterns, you'll be able to make a guess at how to implement the DISARM pattern yourself.

  Generate proper packet/frame

You can use something like scapy for this.  If send a TCP packet with data of 0xb03e01, for example:

# scapy
>>> packet=IP(dst="192.168.0.21")/TCP(dport=771)/"\xb0\x3e\x01"
>>> send(packet)
.
Sent 1 packets.

Putting that in the context of a well-formed TCP connection is a little more work.  If you do need to run multiple packets across a single connection, you'll need to dig a little deeper into scapy (for example, reusing sockets), but that's the tool that will quickly and easily do what you want to do.  You could also put a Perl/Python wrapper around nmap, for example, although that gives you a little less per-packet control.

Since you're dealing with a TCP-to-Serial connection, sending individual packets like that - one TCP connection, one packet, and closed - is probably fine.  The Serial bridge probably might care less how many TCP connections are used.

  Transfer it to the controller and achieve disarming system

If you have TCP access to the Serial bridge, then all you need to do is send the packets.  If it works for the PR Master software, and you mimic it correctly it'll work for you.  Remember, this is a physical security device and it likely operates under the assumption that all Serial input is trusted because the Serial line isn't exposed to untrusted physical spaces.  The data size we're seeing in these packet exchanges makes encryption or authentication precautions unlikely.


Will granting access to data without owner approval set a bad precedent? I work for a small company that does contract work that involves storing customer data on our servers for the duration of a project.  We recently adopted more strict folder security in which each team can only access their own folder.  For example, Team A from location 1 cannot access Team B's data, nor can they access their sister Team A's data at location 2.  This mimics the customer's folder security and is how I was instructed by my boss, the director over the account, and a manager representing the team with the most sensitive data.

As one would expect, I have since received multiple requests to grant additional access.  I have insisted that the manager over the team, the closest we have to the owner of the data in the target folder, provide written approval of the requests.  Each time, my team lead has told me that it is a waste of time and to grant access because it was allowed on the old server.  Each time, I have insisted.  My boss sides with my team lead because he believes my team lead will make the right call.

Am I wrong in thinking that IT granting access to customer data without owner approval (or as close as we have to it) sets a bad precedent?  More specifically, can it jeopardize future adoption of ISO 27001 or NERC standards?

To answer your question about ISO 27001; ISO accreditation is based on practices and processes in effect at the time of audit.  If the original process was to leave all sensitive data on a USB stick in the middle of the room and now you change the process and put in proper access controls, rights management, etc., then your ISO accreditation will be based on what you are doing right now.

If on the other hand the boss is routinely bypassing the security measures during and after the audit then you wouldn't get ISO accreditation.

In your particular scenario I would suggest establishing share zones between each pair of teams so that permissions still remain strong but controlled access can be granted.  Once the share zone is established the choice of what to share moves from IT's responsibility to the group's manager.  If a document needs to be removed from the zone then that can also be done easily.  Concerns about users being lazy and dumping everything in share zones are the manager's problem.


Is logging in using OAuth/OpenID also vulnerable to heartbleed? If one has logged into a "heartbleed-vulnerable" site using OpenID, for example, using Google to log into StackExchange, does that mean that the Google password is now at risk as well?

OAuth and OpenID don't send your password to the sites you use OAuth/OpenID providers to login with, so no. Not unless the attack is performed on the OAuth/OpenID provider and provider's servers are vulnerable to CVE-2014-0160 (The Heartbleed Bug). It is however possible, of course provided that sites you're logging into using OAuth/OpenID providers are vulnerable to Heartbleed, that other information could leak, like say your email address, or user session information with which it could be hijacked for the duration that it is valid for.


Renew access token for OAuth2 implicit grant We want to use the OAuth2 Implicit Grant as it is proposed for single page applications. For JavaScript applications which don't have a classic web session. The applications only have access tokens which expire after an hour. We use a central authentication service (CAS) where the user could posess a session.

At the beginning the user doesn't have any session. When the user starts the JS-application it navigates the user agent to the CAS where he gets authenticated via his credentials. After successful authentication he will be redirected to the JS-application with the access token in the fragment.

After short time the access token is not valid anymore and the application needs a new access token. For that the application navigates the user agent to the CAS again. The questions is: what should the CAS do?

The user already has a session at the CAS. Is it allowed to use this session to authenticate the user? In this case the user does not have to provide his credentials again.
The central authentication service could ask for the user's credentials again.

In my opinion asking the user for his credentials once in an hour is somewhat strange so I would prefer the first solution. But would it be a valid way to get a new access token regarding the OAuth2 RFC?

The RFC states "The implicit grant [...] relies on the presence of the resource owner". I think the first solution does not rely on the presence of the resource owner. For example, the resource owner could leave his computer for some hours but the JS applicatino is still running. If an access token becomes invalid the JS application can get a new access token just by navigating to the CAS which automatically authenticates via the session and redirects back to the JS application. This is done automatically without the presence of the resource owner.

The CAS could only be sure that the resource owner is present if it would ask for the credentials again. But that would mean to ask for the credentials every 30 minutes.

If these options don't apply, how could step (B) in Figure 4 in 4.2 of the RFC6749 be realized to renew access tokens?

If you control the CAS then it is upto you how you access a new access token.

Since your user has already authorised the SPA using your CAS, if the session is still valid with the CAS there is no need to ask them to reauthenticate using their credentials.

Of course, it is upto your acceptable risk level for how long they should remain authenticated at the CAS. If it is a high security application, then you may wish to reduce the session timeout or ask yourself why the access token expiration has been set to expire earlier than the CAS session timeout.

Original answer:

Take a look at the Refresh Tokens section.

The session being valid at the CAS should mean that the user agent has a valid refresh token - this is what is needed in order to renew the access token for the user.

  Refresh tokens are credentials used to obtain access tokens.  Refresh
  tokens are issued to the client by the authorization server and are
  used to obtain a new access token when the current access token
  becomes invalid or expires

Correction: Refresh Tokens are not to be issued for implicit grants.

  The authorization server MUST NOT issue a refresh token.

The "presence" of the resource owner is only relied upon for initial authorisation.


Can Wifi probe requests be abused to trick clients into connecting to a fake AP? I just read about WiFi probe requests and that it is possible to track clients by the MAC-Address in the request.

I was wondering if it would be possible to set up a malicious AP which responds "Yes, that's me" to every probe request from clients, resulting in clients automatically connecting to that "known" network. A malicious AP could for example sniff the traffic from smartphones of people walking by whose devices automatically connected. Is that possible in theory?

Yes and No.

First some technicalities, there's no such things as responding "Yes, that's me" since part of the setup of an access point is to set the SSID (name of the network). This SSID is used to create some keys win WPA/2 for the connection to be established and so on. So in the probe response (which responds the probe requests) you announce the client "I'm this SSID"

YES: Somehow it may be possible for open networks

If the client has saved AP with open connection it's pretty easy, just create an access point with the same name (SSID) and voila, the client with just connect as any regular client, no questions asked. And this may be automated.

NO

Most of the cases the the network is protected with WPA/2 or WEP, which you need beforehand the passphrase (password) to generate the keys together with the SSID using PBKDF2*. So unless you own the network (defeats the purpose of a "fake AP") they can't connect to you automatically.

Taken from Wikipedia: /PBKDF2

  *For example, WPA2 uses:

  DK = PBKDF2(HMAC−SHA1, passphrase, ssid, 4096, 256)


Can 2 devices have same host-name on same network? I can see one unknown android device on my network, but it has same host-name as my android device.

QUESTION

1.Is this possible that on same network two different devices can have same host-name ?

2.Is someone spoofing my device and accessing my network ?

SITUATION

1.I have WPA2-psk security key encryption.

2.Both have different but similar MAC addresses. (first three octets are same).

Question 1:
Yes it is possible for multiple devices to have the same hostname on a network, you can simply change the name of any two computers on a network and they will share the same hostname. Unfortunately this can cause a number of different problems, like domain name resolution will not work correctly since they are both sharing the same hostname. Though they can get different IP addresses assigned via DHCP since that uses MAC addressing to assign IP addresses.

MAC addresses are group assigned to manufacturers much like IP addresses are assigned to ISPs, so that's not unlikely if both devices are from the same manufacturer.

Question 2:
Probably not. If you have any friends or family or co-workers (small-business or home network), that have a similar android device and have accessed your network, that entry may be listed in your DHCP Leases/Connected Devices list. If you delete the DHCP lease/disconnect the device in question and it pops up again, it could be caused by a number of things: some devices (phones especially) have multiple MAC addresses and can have multiple DHCP entries, someone could have left a device there, it could be a cracked or stolen wpa-psk key (though I doubt it), and a device spoof seems really unlikely.

Hope that helps!


how can I tell if I'm under IMSI cell phone surveillance I've recently had an encounter with the law, the details of which I won't disclose here since the case is still in court. They took my phone, naturally. I deactivated it as soon as I was released later that day and had another phone activated on the same number, since it's the only way most people can reach me. In addition to that line I have a separate work phone. Both are on the same carrier (Sprint), and I usually have rather poor cell phone signal at home. What makes me wonder is that my work phone (older HTC android model) gets signal more consistently, while my primary line (Galaxy S4) frequently shows a red X instead of any signal bars. Quite frequently since the incident occurred I have been unable to use my primary line for up to an hour or more while the work phone has good service. This is sometimes alleviated by restarting it. Is this any indication that a Stingray/IMSI device is intercepting my calls?

The most plausible explanation for a phone with poor reception is that the phone's hardware is faulty in some way (either that specific phone has an issue, or the phone design is flawed). Expensive phones don't necessarily guarantee good reception.

IMSI-Catchers are active devices that pose as fake base stations. Details are not really public; however, it seems that when such a device is active, it cannot (easily, or at all) intercept connections for only one specific phone. Thus, all phones in the vicinity ought to be equally affected. This is not consistent with the symptoms you observe. Therefore, either IMSI-Catchers have become more advanced and selective, or you really are not under that kind of surveillance, and your S4 phone is just bad at radio communications.


Is it safe to trust a Docker container? When it comes to Docker, it is very convenient to use a third party container that already exist to do what we want. The problem is that those containers can be very complicated and have a large parent tree of other containers; they can even pull some code from repositories like GitHub. All of this is making a security audit harder.

I know it could sound naive, but could it be easy for someone to hide some malicious content in a container? I know that the answer is YES but I would like to know in which dimension, and if it's worth the risk. I'm a familiar with GitHub, and I usually take a look at the source-code when I use third party code (unless it's a well known project.)

I am wondering if the community is watching for those kinds of behavior because the harm of a malicious container could be bigger than malicious code.

How likely is a container to be malicious? (Considering it's a popular one.) As well, what dimensions could damage/use the other components of the underlining system or the others systems on the LAN ? To be even simpler, should I trust them?

Edit:
I found an article from Docker that brings a bit of light in Docker security and best practices: Understanding Docker security and best practices
.

At the moment there is no way to easily work out whether to trust specific docker containers.  There are base containers provided by Docker and OS providers which they call "trusted" but the software lacks good mechanisms as yet (e.g. digital signing) to check that images haven't been tampered with.

For clarification to quote the recently released CIS security standard for docker section 4.2

  Official repositories are Docker images   curated and optimized by the Docker community or the vendor. But,the Docker container image signing and verification feature is not yet ready.

  Hence, the Docker engine does not verify the provenance of the container images by itself.

  You should thus exercise a great deal of caution when  obtaining container images.

When you get into the world of general 3rd party containers from Docker hub, the picture is even trickier.  AFAIK docker do no checking of other peoples container files, so there's a number of potential problems

The container contains actual malware.  Is this likely, no one knows. Is it possible, yes.
The container contains insecure software.  Dockerfiles are basically like batch scripts that build a machine.  I've seen several that do things like download files over unencrypted HTTP connections and then run them as root in the container. For me that's not a good way to get a secure container
The container sets an insecure settings. Docker is all about automating set-up of software which means that you are, to an extent, trusting all the people who made the dockerfiles to have configured them as securely as you would have liked them to.

Of course you could audit all the dockerfiles, but then once you've done that you'd almost have been better just configuring the thing yourself !

As to whether this is "worth the risk", I'm afraid that's a decision only you can really make.  You are trading off the time needed to develop and maintain your own images, against the increased risks that someone involved in the production of the software you download will either be malicious or have made a mistake with regards to the security of the system.


Is OAuth appropriate for a private API to be used by registered customers? I am developing a private API that will be used by pre-registered clients to access information on our website. We will be storing their login credentials on our server. When looking into how to ensure the security of this API, I have noticed that OAuth seems to overwhelmingly be recommended for authenticating the users. I am trying to figure out if OAuth is appropriate for a case like mine, or if OAuth is geared more for public APIs. I understand the usefulness of OAuth if you want your users to access your site through a third party like Facebook or Google, and if you want your API to be open to the public without requiring a registration. However, the overwhelming amount of info on OAuth is related to these uses. If I want a simple, private API open only to pre-registered clients, what would be the benefits of using OAuth instead of a more traditional API key authentication? Is it worth the extra complexity if you don't need the extra login functionality it provides? Thanks very much.

Assuming that the API clients need to access information on their own behalf, rather than on a third-party user's behalf, then that should correspond to the "Client Credentials" authentication flow in OAuth 2.

Consulting the spec, that's effectively a request amounting to "here is an ID and a pre-shared secret", and a response with "here is a token that lets you access resources" - extremely similar to traditional authentication with a username and password.

Looking at it like that, you could use a limited subset of OAuth 2 for the sake of future-proofing your API in case it ever needs any of the other OAuth functionality. Or, if you already have some authentication layer based on username+password, you could potentially re-use some of that logic for this. In the case of Client Credentials, the two approaches appear essentially the same from a security perspective.

Now, one usability benefit of using OAuth 2 client credentials is that the client developers can use existing off-the-shelf libraries if they so choose, rather than being required to build a custom authentication layer in their client app. So for that reason, building a simple OAuth 2 client credentials workflow seems like a good approach.


Why is storing passwords in version control a bad idea? My friend just asked me: "why is it actually that bad to put various passwords directly in program's source code, when we only store it in our private Git server?"

I gave him an answer that highlighted a couple of points, but felt it wasn't organized enough and decided this might make sense to create a canonical question for.

Also, how does not storing passwords in the source code relate to principle of least privilege and other foundations of information security?

The way I see it, not storing passwords in Git (or other version control) is a convention. I suppose one could decide not to enforce it with various results, but here's why this is generally frowned upon:

Git makes it painful to remove passwords from source code history, which might give people a false idea that the password was already removed in the current version.
By putting the password in source control, you basically decide to share the password with anyone who has access to the repository, including future users. This complicates establishing roles within a developer team, which might have different privileges.
Source control software tends to get pretty complicated, especially "all-in-one" systems. This means that there's a risk this system might eventually get compromised, leading to password leakage.
Other developers might be unaware that the password is stored and might mishandle the repository - having keys in the source means that extra care would have to be taken when sharing the code (even within the company; this might create a need for encrypted channels).

I cannot say that every pattern related to infosec is good, but before breaking them it's always a good idea to consider your threat model and attack vectors. If this particular password got leaked, how difficult would it be for an attacker to use it to harm the company?


IPv6 private network adressing While sniffing a training network with Wireshark, I realized that it contains some IPv6 addresses.

So I decided to nmap one of the IPv6 address found (with the -6 option), and was able to see my own IPv6 address on the network.

Is there an equivalent type of addressing IPv6 compared to IPv4, that is to say, if my IPV6 address is: fe80::6197:27:66c:d8e

What range of address would the private network be?

Could it be?

fe80::6197:27:66c:0000/112

or another format?

The address you show is a link-local address (fe80::/10). Those appear on any network and are non-routable. That means they are for local communication on your LAN only. They are commonly used for things like neighbor discovery, auto-configuration mDNS and streaming from one device to another (i.e. Apple TV).

Link-local addresses are somewhat similar to APIPA (169.254.0.0/16) addresses in IPv4.

If you're looking for private addresses then you want the ULA range: fc00::/7. The first half of that range (fc00::/8) is still reserved, but the second half (fd00::/8) is commonly used on home networks and also on other networks that are not connected to the internet.


How can a system grant constant access without using a constant key? We need to implement an authentication for users from one system to another. Previously we were using OAuth (user enters username/password and system get a temporary access key and a constant refresh key to refresh the access key), but now we have decided to improve security and stop using this system because the refresh key is constant. We are looking for a way that does not require the storage of any constant key to avoid a situation where somebody who steals the key and gets access to the system forever without us having a way to know about it and change the key.

A simple solution is to update the refresh key every defined period of time by  requiring the user to login again. But our client wants users to log in only one time and shouldn't have more "problems" with authentication after that.

This situation seems mutually exclusive - the system should not have a constant key but should allow constant access. Is there any way to combine the two?

It can't be done. The logged in used needs to prove they are the person that authenticated manually. To do that you need some kind of token. Look at it this way - what if the client machine was cloned? How would you be able to tell apart the real and the fake?

The only alternative is on expiry forcing the user to re-authenticate manually.


Credit department is asking me to email them a color copy of my US social security card - how unsafe is this? I applied to take over a friends lease vehicle because they are moving to Europe, and received an email from the vehicle manufacturers lease department, asking that I submit a color copy of my U.S. Social Security Card.

I called their customer service number and asked if they have a way for me to upload this directly to their server, but the answer to that question was "no". However they did tell me that I can fax it but they are still expecting to receive a color version of the card.

They also said that their email is secure but it is the transit that I am a bit concerned about.

So, unless I am able to find a local faxing service that has a color fax, the only option given by this car manufacturer is for me to email the copy of the card.

I wanted to get a better idea of the risks of emailing a scanned copy of a U.S. social security card. What are the risks with doing so?

I would recommend that you do not include a color copy of your U.S. social security card in this matter. Even if they say that it is a secure transaction, it would be safer to assume that it is not. Email servers get compromised all the time. It would be incredibly risky.

One red flag in this email is them rushing you to send it: this is not typical, and sounds like a phishing attempt. The subject line URGENT ACTION REQUIRED and threatening an undesired action if you do not comply within a strict time frame is a sign of this.

In addition, I'm not sure what avenue you could take to even verify that is indeed Mercedes-Benz. I would locate a number independent of this email to phone Mercedes-Benz and ask about this kind of email. They should be able to accommodate your request based on security concerns. If they do not, like ISMSDEV said, its up to you whether or not take this risk if this is the only method they will allow.


When I run this command in OpenSSL, it also creates a file called `serial_number.pem` Note that 00 in 00.pem is the serial number of the certificate.
When I run this command, it also creates a file called 00.pem in the new certs directory.
The 00.pem has the same content as enduser-example.com.crt.
Here is the command:
openssl ca -batch -config enduser-certs/enduser-certs.conf -notext -in enduser-certs/enduser-example.com.csr -out enduser-certs/enduser-example.com.crt

The configuration file enduser-certs.conf is:
[ ca ]
default_ca = myca

[ crl_ext ]
issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always

 [ myca ]
 dir = /path/to/SSLCA/intermediates
 new_certs_dir = /path/to/SSLCA/enduser-certs
 unique_subject = no
 certificate = $dir/Example Intermediate Certificate Authority.crt
 database = $dir/certindex
 private_key = $dir/Example Intermediate Certificate Authority.key
 serial = $dir/certserial
 default_days = 365
 default_md = sha512
 policy = myca_policy
 x509_extensions = myca_extensions
 crlnumber = $dir/crlnumber
 default_crl_days = 25

 [ myca_policy ]
 countryName             = optional
 stateOrProvinceName     = optional
 localityName            = optional
 organizationName        = optional
 organizationalUnitName  = optional
 commonName              = supplied
 emailAddress            = optional

 [ myca_extensions ]
 basicConstraints = critical,CA:FALSE
 keyUsage = digitalSignature,keyEncipherment
 extendedKeyUsage = serverAuth
 subjectKeyIdentifier = hash
 authorityKeyIdentifier = keyid:always,issuer
 crlDistributionPoints = @crl_section
 authorityInfoAccess = @ocsp_section
 subjectAltName  = @alt_names

 [alt_names]
 DNS.0 = *.example.com
 DNS.1 = example.com

 [crl_section]
 URI.0 = http://pki.example.com/Example Intermediate Certificate Authority.crl

 [ocsp_section]
 OCSP;URI.0 = http://pki.example.com/ocsp/
 caIssuers;URI.0 = http://pki.example.com/Example Intermediate Certificate Authority.crt

Is this normal?

From the documentation of ca:

-outdir directory The directory to output certificates to. The certificate will be written to a filename consisting of the serial
number in hex with .pem appended.
...
new_certs_dir
The same as the -outdir command line option. It specifies the directory where new certificates will be placed. Mandatory.

So yes, this is the documented and expected behavior.


Can't Amazon see my files if I use s3cmd/gpg with a complex password? Since the early days of s3cmd I use it in combination with random generated filenames (uuidgen loop) and a complex passphrase (pwgen -n1 -c 32 -y). On security.stackexchange.com search there is only 1 result for s3cmd.
I use Amazon S3 (Glacier) for offsite backup of my personal files.
I wonder if this in 2020 still the state of the art solution for security?
How secure is it? Is there a guarantee that Amazon can't view the files?
s3cmd -e -vv put --recursive --acl-private /xxx/yyy s3://ppp

See https://s3tools.org/s3cmd-howto for information on how you can configure s3cmd to use GPG on the client side, to encrypt files on the client side before they are transferred to Amazon s3, using a key stored on the client side.
Notably:

You can optionally enter a GPG encryption key that will be used for
encrypting your files before sending them to Amazon. Using GPG
encryption will protect your data against reading by Amazon staff or
anyone who may get access to your them while they're stored at Amazon
S3.


Remote Desktop - Can my company see web browsing in other applications while connected? I access work on my personal mac via a remote desktop connection..I do this on a mac and access it via safari. My question is, can my company then see what I am browsing in Firefox while connected to the remote desktop in safari?

That depends on the VPN specification you're using. However, if you are connected via VPN you should probably assume that everything you do is visible to the VPN provider if they want it to be. And therefore you should not look at anything the VPN provider would not want you to be looking at, and/or you should trust them to respect your privacy.

If you want to find out where your traffic is traveling, you can open terminal and just type traceroute cnn.com (or any website you prefer). This will show you the path your request takes to the resource. It may or may not be easy to recognize your company's servers from this. You can then disconnect VPN and run the same command again and compare the two results.


Is the following set of steps, secure enough, during register and login on my webapp? Register:

Both text boxes of the user inputted password are compared, if they match:
Add the user's email to the [users] table in the database, to have a user ID to later record everything against.
Create salt. Anything random enough, and complex enough will suffice. UserName+current dateTime - MD5 hashed. GUID, UserName + Random number hashed, etc.
Record the salt in a Salt table in the DB alongside the user ID and name.
Add together the user Password and salt.
Hash that using Encryption1
Hash that using Encryption2
Record that, alongside the user ID and their details (if any) they provided in the registration form.
Optional email verification sent out, to make sure they are using a legit email.

Login.

Get the salt using the user inputted username.
If salt is returned do Steps 5-7 from the Register (pwd+salt, hash, hash)
When we retrieved the salt, we also got a user ID, compare the outcome of Step 2 and the ID against the records in the database.
If there's a match then the user used their email and password and are allowed to login.
Create session variable and allow them to proceed.

A benefit I believe all this carries is, even if my entire database is accessed in a raw unprotected form, the password is a 50 character long string hashed twice using different encryption methods.

Following your lead, I'm just going to list my thoughts:

Make sure the email address isn't already in use
To be clear, the MD5 hashing algorithm doesn't add randomness to anything.  As a result, it isn't really doing a whole lot for you here, other than making it not-immediately-obvious where your salt came from.  I think it would be better to use a CSPRNG to generate your salt than basing it off of user data and running it through MD5.
This is an application nitpick, but it sounds like you are creating the user record (step 2) and then coming back and storing the salt (step 4) and then storing the hashed password (step 8).  There is no reason you can't just do all of that in one insert operation.  You'll get better performance, but most importantly, your code will be simpler and easier to maintain.
To be clear, you don't want to use an encryption method to hash your passwords.  Hashing and encryption are two separate concepts with different preferred algorithms.  Make sure you are hashing: not encrypting.  From what you have written I think that you are on the right page, and are simply using the wrong terminology.  It's an easy mistake to make, but the difference is critical enough that it is worth me pointing this out.
There is no good reason to use two separate encryption algorithms.  The only reason to do such a thing is to make it so that people can't try to brute force your passwords if they find your database.  However, it is a security measure that relies on your source code being kept secret.  Sometimes they both get leaked though.  This step isn't useless, but it also isn't as useful as you might think, and it complicates your code.  If you want a protection like this I would just include a pepper and stick to a single pass of a secure password hashing algorithm.
On login, make sure you only ever return a single, non-descriptive error message to the user "Invalid username/password combination"
Don't do a simple comparison of the hashed password of the user to what comes out of the database (i.e. $hashed_input == $user_hash).  There are some subtle ways in which such a straight-forward comparison can be used by a malicious attacker to help crack passwords.  Some languages have helper methods to facility password hash comparisons.  Use one or find one.

There can be a large number of subtle ways for security bugs to creep in to the login system of an application, which can easily be missed in an overview like this.  Considering that it is the first line of defense of your application, it is important to get user authentication right.  As a result, your best bet is to use a well-tested and well-supported authentication module that already exists, rather than building your own.  If you do decide to stick with writing your own, then you should at least post your code on codereview.stackexchange.net afterward.


Security camera NVR is making my network not PCI compliant. What can I do? So family operates a small bar/lounge in Florida and I work for them part time as a bar back / IT technician. For the past couple months we have been trying to become pci compliant. However, we keep running into issues with passing a network vulnerability scan (which I think is being caused by our icrealtime security camera nvr)
We use clover stations for our 3 pos/terminal systems and are, according to cloversecurity site, SAQ type C.
The vulnerability report is as follows:
General remote services - SSL Certificate - Signature Verification Failed Vulnerability httpsport / tcp over ssl
CGI - HTTP Security Header Not Detected httpsport / tcp
General remote services - SSL Certificate - Invalid Maximum Validity Date Detected - httpsport / tcp over ssl
General remote services - SSL/TLS Server supports TLSv1.0 - httpsport / tcp over ssl

This is how I have the network set up:
Spectrum modem - > Edgerouter X
On the ERX all 4 ethernet ports are separated (e.g. .1.x , .2.x, .3.x , .4.x).
The .1.x has our jukebox and ATM machine.
The .2.x has our IoT (atm only security camera)
The .3.x and .4.x contain our pos on one and employee and guest wifi (on a r500 AC point)

I have a firewall ruleset allowing only related/established access to the security camera but blocking IoT network from accessing other lans. I am also dropping connections to the http and https ports for the security camera network but the scan still fails.
I can disable https on the box but can't disable the http and when I do that I still get an error for:
HTTP Security Header Not Detected httpport / tcp

I'm not sure what else I can do? AFAIK its only the remote gui/webserver of the security camera nvr causing the issues.
additional information: I should have a working security certificate from letsencrypt on the ERX so as I don't get a warning when accessing the gui on my local network (router gui can't be accessed outside network and POS network and guest network are blocked from accessing that gui)

PCI compliance is for payment processing. Don't put your cameras on your payment processing system.
You want the cameras on their own network so that any camera system compromise doesn’t become a stepping stone into your financial transactions.
You should of course secure the cameras as well, but they need not have any interaction with PCI once they are isolated.