Securing a Web URL when called by a client application

You're trying to use your vendors as Single Sign On providers. That is absolutely possible... if they are willing to implement some federated identity protocol like OAuth, SAML, Kerberos, etc. This would involve substantial engineering work on their part, and probably substantial burecruatic work and legal liability since HIPAA is in play. (I don't know. I'm not your lawyer).

For the reasons you've listed, relying on the Referer header or a shared, unlimited-use, unaccountable secret is absolutely out of the question. Further, trusting a user simply because he was logged in at a trusted vendor is also out of the question. Your API needs to know who, specifically, is acting on it, and store/log that information. Your business may not care, but HIPAA does.

SSO/federated identity protocols are ways of generating, passing, and checking tokens like your Option 2 that are specific to the user, time window, etc. Don't invent your own. OAuth is probably the easiest to implement.

The simplest solution is to build user accounts into your NodeJS app. Users must be logged in (have session cookies) to get anywhere with the URL from your vendor. No federated identity problem.

Another fairly simple solution is to have your API and your vendors' backends communicate directly, with no end-user browser in the loop. HTTPS and a simple token in an HTTP header would be reasonable. Mutual TLS with client certificates is the gold standard. But this relies on the secrets staying in the backend. This would also mean any changes in the way you interact are code changes for your vendors.

The real solution is to implement an Identity Provider (farm it out to Microsoft Azure, AWS, or OneLogin, or hire consultants to do it inside your firewall) and integrate it with all your vendors and your API so that your users only have one account to deal with. Your existing vendors almost certainly don't want this role. SaaS folks might not want it because HIPAA, but probably one of them will be willing to execute a HIPAA Business Associate Agreement for the right price.


Spoofed email: can't determine Purported Responsible Address

DATA
354 Enter mail, end with "." on a line by itself
this is the email body
.

You don't send any mail header which also means that you don't send any From field in the mail header which means that server cannot extract From and use it for verification. See also RFC 4407 - Purported Responsible Address in E-Mail Messages.


You have two solution:

Use HPKP and a trusted certificate
Keep your custom CA and use the Firefox addon "Certificate Patrol": https://addons.mozilla.org/fr/firefox/addon/certificate-patrol/


Can WebAssembly execution be disabled in browsers?

I did some more search and disabling is not complex. In e.g. https://github.com/stevespringett/disable-webassembly for Firefox one should:

  Enter about:config in the URL bar and change javascript.options.wasm
  to false

I've checked with sample app https://subzey.github.io/wasm-canvas2d/ and it indeed changes working app to not-working.


How can I partially overwrite the EIP in order to bypass ASLR?

With ASLR not the full address of instructions will vary but only some higher bytes. So for example Byte 1+2 are static but Byte 3+4 not. So the idea behind partially overwriting the EIP is to overwrite only the static bytes of an address to get a (limited) control of the execution flow.


Is there something similar to Firejail for OpenBSD?

Some developers are working on a sandboxed version of Chromium. I don't know if there is a public diff or not. With pledge and unveil, they can limit the syscalls used and the directories viewed by Chromium.

Firefox only uses pledge, so it has not whitelisted/blacklisted directories.


You need an internet connection to download it and for it to update its threats database. Apart from that, you don't really need internet access to have it scan your device. As for how it works, each anti-virus has a threat database which uses to scan files for malicious signatures. Some more advanced will also look for abnormal behavior in the execution of an app, like network connections, root attempts etc.


Easy there cowboy, you've got about 15 years until this is really a problem. You are also making a massive assumption that NTRU is going to be the cryptosystem of choice for a post-quantum age.

NTRU is part of a collection of schemes called "Lattice-based crypto". Still within lattice-based schemes, many people prefer Ring Learning With Errors over NTRU for several reasons. In general, the expert cryptographers of the world agree that lattice-based schemes - as a whole - is a branch of mathematics that we don't understand well enough to trust them with any serious information at the moment.

There are also collections of crypto schemes called "code based" with McEliece being the leading candidate, and isogeny-based techniques, both of which are considered better than NTRU for reasons of security, key size, and speed.

Bottom line: none of the post-quantum algorithms are mature enough yet to be included in anything other than research code (although it wouldn't shock me if GPG included an experimental version at some point). Try again around 2020.

EDIT:

In response to your updated question:

  So can I use any quantum safe algorythm for sending e-mails already?

No, no you cannot. None of these algorithms are considered safe yet; they still need several years of research by basic mathematicians before we decide whether or not to trust them. Then we need to standardize protocols and stuff around them.

I understand that you read something on the internet and now you're on a crusade about it. Trust me, this is moving as fast as it can - in the world of mathematics research, sometimes a theorem takes 200 years to prove - by comparison 5 years for completely redesigning crypto is warp-speed. You'll get your GPG / TLS / Thunderbird plugins by the year 2020. Until then you need to chill out.


need network level security alternatives to a VPN

Get a better VPN.  You don't say specifically what you are trying to do, but if a VPN is needed, then a VPN is needed.  VPN isn't a particular solution, it is a class of solution.  It is designed to make a secure, private network over an open network.  You can use any of a number of different types of VPNs to implement that functionality.

If you don't actually need a full VPN functionality, you will have to give more details about what you actually need to be able to do.


Can't understand SNORT rule pcre option syntax "?P=name"

(?P<var>\w+)

How to read this expression:

'('        = Open matching group.
'?P<var>'  = call this matching group "var"
'\w+'      = one or more alphanumeric/underscore characters
')'        = close matching group.

Next part is simply asking for the named backreference:

(?P=var)

For the next piece of syntax:

(?<element>\w{1,20})

'('          = open matching group.
'?<element>' = Name this matching group "element"
'\w{1,20}'   = match any alphanumeric or underscore a minimum of once, and a maximum of 20 times.
')'          = close matching group


Documentation on Snort rules and alert tuning, especially for new users

You're encountering one of the most basic issue with pretty much ALL monitoring system: how to handle the data generated properly and separate the signal from the noise.

Unfortunately for you, there is no easy answer because it all depends on your what your resources are and the value of what you're protecting.

Let me be more specific: if you're working with a small, high-value network and have plenty of (competent) people to handle the task, you can leave all alerts on and investigate all of them completely. That is obviously very expensive and you need highly trained people (and probably very smart software) to be able to handle it correctly.

On the other hand of the spectrum, if you have a large, low-value network with few people available for incident handling, then you could decide simply to log everything and only investigate issues that are explicitly flagged as incident through a different channel ("Who changed the password of the CEO's email?"). Your IDS will still be of value to you because you can use the logs for some post-mortem analysis of an incident but it will not allow you to react proactively.

Most networks falls in between these two extremes so you're supposed to create alerts that match as closely as possible your actual threat level and response capacities. That takes time and it's a process that should be continuous: you'll have to adjust your rules to react to new threats, changes in usage or in capacity all the time.


What makes an SSL session pick one cipher over another?

In the first step the server aligns the ciphers offered by the client with the ciphers configured for the cipher to get a set of common ciphers. From this set the server then selects a single cipher.  There are various strategies possible for this selection but usually it boils down to a selection either on the cipher order given by the client or the order configured in the server.

What you see here is probably a different value of the SSLHonorCipherOrder option in Apache (and similar options in other servers). With SSLHonorCipherOrder on it will choose the cipher depending on the preference of the server and thus pick from the top of the servers list, i.e. SSL_RSA_WITH_RC4_128_MD5 in this case. With SSLHonorCipherOrder on it will instead choose the cipher depending on the clients preference and choose the better cipher TLS_DHE_RSA_WITH_AES_128_CBC_SHA.

  Both appear to have certificates with the same signature Algorithm - SHA256 with RSA and both are owned by the same company.

The certificate does not have much relevance for choosing the cipher. You can only use ciphers with RSA authentication with RSA certificates and ciphers with ECDSA authentication with ECDSA certificates but apart from that there is no dependence.


Google hacking - why "numrange" is so dangerous?

I did little more digging by myself and I was playing with Google for a couple of hours...

The numrange operator was much more problematic when it was introduced by Google than it is now. A couple of years ago you could harvest CC#s, but then Google limited the range of numbers in a query to 5 digits. If you use 6 digits in a query then you get this:

However, it is still possible to harvest SSNs. The trick is to break a number (SSN) into smaller pieces.  In the USA, the first three digits of an SSN represent the state. The second group of numbers (2) represents the group number and the last group of digits (4) indicates the serial number.

The query itself could like like:

+ssn "486..500-01..99-0001..9999"

This would return all SSN from Missouri.

The Numrange operator has legitimate uses (unrelated to social-engineering) such as searching for addresses, price ranges, page numbers, years (e.g. Aston Martin 1950..1960) and so on.


Using AES encryption to generate MAC (and provide authentication/integrity)

A signature  is created with a secret private key and verified with a public key. What you're talking about is a MAC, which is created and verified with the same key.

If you want to create a MAC with AES, then there's already a standard algorithm for that. It's called CBC-MAC, and it basically involves encrypting the plaintext using CBC mode and using the last block as the MAC (but be wary of pitfalls).

If you want to create a MAC using a hash like SHA-256, you're much better off using HMAC, as it's a standard algorithm with provable security properties (assuming certain things about the hash, but even MD5 is still very secure when used with HMAC).

aes(sha256(plaintext)) might be ok, but don't roll your own! If you really want to show something wrong with it, you could try pointing out that it's non-standard and relies on the security of both AES and SHA-256, whereas HMAC-SHA256 is standard and relies only on the security of SHA-256.


security in the browsers - broad questions

"Browser security" is about far more than secure connections. Using HTTPS to secure the connection between browser and server is an important part of browser security, but it's certainly not the whole thing. To show what I mean, here are some things off the top of my head (and by the way, I have never done any work related to browsers, these are just things I've heard about):

Javascript Sandboxing: So your browser is going to download and run arbitrary javascript code. What if this code is malicious? Can it read the user's personal files on the hard drive? Can it modify files on the hard drive to plant viruses? Can it read data from other tabs? Can it force the browser to do something malicious on its behalf? These are things you need to think about when designing a browser.
Browser extensions: Most major browsers have some system for people to add extensions written by other random people. Unlike javascript, once installed these are part of the browser and can not be effectively sandboxed. What security features exist around these? Do they have to be reviewed by a security team before being allowed on the app store? Will the browser monitor them and disable the extension if it breaks the rules?
Cross-Site Scripting (XSS): If I have two tabs open, can one tab get access to the cookies / session info for the other tab, allowing it to impersonate the other tab through GET / POST requests?
Media file exploits: Many browsers now include built-in media libraries for things like PDF, audio, video, etc. These are very complex media types with long lists of supported codecs. Libraries that parse them are notoriously buggy for things like buffer overflows that allow arbitrary code execution. How much security analysis have you done on the libraries that your browser compiles against?
Root Certificates: Most browsers now embed (aka "pin") the root SSL certificates into the source code of the browser. How fast will the browser issue a security patch if one of the root CAs is reported to have a breach?

Those are just examples off the top of my head. Bottom line: "Browser Security" is a HUGE topic.

To answer your other two questions:

  How does the level of security differ from one browser to another?

That depends on which browsers you are comparing. Firefox and Chrome? They are pretty similar. Firefox and the browser my friend wrote for fun last weekend? There's a pretty big difference. Everything else will be somewhere in the middle.

  Insecure connection: browser issue or network issue?

Yes. Also No.

Sometimes it's the browser's fault. Sometimes it's the network's fault. Sometimes it's the server's fault, or the OS's fault, or the user's fault, or the IT department's fault, or openssl's fault, or the VPN's fault ... the list goes on.

Actually, scratch that, a good security developer will write their code under the assumption that the other machines on the network are malicious (hopefully, including routers). So a faulty network should not be able to cause an insecure connection, but even if it can that doesn't mean it's the browser's fault: it could be any of those other things I mentioned.


Categories of security when evaluating services and protocols

Solving small problems is certainly easier than solving big problems. But you might want to think about how you would decompose these categories further into a hierarchy (decompose the problems further before trying to find answers). e.g. typically what you have described as login security is decomposed into access, authentication and authorization.

You will probably find that you will want to revisit and develop this hierarchy as you work on the analysis.

A fairly obvious gap in your current model is that you are only considering an us-and-them scenario - but as a service provider, there are at more parties involved. Does the system you are evaluating (for example) provide a means of attributing activities to specific individual or at least differentiating between your customers and yourself?

Another approach (complementary - not exclusive) is to cast yourself in the role of the attacker and consider how the system you are evaluating prevents you from acheiving some nefarious purpose - read someone's email, modify a project proposal, deface a website....Given a specific outcome facilitates making informaed choices about whether a solution which is not completely secure (i.e. all of them ;)) is worth the risk - take a guess at the probability of someone wanting to achieve the outcome, multiply by a guess at the probability that the solution can be thus exploited, and multiply by the cost impact. (There are more complex models for risk assessment).


Assuming that the passphrase was randomly generated, the two pieces of information needed to perform the calculation for a fully brute force attack are:

Keyspace. This is how many possible combinations there are. In this case, 26 upper-case, 26 lower-case, and 10 digits = 62 characters, in eight positions (so 62^8, 62 to the power of 8, or 62x62x62x62x62x62x62x62).

Real-world GPU cracking speed. This is highly variable depending on the platform. Benchmark numbers for tools like hashcat are generated under ideal conditions which can't usually be achieved in real-world attacks, so running the actual attack is the gold standard for determining real-world throughput, and then doing the math to match your target scale.

Here is an attack under the parameters in your question, running on 6 GTX 1080s:
$ hashcat -a 3 -m 2500 -2 ?l?u?d hashcat-wpa2.hccapx ?2?2?2?2?2?2?2?2
hashcat (v4.1.0) starting...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #2: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #3: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #4: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #5: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #6: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU

[...]

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Applicable optimizers:
* Zero-Byte
* Single-Hash
* Single-Salt
* Brute-Force
* Slow-Hash-SIMD-LOOP

Password length minimum: 8
Password length maximum: 63

Watchdog: Temperature abort trigger set to 90c

[...]

Session..........: hashcat
Status...........: Running
Hash.Type........: WPA/WPA2
Hash.Target......: 8381533406003807685881523 (AP:ae:f5:0f:22:80:1c STA:98:7b:dc:f9:f9:50)
Time.Started.....: Wed Apr 25 06:39:06 2018 (4 mins, 40 secs)
Time.Estimated...: Sat Oct 23 07:02:24 2021 (3 years, 181 days)
Guess.Mask.......: ?2?2?2?2?2?2?2?2 [8]
Guess.Charset....: -1 Undefined, -2 ?l?u?d, -3 Undefined, -4 Undefined
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:   332.4 kH/s (6.93ms)
Speed.Dev.#2.....:   327.8 kH/s (7.06ms)
Speed.Dev.#3.....:   329.5 kH/s (7.00ms)
Speed.Dev.#4.....:   328.7 kH/s (7.01ms)
Speed.Dev.#5.....:   330.4 kH/s (6.96ms)
Speed.Dev.#6.....:   330.1 kH/s (6.98ms)
Speed.Dev.#*.....:  1979.0 kH/s
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 553451520/218340105584896 (0.00%)
Rejected.........: 0/553451520 (0.00%)
Restore.Point....: 8437760/3521614606208 (0.00%)
Candidates.#1....: etET7778 -> exQC5678
Candidates.#2....: 1BDpERIN -> 1r8tBONA
Candidates.#3....: l5MUQURL -> lEeqNANA
Candidates.#4....: bjHuRANA -> bCLfNANA
Candidates.#5....: 2Rh7MANA -> 2VLbLESS
Candidates.#6....: rFrR7778 -> r0xsANAN

Once you know the performance of your GPU for that hash and that attack, you can multiply that speed (or divide that time estimate) by the number of GPUs you'll have. If you need to scale out across multiple chassis, tools like Hashtopolis or hashview can manage a cluster of systems. If I had ten systems like the above, it would take 1275 days / 10 = ~4 months to fully exhaust the keyspace (and ~2 months to crack the average case). You get the idea.
For your other capacity questions, in practice, you don't need a lot of CPU for the attack itself when using hashcat. I'm told that recent versions of hashcat do work best when the host system has roughly much RAM as the total amount of GPU memory, but this isn't exact. For example, the system above collectively has 48G of GPU memory, but only 32GB of RAM and works fine for WPA2. But this memory rule of thumb is good for general system-build advice.
As should be clear by now, if you only have 24 hours, and your passphrase was randomly generated, you won't get very far. But the above should help you perform the calculations.


Prevent bypassing of SSL Pinning in android application

No there isn't. Your app is a guest on the system, the user is the owner of the device is the master. They get to decide what your app can or cannot do, and there isn't much you can do about it.


The CP describes what the requirements are. The CPS describes how those requirements are met.

For instance, the CP can require that the root CA must be configured so that it requires the presence of two persons from separate departments in order to bring it online. The CPS must then describe how this is achieved - by keeping it in a secure facility that requires two separate keys, or by requiring two separate passphrases to be entered, or by requiring two separate smartcards. If you need to change how the CA is operated, e.g. when you need to move to a new facility with different access rules, or when you change to a new operating system, you might need to rewrite the CPS but you shouldn't need to alter the CP.

Also, while both documents may be written by the same organization, i.e. the entity that runs the CA, I strongly recommend that they be written by separate parts of the organization. For a trustworthy PKI system, separation of duties is essential - and not only in operations, but also in oversight. The people who run the CA should be overseen by another department, whose job it is to set the standards and to verify that the operations follow those standards. If the same persons do both, they are effectively overseeing themselves - in other words, they have no oversight at all. As a consultant, I have sometimes been asked to write both documents, and I always recommend strongly against it. I would rather have my client bring in a competitor to do one of them, or at the very least, to verify my work, rather than risking that I be the one to write the conditions as well as fulfill them.


Is there anyway to prevent from being defeated by a SS7 attack in android?

The PSTN is based on trust. If a third-party sends a call to your mobile provider pretending to be another number they don't own, your mobile provider will still happily trust it and forward the call to your mobile as if the call was from the legitimate owner of that number - your mobile has no way to tell whether something fishy is going on, and the mobile provider doesn't necessarily care about that either, though if they wanted they could mitigate at least some issues (like enforcing a whitelist - if the number isn't known to belong to the originating provider, refuse the call).

The only real mitigation is to not trust the mobile network and only use IP-based solutions which employ encryption - if you want to place calls do it either via something like FaceTime, WhatsApp, Facebook, etc - so the mobile network even if compromised wouldn't see much besides encrypted packets. Of course, this breaks down when you actually need to reach the PSTN - you could use a SIP provider (so at least you're protected against your mobile provider being malicious) but this shifts the issue down to the SIP provider where it could just as well be deceived into accepting a call from an impostor.


Should I use the certificate serial number or the subject key identifier to look up public key?

If you only accept certificates issued by you, and you validate that fact, then using the SKID has no security benefit over the serial number. If you use the serial number, and accept self-signed certificates (or any other certificates from CAs who aren't you), an attacker who knows the public key can impersonate users.

Otherwise, there is no difference security-wise. Of course, you'll have to make sure the SKIDs you issue are really unique, and the attacker can't e.g. abuse the fact that your backup signing infrastructure can't doesn't care for duplicates.

As your answer indicates that all certificates are signed by you, you I'd suggest to use SKIDs. You can make your signing infrastructure spare some bits out of your desired int width (e.g. 64 bits), and use those spared bits to store the signer certificate, either on the "storage side", or already with the signers, then you can ensure uniqueness, too.


Can you fake the Host attribute of a C# URI?

There's no intentional or known way, and probably (hopefully) no way at all. If there were, it would be a very serious bug in the .NET framework.

However, note that this only guarantees that the host is actually example.com; it doesn't guarantee that traffic for this URI destined for example.com will actually make it there without interception.


Are there any risks from cloning a LUKS encrypted partition?

Per the cryptsetup wiki,

Note: this section pertains to backups specifically, but I feel like it applies to your situation.

  6.7 Does a backup compromise security?

  Depends on how you do it...There are risks introduced by backups.
  For example if you change/disable a key-slot in LUKS, a binary backup of the partition
  will still have the old key-slot. To deal with this, you have to be
  able to change the key-slot on the backup as well, securely erase the
  backup or do a filesystem-level backup instead of a binary one.

To clarify, one should ensure that the old key-slot is removed in the cloned partition.

  In both cases, there is an additional (usually small) risk with
  binary backups: An attacker can see how many sectors and which ones
  have been changed since the backup.  To prevent this, use a
  filesystem level backup method that encrypts the whole backup in one
  go, e.g.  as described above with tar and GnuPG.

To reiterate, one could simply back up the partition by creating an archive and encrypting it, and then moving it to a newly encrypted partition on the new machine and extracting it.

  I've considered also changing the UUID of the LUKS device. Although I'm not sure if that's adding anything, it will at least differentiate the partitions on different systems.

I would recommend this.

  6.15 Can I clone a LUKS container?

  You can, but IT BREAKS SECURITY, because the cloned container has the
  same header and hence the same master key.  You cannot change the
  master key on a LUKS container, even if you change the passphrase(s),
  the master key stays the same.  That means whoever has access to one
  of the clones can decrypt them all, completely bypassing the
  passphrases.

  The right way to do this is to first luksFormat the target container,
  then to clone the contents of the source container, with both
  containers mapped, i.e.  decrypted.  You can clone the decrypted
  contents of a LUKS container in binary mode, although you may run
  into secondary issues with GUIDs in filesystems, partition tables,
  RAID-components and the like.  These are just the normal problems
  binary cloning causes.

  Note that if you need to ship (e.g.) cloned LUKS containers with a
  default passphrase, that is fine as long as each container was
  individually created (and hence has its own master key).  In this
  case, changing the default passphrase will make it secure again.


Does the ANeko app demonstrate vulnerabilities in the Android architecture?

The sort of malware you're referring to is commonly known as overlay malware. Some more specific overlay-related attacks are dubbed "Cloak and Dagger"[1], [2] and "Toast"[3], [4].

Here's a short video (1:02) demonstrating how those work in general (mostly just in the way you've mentioned).

Of course, since in a nutshell the malicious frame is just a window floating on top of other windows, there are a lot of seemingly legitimate applications of that: video calls, navigation, notifications and so on. In fact, your poor old desktop OS is (and has always been) also vulnerable to such an attack once you've installed a malicious application.

One step by Google here has been to remove apps requesting unreasonable overlay permissions from Google Play. Also, since Android 8.0, an explicit permission should be granted by user for an application to be allowed to lay on top of other windows, effectively eliminating most of the attack scenarios.

A patch mitigating the latest reincarnation of the attack, the "Toast", has also been backported to some older versions and is featured in the Android security patchset 2017-09-01 for Android versions 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1 and 7.1.2. Whether or not it makes you feel safer is entirely up to you. However, please note that all the Android versions listed above with patch level lower than 2017-09-01 as well as older versions may be still affected at least to some of the attacks.


Note that this is no longer the suggested way to create strong passwords. It tends to be counter productive, and in fact your particular example has good odds of being cracked quickly if someone were to attempt to bruteforce it. Here is a breakdown:

XKCD #936: Short complex password, or long dictionary passphrase?

Password length is more important than password complexity, and the language doesn't particularly matter. Regardless of language the total amount of "randomness" is what protects a password from bruteforce. Whether you are using English letters or Asian characters, the more the better.


What prevents web shop owners from misusing credit card data?

The liability for a disputed transaction falls upon the merchant for Card-Not-Present transactions.  Essentially, if you dispute a transaction, if the merchant doesn't have your signature, then if you persist they will end up footing the bill.  By the same token, when a CNP merchant double bills you, they're going to end up paying when you dispute the bill.

As @DavidFoerster points out, the processors and card companies track chargeback rates.  They eye the statistics and, when a merchants is having too many chargebacks, they get cut off.  (Usually they get booted from their processor, and go find another processor who'll charge them more for the higher risk).

The same is true with stores that re-abuse cards elsewhere.  The card brands look at fraud reports and determine that these 20 fraud report cards all had Bob's Web Shack in common as a past transaction.  They will then investigate Bob's Web Shack - both because it might be a bad shop owner, and because it might be a shop that's compromised.  And - again - if a shop is a source of problems, they'll get cut off.

That's what prevents web shop owners from abusing the cards.  They'll lose any disputes, and then they'll get dropped and be unable to process cards.


How to block traffic coming from an "public" WiFi hotspot and going to the LAN (iptables)

After some debugging I found my problem It wasn't the firewall rules but the fact that the DHCP server for my LAN wasn't working (and thus creating an very strange scenario).

These are the rules I used (i flushed all previous iptables rules from the tutorial):

sudo iptables -P FORWARD DROP
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i wlan0 -o eth0 -d 192.168.2.0/24 -j DROP
sudo iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o wlan0 -d 192.168.2.0/24 -j DROP
sudo iptables -A FORWARD -i eth0 -o wlan0 -j ACCEPT

And this results in:

Chain FORWARD (policy DROP 0 packets, 0 bytes)  pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  wlan0  eth0    anywhere             192.168.2.0/24   192 11645 ACCEPT     all  --  wlan0  eth0    anywhere             anywhere
    0     0 DROP       all  --  eth0   wlan0   anywhere             192.168.2.0/24
    9  6286 ACCEPT     all  --  eth0   wlan0   anywhere             anywhere

What happens here, is that i refuse any traffic from my LAN (192.168.2.x) from going to the WLAN and vice versa. If the packets comply to this rule, I use NAT to transfer them to the gateway of the LAN and onto the internet.


What is the risk of data being recovered from SAN storage after logical deletion?

Each layer of indirection makes this more difficult to answer.

NetApp SANs for example have the explicit policy to always do Copy-On-Write. This means that data is NEVER updated in place. Nothing is ever overwritten directly. Instead a new RAID stripe is written, this new stripe's data is mapped to the old stripe's address and the old stripe's data is marked as available for overwriting. This is completely unknown to the VM running on top of it. If I recall correctly the stripes were something like 4k. So if your private key was inside that stripe and you thought the Linux "shred" command actually overwrote it on disk, then no, this is not what happened down on the hardware level.

And there is no real telling exactly when that old stripe data once marked as reusable will actually really be reused. So depending on free space percentage on the SAN and throughput you may give some probability for overwrite. But only probabilities.

And every layer makes this harder to predict:

What about tiered storage?
What about the file system on the Linux VM itself? Will it actually release that space for overwrite? Will it forward the SATA "trim" command to the storage layer at all?

So in closing: so good way to tell. If you worry about remnants of deleted data consider full-disk-encryption.


How dangerous might be publishing a public key?

None, that's why it is called a public key.  It can not be used to access anything encrypted for you without solving math problems that are currently prohibitively difficult to solve.  It is possible that in the future it may be possible to solve these problems and that would cause the public key to allow messages to be decoded, but there is no current known threat.

The flip side is that if you do not share your public key, then your private key doesn't do you any good.  The only reason to use asymmetric cryptography over symmetric is if you need to let someone have your public key.  Otherwise, if you are just doing stuff for yourself, symmetric is far faster and more secure.


What are currently used types of certificates and what they can be used for?

The simplest may be to quote RFC 5280, section 4.2.1.3: Key Usage:

  The key usage extension defines the purpose (e.g., encipherment,
  signature, certificate signing) of the key contained in the
  certificate.  The usage restriction might be employed when a key that
  could be used for more than one operation is to be restricted.

There is also the Extended Key Usage section.

You will find lists of key usages in both sections. The key usage dictates what a given key can be used for. There are some fields needed based on the type of usage, but those could be set (or not) regardless.

As for why we don't just have one certificate to rule them all, you could craft a certificate allowing all uses, but that seems unwise. The general rule in privileges is to grant exactly what is needed and no more.

For example, most web servers need only Key Encipherment, Signing, and Server authentication and would not need Client authentication if they do not make use of it.


How can a router or my ISP protect against phishing?

In general, phishing attacks comes on emails, and the majority of ISPs gives you email services for you in their platforms not on the home routers (in general). So the email services are hosted and process by your ISP, that is normally how ISPs protects you from that types of attacks.

For phishing attacks normally they have antispam/antiabuse systems that allows them to filter domains, ips, suspect emails and so on


How secure is connecting to a machine behind a router with SSH tunnels using a 3rd machine that has static IP address?

That proposal opens a reverse-tunneled port from the NAT'd system (the final destination SSH server on your LAN) to the world. It's clunky; if you want that sort of thing, just set up port forwarding from your router.

The "proper" SSH solution would be to accept SSH connections on your public-facing system (router) and use it as a jump host into your network. Then you're as secure as your router's SSH plus your NAT'd system's SSH (the port-forward and reverse-tunnel solutions have zero security for the router and rely solely on the security of your NAT'd system).

After you've set up ssh open to the world on your router (which, by the way, should not allow root to log into, or at least not without a key), you can connect like this:

ssh -J username@my-router me@lan-system

This will connect as username to the router, then immediately forward a connection to the lan system as user me. (Specifying a user is optional, it'll default to your local user name.) This is all performed from your local client's perspective, so if you're using SSH keys (which you requested—and you should), the private keys all live on your local system, not the jump box (the router).

This SSH jump host guide has some good examples, including how to use your ~/.ssh/config to make it automatic (so you'd type ssh lan-system instead).

To set up key-based authentication

On your local client my-laptop, create a key (make an RSA key if ed25519 is unsupported, see that link):

me@my-laptop:/home/me$ ssh-keygen -t ed25519 -a 100

Make sure it has a password on it. We'll get to saving the password with ssh-agent later. This will create ~/.ssh/id_ed25519 (your private key) and ~/.ssh/id_ed25519.pub  (your public key) by default, which is fine. You can also use -C "comment about your key" if you want something other than the default username@host.

Now you can copy the public key to the jump box (my-router):

me@my-laptop:/home/me$ ssh username@my-router "mkdir -p .ssh; chmod 700 .ssh; cat >>.ssh/authorized_keys" <~/.ssh/id_ed25519.pub

This should be the last time you'll be prompted for your router user's password.

This runs three commands on the router. First, it ensures you have a ~/.ssh directory. Then, it ensures its permissions are correct (700 is drwx------). Finally, it appends the input to your list of authorized keys. After that, we're piping the public key via standard input (think of this like passing a ball; you hand the ball to ssh and it instructs the remote system to hold onto it in that prescribed location).

You should now be able to log in with the key, but let's set up your SSH agent first.

There's a good chance you're already running an SSH agent, so let's just try it:

me@my-laptop:/home/me$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /home/me/.ssh/id_ed25519: [your typing will be invisible]
Identity added: /home/me/.ssh/id_ed25519
me@my-laptop:/home/me$

If that worked, you're good to go. If not, you'll need to launch an agent:

me@my-laptop:/home/me$ ssh-add ~/.ssh/id_ed25519
Could not open a connection to your authentication agent.
me@my-laptop:/home/me$ eval `ssh-agent -s`
Agent pid 1234567
me@my-laptop:/home/me$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /home/me/.ssh/id_ed25519: [your typing will be invisible]
Identity added: /home/me/.ssh/id_ed25519
me@my-laptop:/home/me$

You should look into how to do this for your whole desktop environment rather than per-shell, but you could just add eval `ssh-agent -s` to your ~/.bashrc if you're willing to deal with having to run ssh-add in each terminal you open rather than having it managed centrally.

You should now be able to run ssh username@my-router and log in automatically with your agent's unlocked key.

Let's connect to the NAT'd system lan-system now. This should look familiar:

me@my-laptop:/home/me$ ssh -J username@my-router me@lan-system "mkdir -p .ssh; chmod 700 .ssh; cat >>.ssh/authorized_keys" <~/.ssh/id_ed25519.pub

This will automatically jump through my-router and request your me password for lan-system, then it will install your key. After that, you can run ssh -J username@my-router me@lan-system and log in seamlessly with your agent.

Finally, you can shorten this command line by putting this stanza into your ~/.ssh/config file:

Host lan-system
  ProxyJump username@my-router
  UserName me

This will let you run ssh lan-system on its own. The UserName line is unnecessary if you have the same username. The same goes for the username@ part of the ProxyJump line.


Yes, this makes sense.

With key pairs, the private key is important to keep secure, and in your scenario you're generating it on the client and keeping it only on the client.

The public key can be copied to as many places as you'd like to log in to, without threatening the security of your logins.  This matches what you're doing, copying it to the servers you need to access.


Is using 100,000 iterations of sha256 good enough for password storage?

To answer the title: no.

Your question's premise is incorrect in the first place. Repeated iterations of SHA256 is not a suitable algorithm for password storage.

You should use Argon2 if your language has an available binding. If you're using PHP you can use the inbuilt password_hash function with the PASSWORD_ARGON2I flag. For .NET applications there's a fully managed implementation available. There's a binding available for Java too. There's a fantastic article from Paragon about storing passwords safely, which has example code for a bunch of languages.

If you absolutely cannot use Argon2, although I see no reason why you couldn't (there are bindings for almost every language now!), then you should use scrypt, bcrypt, or PBKDF2-SHA256, in that order of preference. Again almost every language has bindings or libraries for these.


Considering the attacker's doing full tcp-ip handshakes, installing a HIDS like OSSEC or fail2ban should work quite nicely to automatically drop this traffic.


Are there any security concerns if certificates work with multi-level subdomains?

A certificate should be issued for the entity which manages the specific domain. There are environments where different sub-domains are managed by different entities. This is for example often the case within universities where different departments have their own sub-domain and have their own systems within this sub-domain. These systems are usually managed by the department itself and not centrally by the university.

If *.example.com would match every sub-domain and subsub-domain it would not be possible to limit the wildcard certificate to only match the hosts managed by the specific entity.

Apart from that domains were used differently at the time when these standards were made. The domain name system was actually designed to be used more hierarchical then it is used today. The idea was to use the domain name as the main entry point for an organisation, have sub-domains for organisational parts of the organisations like departments and have hostnames within the sub-domains and main domain to identify systems. Using just the main domain name as in example.com instead of www.example.com is a "relatively" new thing and  also multi-level sub-domains without having any organisational structure behind it. In this "old" world a design of having the wildcard matching only a single part made more sense than it seems to make today where it is often more important that a domain name looks fancy than that it reflects an actual organisational structure.


This Google help site tells you how to check for an authenticated message.

To quote:

  The message is authenticated if you see:

  "Mailed by" header with the domain name, like google.com.
  "Signed by" header with the sending domain.

  The message isn't authenticated if you see a question mark next to the sender's name. If you see this, be careful about replying or downloading any attachments.

  When an email isn't authenticated, that means Gmail doesn't know if the message is coming from the person who appears to be sending it.

What this translates to, is the following: if the message is authenticated, the sender that is displayed is really the person or system that sent the message.

That does not mean though, that every authenticated message that you receive from a person or system is a legitimate non-phishing message. The likelihood is however very much increased.

Because there are very little details in your question, here are two other questions that might help you:

for identifying phishing mails in general refer to this one
and also have a look at this one, because it could be a duplicate to yours.


Does SSH authorized_keys violate the principle of "re-authenticate before password change"?

Yes, you're correct, SSH authorized_keys allow authentication changes without verification if an opponent is granted (or steals) shell access once (or has sufficient file access).

I'm going to go out on a limb here and suggest that SSH authorized_keys was designed as an improvement upon the .rhosts paradigm.  A way to allow seamless access between hosts but with more than bare trust.  So from that perspective, authorized_keys are indeed a great improvement in security.  That's not to excuse the issue you're describing, but to put it in context.

The only approach that will really address this issue is to centralize key authentication.  Instead of using disparate key files, require users to submit keys into a system repository, just as they submit their passwords into the /etc/shadow repository via intermediary programs.  That'll mean code, and file ownership and protection issues, and the replacement of a simple file edit control with a more structured and probably difficult database manipulation interface (one that requires authentication to permit manipulation!).

Doable?  Certainly.  Easy?  No, it'll be a bit of work.  Likely?  Probably not; this area of weakness has been known and accepted for a long time, without new impetus I don't see anyone pushing hard to fix it.


What to do if you still have SMBv1 running on your network?

The real fix

First of all, I would strongly recommend to only focus on convincing the decision makers that it is very irresponsible to continue the use of Windows Server 2003 in production environments. The easiest way to do so is to point out their responsibility and liability and the potential risks. Clear that out and ask them if they really want to accept those risks, probably not! They likely just don't understand the risks.

Additionally, convince them with plenty of different reasons, most importantly:

  Microsoft ended support for the Windows Server 2003 operating system on July 14, 2015. After that date, this product will no longer receive: Security patches that help protect PCs from harmful viruses, spyware, and other malicious software.

Also, if I'm not mistaken Ransomware like WannaCry and Petya exploited SMBv1. It got plenty of media attention to underline your statement.

Upgrading or migrating should get serious priority and (time) budget in order to fix the underlying issue here.

The best of the worst

Or, "the unrealistic and terrible workaround". If you are sure you tried everything in your power to convince them why it's a terrible idea to continue the use of Windows Server 2003. This goes against all my principles and hurts me to say but... make the best of the worst. I think you might be technically able to install and enable SMBv2 or even SMBv3 after which you can disable SMBv1 (probably server-side as well as client-side).

But, this is a path you really don't want to go. As far as I know, their is no official support for SMBv2 and v3 in Windows Server 2003 since it's end-of-life. But if you do manage somehow (first of all respect for your technical skills) secondly, now you have a new SMB version in place and can disable SMBv1 as well as block possibly SMBv1 traffic in the firewall. You probably need some kind of advanced firewall since I think SMB is using the same network ports for v1, v2 and v3. So basic firewall ruling is probably not gonna get you anywhere.

But again, you probably have more or other issues to worry about than disabling SMBv1 when you run Windows Server 2003.

Lastly, if the server was only used as a fileserver, you could maybe look into SMB alternatives like NFS. But that's not ideal for Windows servers (and clients).


Secure compiled .NET source code applications ASP.NET and Windows Forms

It sounds like you're looking for an obfuscation tool, such as discussed over at StackOverflow in ".NET obfuscation tools/strategy".  The idea behind such tools is that they make it harder to decompile/understand the program.

Other tricks include compiling the .NET executable to native code and using aggressive optimization as these can help strip the original intent from the code, making it less comprehensible and harder to repurpose the code from the executable.

As Xander pointed out in the comments, you may need to take further action than just obfuscating and lossfully compiling the code as these technical approaches are unlikely to be perfect solutions.


When you spoof ones IP the answer will not reach you at least not for a long time. As a side effect you can cause what is called Port Stealing. This is happening when one IP is seen on two different ports of a switch. The IP is then assigned to the port the IP was last seen on which might be the port you spoofed the address from. But when the original host sends another package (which will happen frequently at least by ARP, IGMP,...) the IP is assigned back to the original port on that switch.

There is I think only one realistic scenario wich will put you in a position to sucessfully fake the IP-Address and also interact with the server.

Perform a MitM Attack between that hosts
Connect to that server with faked source address
Take the sequence numbers from the packets you receive for that original host
Drop the packets though they never reach the original host (apply this only to port 22)
Send answers with sequence numbers taken from source packet

The easiest way to do this might be through iptable rules. But "easy" should be seen in the context of this complex problem. I stronly encourage you to try this in a lab first!


Why a self-signed digital certificate (X.509) cannot be altered?

Yes, you can make a self-signed certificate with any subject name you want.  It's easily doable with free tools.  Getting a signing certificate with a fake subject name signed by a truthworthy issuer is another story - they take verification of identity fairly seriously.

Another thing that isn't easy (in fact assumed to be impossible) is to figure out the private key of the legitimate CA.  So if you are faking a CA, you'll most likely end up making up a new public/private key pair and signing that.  Any entity that explicity trusts a specific public key will NOT trust your fake CA (true for the MS certificate store).

What you cannot do - easily - is modify the Trusted Certificate store on a computer that you don't already have access to.  This isn't an operation that is available from most web browsers - it takes at least user-level access, although some operating systems can be restricted further to administrator level access.  In essence, to extend the realm of trust, you yourself must be trusted.

Which begs the question - if you've gotten access at this level to a machine - why bother signing the malware?  Just install it and save yourself the headache of doing code signatures.

There, are, however two really interesting attacks in this area:

Social Engineering - in many cases, when a user is browsing, the browser will prompt the user when an unknown CA is encountered - the user is asked to explicitly trust the signer, and if the user has the capability, the option is there to install the CA certificate as a trusted CA.  So... there's all sorts of ways of setting up a site to helpfully advice the user to trust you.
If it's not validated properly, you have a problem - the big famous one was FLAME, which used a fake Microsoft signing certificate - it wasn't validated properly and many servers did, in fact, upload malware.

Not the easiest attack - you really have to know a product and how it's doing certificate validation to get something like this through - but bad design/implementation can lead to flaws, so it's mostly about how  much time the attacker can spend to find the hole.


You can't distribute a windows VM legally.  But a windows XP SP1 machine or a windows NT4 machine would be ideal. NT4 is no longer supported by Microsoft and there for contains numerous unpatched vulnerabilities.   Even a windows 7 machine without patches could be exploited though an IE exploit.


Arbitrary code execution, allows an attacker to run any code target system. Based on the Attack Vector we can divide the arbitrary code execution into two categories: remote and local.
In general, I would say that remote code execution is more severe as the name suggest can be exploited over the network, which is much more dangerous in those days when everything is interconnected. Of course, there are also other factors like what type of privileges are required, user interaction, attack complexity, etc.
You can play with NIST CVSS calculator and see how the individual metrics project into the score. The score can be roughly translated into the severity of the vulnerability.


Cutting and sniffing fiberoptic cables - time before detection?

Depends on the protocol, but probably faster than you can blink your eyes. Especially in data transmission within a matter of milliseconds a different fiber will be selected.

Tapping fiber optic can be done by carefully bending the fiber just a bit sharper than it is supposed to, but won't work on monomode fibers which are commonly used over longer distances than a few 100 meters, because the loss of optic power. The real trick here is to dismantle the cladding without damaging the fiber.


SQL injection Are there any instances where a vulnerable url would not contain an 'equals' (=) symbol

SQL injections can be performed in any part of the request. Any parameter of the HTTP request can hold SQL data that can trick the application into injecting it into the database.

For example, Amazon has the product IDs in the URL http://www.amazon.com/gp/product/B008GFRB9E This is called an URL rewrite and the webserver extracts the product id from the URL and uses it to query the database for it.

Without having the source code available, there is no way to know what SQL queries are being performed. One web application can perform a reverse DNS on the connecting IP address and insert that name in the database. But the IP can resolve to a string that performs an SQL injection.

Here are some of the ways to get variables from the URL into the web application:

Wikipedia uses the colon (:). ex: http://en.wikipedia.org/wiki/File:Bald_Eagle_Portrait.jpg
JavaScript applications can use fragments (#) as input. ex: https://www.youtube.com/watch?v=9CTkdih2kU8#t=15s
Tilde (~) was popular once. ex: http://www.cigital.com/~gem/
You can encounter protocol handler links like data: or javascript: that can indirectly pass data the web app. ex: javascript:addtocart(5)

When parsing your links remember that characters can be URL encoded.


Is it urgent to revoke the access to a private repo once a person has been mistakenly granted it and become aware of this?

There's a number of reasons:

If it has happened to one person, it might have happened to more. These other people might not be as kind.
Who knows, this person might change their mind. When they made the effort to contact you, and just gets a "meh" in return, they might be a bit annoyed and decide to punish you for it.
Or maybe they just want to poke around a bit for fun, and accidentally break something.
You probably want to check the logs to see that this person is telling the truth. Maybe they silently stole your encryption keys before contacting you. You probably want to rotate all your secrets just to be sure.
And most importantly, this is a Big F*cking Deal™. Anyone who is not reacting with shock and horror, but instead orders another piña colada, clearly doesn't understand the gravity of the situation.

There's some very good points in comments and this answer that all might be fine under certain circumstances (e.g. read only access, no secrets in the code, etc.). That is correct, but I would still argue that this should be taken more seriously. Are you really 100% sure there are no secrets in some old commit in your repo? The very fact that someone who shouldn't have access to your systems got it anyway is in itself a bad omen.


Why would security cover things like natural disasters?

All other answers are fine. I'm going to offer you a classic security perspective.

Starting a fire/flood is a textbook scenario for physical penetration/exfiltration. People under stress are less likely to challenge strangers.
A fire can be used to destroy forensic evidence, in particular when there's insider involvement.
An earthquake or, indeed, any natural disaster (like bush fires) is a potential complication for security because law and order break down and looting rears its ugly head.
Perimeter security against SVBIEDs is a necessary consideration in certain countries and threat environments. If a suicide car bomber can drive close to the walls of your data center, it is your failure as a security consultant. Hence bollards, flowerbeds, and concrete barriers.
Security is a holistic discipline. Every specialist cares about bits and pieces of the enterprise, and by necessity of life loses sight of the whole. There should be at least one person out there who thinks in terms of adversary's behavior and not his/her own pigeonhole. Which, incidentally, is a security consultant's job description.


security in banking app with 4 digit pin code and social security number

From what you describe, the process may be the following:

During device registration, the application on the device (be it a phone or a laptop) generates some secret value and sends it to the bank; it also stores it. This "secret" may be a secret key, or a private/public key pair: it does not matter much here. The point is that the device can now be recognized by the bank as the device.
The "registration code" is a one-time password that you use to assert to the bank: "this is my device, remember it".
When you log in, the device connects to the bank and uses its stored secret value to authenticate with the bank.
The PIN code is sent to the bank for verification. The device does not store the PIN code or anything which would allow it to verify that code. The bank enforces an auto-lock policy, like smart cards do (after 3 wrong PIN codes, the bank refuses to talk any further).
We assume that the application code is safe (unmodified by attackers); communications use SSL so that the application code is always guaranteed to talk to the genuine bank server, and data can be exchanged securely.

This indeed embodies two-factor authentication: to successfully log in, you must use the registered device ("something you have") and enter the correct PIN code ("something you know"). If an attacker steals your phone, he can initiate the connection (the bank recognizes your phone) but he will be blocked when it comes to the PIN. Conversely, if an attacker learns your PIN code but cannot grab your phone, he will not be able to submit the PIN code to the bank for verification (the bank will accept to consider a PIN code only if it comes from a duly authenticated device).

The use of the social security number is mostly for the show: it makes the process look "more secure". But it improves things only insofar as that number is not known to the attacker. As you notice, social security numbers are not really secret. They may slow down a casual, not-very-competent attacker (e.g. the guy who stole your phone and ran for it, and is trying to see whether he may "get lucky" and plunder your bank accounts as well).

Now the tricky part: how come such a scheme with a phone (or tablet) would be "more secure" than the equivalent mechanism with a computer ? And the answer is: conceptually, it is not more secure. However, there is a widespread notion that malware such as keyloggers are less prevalent in the smartphone world than on general-purpose computers. In that sense, the bank considers that your laptop is less trustworthy than your phone. This relates to the last property I listed above: the protocol works only as long as the application code is indeed unaltered and runs on hardware which is not under hostile control.


The two phases part here is a bit of a separate matter to the rest. Those phases are just two parts of the handshake, and they're just logical separations between the initial identity validation, authenticated key exchange, and parameter agreement (e.g. modes, features, etc.), which make up phase 1, and the derivation and setup of the secure channel used for bulk data transfer, which is done in phase 2.
This is very similar to how TLS in HTTPS works - the handshake initially exchanges information about the identities of the parties and what protocol version and features they supports, agrees on what features should be used, and (usually) does an initial key exchange which is authenticated by the long-term key from the certificate (as in IKE phase 1). It then uses that exchanged key to derive the necessary parameters for the secure channel that the bulk data is transferred over, and initiates that channel (as in IKE phase 2).
The duplication of security associations is because of certain usage requirements, partly due to historical hardware and telecommunications limitations.
The most commonly given example is in a distributed cellular network, whereby one client device might be talking to multiple cell towers. Each cell tower has plenty of processing power, is powered from the grid, and has a (relatively) high bandwidth network connection to the other towers. Compare that with your average late-90s cellular device, which has little processing power, runs on a small battery, has very limited bandwidth to the cell towers, and might be moving between towers quite a lot. Instead of making the phone perform a complete new two-way IKE handshake with every tower it comes across, there are instead two unidirectional channels - one for the client to talk to the tower, and another for the tower to talk back to the client - each with their own security parameters. The idea here is that the cellular device can broadcast data on one security association which is shared between all towers, allowing any tower to decrypt it, whereas data coming back from each tower to the cellular device has its own separate channel.
The differences in supported features, lifetimes, and renegotiations are precisely because of this difference in functionality. The outbound channel from the cellular device to the towers needs to be able to work in a broadcast environment, but the inbound channel does not. The security properties of each channel are tuned so that they are most effective for the specific use-case, providing the most security possible given the requirements of the system.


What are the advantages of using JWT over Basic Auth with Https?

First, as Steffen's comment points out, you don't send credentials (certainly not complete ones, suitable for authentication) in JWTs. I mean, you could, but that both completely misses the point of a JWT and is totally useless. In my years of reviewing many, many web apps and services I have never seen this pattern. I'm really curious where you got the notion that this is a thing people do.
JWTs contain three parts. There's metadata (information about the JSON Web Token), like who issued it and when it is / isn't valid. There's claims (information about the token bearer), which in the most basic form is one field containing an email address or similar identifying string (or sometimes number). Finally there's the signature, which can only be created with knowledge of a secret (either a symmetric HMAC key or an asymmetric digital signature private key) that the user doesn't have, and which prevents the user (or anybody else) from forging or modifying the JWT and having the server still accept it.
Note the total lack in there of anything a user could use to prove their identity (a "credential"). No passwords (as there are in HTTP Basic Auth). No ephemeral user access codes, such as a random string from an email or app or SMS. No sign of user possession of a cryptographic key (such as is used in TLS mutual auth; the only cryptographic key used in a JWT is exclusive to the server). Yes, the claims may contain a user identifier such as a username, but so does the question you posted, the "From" field of any email you send or receive, and the sender info of every SMS. You can't use those (alone) to log in to anything. They aren't credentials, just identifiers. Access to the account behind the email address or username, or the phone behind the number, can be used as a credential, but the identifier itself is not.

So, what are the advantages of JWTs over HTTP Basic Auth? In no particular order:

JWTs are generally specific to one service. If I take a JWT that tells StackExchange that I'm cbhacking and try to use it on GitHub, there is no chance GitHub will consider this valid. Passwords (sadly) get reused all over.
JWTs are time-limited, and expire. If you dig through a dump of some poorly-sanitized logs from months ago and find a JWT I used, it will almost certainly (if the implementer had any sense) long since have expired and thus be basically worthless. If you instead find a basic auth string, odds are pretty good that the password it contains is still valid.
JWTs can be issued by one service and verified by another. This is one of the standard things they're used for, in fact. If you log into a site A via "Sign in with Facebook" or some other SSO (Single Sign-On) provider B, the site A that you're logging into will never see your password; that either goes straight to the SSO provider B, or did at some time in the past (and your session with B is still active). Then B can return a JWT saying "The bearer of this is Arjun, user ID 255431" and signed in a way that A can verify but not create (this is the magic of asymmetric cryptography). Now site A knows who you are - so long as you send the JWT to them - without ever seeing any of your credentials.
JWTs can grant scoped permissions. Suppose I have a calendar online, and since it's my calendar, I can see all the details of events, add and remove events, and so on. Now suppose some third-party app for scheduling calls with clients wants to access my calendar. I want it to know what times I'm available, but I don't want it to know what I'm doing during any particular slot. Maybe I'd let it add and remove those client meetings directly, but it shouldn't be able to remove meetings (or dentist appointments, or vacations, or friends' birthdays) that I added for my own use (nor should it even be able to tell what those are). With basic auth, I'd have to set up multiple unique passwords - one for each service (client meetings, friend birthdays, etc.) that I don't want to give full access to - or else share the main password and then any app that wanted to could take total control. With a JWT, each app can request only the permissions that it needs, and when I approve them it gets a JWT with "scope" claims that limit what the token can be used for.
JWTs can be both secure and fast to verify. Password storage, necessary for basic auth, can't. Symmetric signatures (HMACs) on JWTs are super-fast to verify, usually at most taking a few rounds of hashing. Asymmetric signatures are significantly more expensive to verify, but you can still do them very quickly especially if you use efficient algorithms, without compromising security. Verifying passwords, however, needs to be very slow indeed, because they're too easy to brute-force from a leaked database if you use a fast hash or similar. Thus password hashing is deliberately designed to be computationally expensive - tens of thousands of rounds of hashing is one simple way to do it - and is usually tuned to take somewhere between about 50ms and 250ms per user, on security-conscious sites. As computers get faster, you have to make the password hash even more expensive, too, which isn't a significant concern with JWT signatures. This means that, with basic auth, you have to either add a ton of CPU time spent doing extremely expensive password hashing, or you have to run a very high risk that, if your password database is leaked, people will be able to brute-force the hashes. With JWTs that's not nearly as big a concern (with HMAC-signed JWTs, it's basically not a concern at all).
Relatedly, JWTs can be verified without a database lookup at all. Passwords, including ones sent in basic auth, can't. You can cache them, but that takes server-side resources and breaks down when you have a cluster of servers behind a load balancer. Thus, JWTs are much better for scaling to large numbers of users, where DB hits are relatively expensive and need to be minimized.
Basic auth isn't really compatible with multi-factor authentication (sometimes called two-step authentication or similar). MFA is usually implemented with ephemeral values - one-time codes generated in an app or sent via SMS, challenge nonces sent to hardware tokens or push notifications, etc. - and even if there was a practical way to include the resulting token in the basic auth string (there isn't, for browsers), it would become invalid almost immediately. That's awkward if you want a session to last more than a few minutes before the user has to log in again! With a JWT (or any other session token), you can verify the user's credentials (including MFA) once, and then give them a token good for as long as you want (with JWTs in particular, it's often two tokens: the JWT itself which has a short lifetime, and a refresh token that lasts longer but takes a DB lookup to verify).
A bit of a technical curiosity rather than a deliberate feature of JWT design, but: HTTP Basic Auth is automatically sent by the browser for any request to the relevant domain... even if the request comes from a different domain. This means that there's a risk of CSRF (Cross-Site Request Forgery), where if site X thinks you might be signed into site Y, it can make your browser send requests to Y and Y will think you, the user, did it. This could be used for anything from posting messages on a forum to transferring money between accounts, and it would happen without your awareness. JWTs, by comparison, can be put in lots of different places. Cookies are common, and used to be automatically sent even on requests from other domains (just like Basic Auth), but these days there's the SameSite cookie flag that can be used to control this behavior. JWTs are also often sent in other HTTP request headers (often Authorization - the same one used for basic auth - but sometimes custom ones), and in those cases the requesting client must explicitly specify to send the JWT. Which means the requesting client has to know the full contents of the JWT, because your browser won't just automatically attach it to every relevant request.
Logging out a user who uses a JWT is simple, just delete it from their client (this doesn't invalidate the JWT on the server - that's hard to do, and usually you just rely on the JWT having a short lifetime and expiring soon - but it works fine for Alice getting up from the computer before Bob sits down to use it). It turns out that there's no standardized way to make a browser forget basic auth credentials. At least one browser (Internet Explorer) has a special API for this, but generally speaking, if you want to log out a client that uses basic auth, the only option is to tell the browser that their authorization is invalid (which generally makes the browser stop sending it). That's... messy. Obviously for non-browser clients this is not an issue.
Relatedly, logging in with basic auth isn't really under the control of the client application (implemented in HTML/CSS/JS). The web browser chooses what to show (usually a pretty ugly modal credentials prompt). Other forms of authentication / authorization token allow the web application to create their own login pages, which might include features like a "forgot password?" link or SSO login options, while a basic auth site just presents the user with a blank page (the content won't be loaded - or even requested - until the user signs in!) and an ugly pop-up modal box.


The problem with someone being able to execute commands on your machine is that they don't really need a virus at that point. They can use perfectly legitimate tools/commands to obtain and retain ownership of your machine, so anti-virus is rather moot.

The only "right" suggestion for what to do after being victim of an attack is to format the machine and start again. And hope that you were being diligent with your backups.


Does removing my security questions on Yahoo make me more secure?

Disclosure: I work for AgileBits, the makers of 1Password, a password manager.

Security questions are terrible. In fact, pretty much everyone who studies these calls the insecurity questions.

First of all security questions are another way into your account. But let's compare their security properties with passwords.

Security answers are not secret

My mother's maiden name is not a secret. Nor is the street where I lived as a kid, nor are so many of the other things that are routinely asked. Sure, some of them may not actually be public knowledge, but if I have to use my father's middle name, I don't want to then be responsible for keeping that secret in the future.
Security questions are stored unencrypted

Passwords have to match exactly because they are typically hashed, but security questions are looked at by humans, so if I answered "walter" for my father's middle name (see, it is no longer a secret), I would be allowed back in with "Walter". But in terms of passwords almost doesn't count:

$ echo walter | shasum
95ea07881ac3ffe8602879232682052c3e93b6d8  -
$ echo Walter | shasum
f82f03f4a76873ff4ae41d6609b99f258a647b82  -

And so insecurity questions are stored unencrypted. Yahoo! did a nice job with using bcrypt to hash the passwords (making it harder for the people who stole those hashes to make guesses at passwords), but the thieves got the security questions.

This also means that the people who manage the system also know your security questions and answers. It's not just external thieves, but internal ones as well who can learn these.
Insecurity questions are even more likely to be reused than passwords.

The people who got hold of the insecurity questions (and answers) can now uses those answers to attack your account on other sites you use those answers for. If you give your father's middle name as "walter" on one site, you are likely to give the same answer to the same question on another.

This, of course, is true of passwords, which is why you should use a separate password for each site and service. If you used a decent enough password, than Yahoo!'s use of bcrypt will mean that many reasonably strong passwords will remain unguessed. So the bad guys may not know your Yahoo! password, but they do know your security question answers. (But do not use things that you would like to keep secret for security questions. Remember that in the best case only the people who operate the service will see them.
Security questions (answers) are less varied than passwords.

The most common 100 pets names are almost certainly going to be more common than the most common 100 passwords.

Almost all of the problems about security questions listed above are a consequence of what they are designed to do. They are designed to be things that you already remember (instead of a new thing you have to remember like a password. And you remember these things because they are the truth. So true things about you are less likely to be secret and there are many more ways to lie than to tell the truth. So the inherent problem with insecurity questions follow from their design.

I'm quoted in an a recent article at WIRED that covers these and points to other resources as well.


Use (or not use) OAuth for internal service to service communication in SOA

This started out as a comment, but it grew a bit large for that, so I've moved it to an 'answer'.

The step that is missing from the OAuth2.0 specs is the 'backend communication': the part where the authorization server and the various services agree on what is a valid token and what scope is associated with it. These 'implementation details' are is left the discretion of the OAuth Service Provider.

Also, your diagram is could be improved by sticking closer to the OAuth2.0 terminology (I'm not saying you did a bad job, the diagram is helpful, but it could be more clear).

Your 'User' in this case is (presumably) the Resource Owner. The 'Frontend' could (I'm guessing here) be a single-page application, running inside the User Agent.

It is the API Server that is receives the Access Token from the Authorization Server, to access data on behalf of the Resource Owner.

In other words, your diagram is missing the communication between the 'User' and the 'Auth Server'.

For the flow of OAuth, maybe the follwing diagram is helpful:

Figure 1: OAuth flow for (confidential) clients.

To answer your question: OAuth is about delegation of authorization from a Resource Owner to some service to access the Resource Owner's data on their behalf.

So, using OAuth may not be your best option. However, I don't know of any out-of-the box solutions that really solve your problem (delegation of access rights, on behalf of a user). You could take a look at authoriZation Based Access Control (ZBAC) but it may be quite an overkill for what you are attempting to achieve.


How to discover known vulnerabilities (CVEs) in Go executables?

Not really. I mean, in theory you could, but it's absurdly unlikely that anyone will.

Go is a relatively safe language, so vulns in Go code tend to be logic errors, not mechanical ones. This means that vulnerabilities are marked not by patterns in the binary, but attributes of the control flow.

Essentially for detecting a given CVE you'd have to construct the opcode sequence that corresponds to the vulnerable logic, and match the binary against that pattern. This might be simple for a trivial pattern, but trivial patterns are unlikely, and it's a lot of work for essentially no benefit.

After all, vulnerability detection is fundamentally a supply chain problem. If your upstream can't source vulnerability metadata, then your whole trust model is borked. If you are the upstream (you build the binaries) then you need to start embedding metadata in your package details (eg. source code provenance) that can be used to determine CVE relevance.


Question: How to plan email policy for start-ups?

You are violating your own policy by asking this question. You communicate with the outside world over an issue related to your startup.

The fact that you start by violating your own policy indicates that you haven't thought the issue through.

Your policy basically says that if your startup uses some open source library and that library has an issue the developers in your startup aren't allowed to write posts to the mailing list of the open source library and they aren't allowed to report bugs to the bugtracker of the open source library.

If you do an effective ban on communication with the outside world that reduces the efficiency of your programmers. There might be startups where total secrecy is important but in most startups it's probably not worthwhile.

I once did an intership in university. The academic group in which I worked didn't use any source control. The had a blanket policy of no outside data transfer. I did the sensible thing of installing source control for myself and asked whether I can backup the data to an external server. I basically got a: "Well, okay."

The basically allowed me to get around the senseless policy of no outside data transfer. They however didn't explain exactly why they didn't want outside data transfer. As a result I couldn't make sensible decisions about when I communicate which data that were in line with the company policy.

Instead of trying to ban all outside communication you should talk with your developers
about which informations can safely communicated and which information can't. In most startups you shouldn't forbid your employees from communicating all information.


Idea for an algorithm to authenticate users with zero-knowledge-proof [need thoughts/review]

This is how I understand it, please correct me if I've misinterpreted something.

Sending Password in the Clear

A one time risk is never worth it when it can be avoided.  Using a secure algorithm like bcrypt or PBKDF2 with a salt does not require the password to be sent in the clear.  Even if the password is sent under TLS, am I to trust that you're not keeping my password for yourself?

This answer provides a completely secure mechanism for login authentication without sending a password in the clear.

Overhead

There is a lot of overhead that an attacker can see over the wire.

  When a user wants to log in, he first computes said hash on his local
  machine. The server then tells the client to join random letters to a
  new one time password. The server only sends out letter positions and
  sends them out at random, so that there are enough permutations to
  never run out of combinations. There has to be a history of already
  used letters, so that at least one never exposed letter gets used.
  Else a MITM could simulate a client.

What exactly is happening here?  Are you joining random letters to the hash of the password?  You're sending the letters in the clear, so why exactly can't someone be in the middle?  I understand that you've exchanged a secret only once, but that secret is stored on both the client and server.  Two separate attack vectors.  If you're concatenating the letters to the end of the hash, then all I need is the hash and I can login with the server.

If you're creating a whole new password from the letters sent by the server then at what point do you verify that the original password was correct?  Otherwise I can connect to the server myself, and the server happily supplies me with a new password.

  Even if send one-time passwords are "securely" hashed, the attacker
  has time.

I'm not really sure what you're referring to.

  This counter gets send to the client every time he want's to login, so
  he increases hashing rounds by the counter to match server data.

Again you're providing some other characteristic over the wire, if an attacker can see it then it's reproducible.  I don't think this adds anything to security, as any secure hashing algorithm will run through enough iterations on its own.

Unnecessarily Long Password Requirement

There's no reason for a 4000 character password.  For a secure algorithm this will put a performance hit on your server.  I securing hashing algorithm iterates 20,000 times over the entire password.  A 16 character string is the minimum needed for a secure password.  4000 characters is overkill.

Done Before (kind of)

It seems like the random characters provided by the server are acting as a random salt.  However, since they're restricted to letters they're not going to be nearly as effective.

Check out Salted Password Hashing - Doing it Right


HMAC password reset link and replay attacks

The major risk of email password reset systems is the SMTP transport of the reset token.

Any competent email infrastructure will use either HTTPS (HTTP/TLS) webmail, IMAPS (IMAP/TLS), or POP3/TLS, or a proprietary protocol like MAPI/TLS.  If not, get another provider ASAP.

Your visit of the reset token link itself use HTTP GET over TLS and the only thing the attacker can see is TCP connection level info (source/dest port/address).

This leaves the attacker with only SMTP interception on the Internet, at the sender network, or at your mail provider's network.  That's not economical for most attackers unless you are a high-value target like a CFO or other individual with valuable privileged data access.

If the attacker has access to your email via account compromise they can get new reset links.  A two factor token would mitigate that.  If the attacker has compromised your endpoint they can steal your session directly.  A defense for that is for the application to lock sessions to particular hosts.


Are text and html files vulnerable to altering in transit through Tor network?

If the url is http (not https) they could.

There are studies about malicious tor nodes that inject virus in executables.

There are studies about internet routeurs (so it's apply to tor AND not-tor traffic) that inject ads in html webpages.

  Will it be safe if I drag and drop these text and html files on Tor window to open them?

If you open local content with your tor browser, it doesn't transit on the network, so if that local webpage doesn't call external urls, it can't be altered by the network.


Erasing Truecrypt keyfile(s) after volume has been mounted

To improve security to some extent, I use keyfile generation technique (to change an existing file into an actual keyfile).

Are you using an external tool to do that, or something built-in to TrueCrypt? AFAIK you can use any type of file as a TC keyfile, but the file is used as-is, no transformation is done. From the docs:

  Note that TrueCrypt never modifies the keyfile contents. You can select more than one keyfile; the order does not matter. You can also let TrueCrypt generate a file with random content and use it as a keyfile. To do so, select Tools > Keyfile Generator.

Whatever method is used to "turn a regular file into a keyfile", you must make sure it's deterministic (i.e. always generate the same keyfile given the same input), otherwise you can't throw it away after use. And of course, if you generate it from a random source, you must keep it to be able to unlock the volume later.

  If yes, then it could be safely overwritten and destroyed immediately after usage, further enhancing security associated with using truecrypt.

I don't see how that will enhance security. If the original file is sufficient to decrypt a volume, an attacker that has access to it can also do the same, regardless of how many intermediate steps there are to transform it into the resulting keyfile. Same with keyfile+password vs. original file+password. That means you have to protect this file as well as you'd do with the keyfile.

You could argue that using an arbitrary file is safer than using a "standardised" keyfile, since there are so many of them in your computer, and the attacker must know which one is the key. A 64 byte file with random data "stands out in the crowd", so they would in principle be the first ones to be tried. That's a bit like "security though obscurity", but if you have no better way to protect your keyfile, this should give you a little more protection.

However, I must point out that since TrueCrypt accepts many keyfiles at once, and it does its own hashing to combine them together and with the supplied password, you shouldn't need to perform the intermediary step yourself (that just potentially increases the attack surface).

And for a reason to have many keyfiles: if your storage media has N files and K of them will be used as keyfiles, the total number of combinations your attacker must try is N! / (K! * (N-K)!). By carefully choosing this number you can make it much more difficult to brute force it, even if the attacker has access to all your files and a lot of time and resources to try them. (just make sure to scatter the keyfiles through different folders...) It's up to you to decide the tradeoff between security and convenience, since supplying all those keyfiles also has its cost - in user patience, which can be very limited.

Update: as per your comment, you're using 20 files out of 1000, which in principle would take a long time to crack (1.6 * 10^10 years at 1000 tries/second). However, you mentioned that the files are chosen based on user input, so I must point out this fact:

Despite the large number of possibilities to choose those 20 files (5.3 * 10^20 ~ 68 bits of entropy), not all of them are equally likely to be chosen, since the process is not random. In fact, each sequence of user inputs (lets call that a "password") will deterministically lead to a single combination. Thus, the entropy of your scheme will be at most the same as the entropy of your "password" (capped at 68 bits). In other words, an attacker that knows your process needs only to redo the same (against a list of "password" guesses) to get a viable combination of files - a better result than trying all them at random.

Also, you must make sure the logic for choosing those files does not leads to too many collisions. If two or more inputs lead to the same set of files, either of them can be used interchangeably. If that happens, the resulting entropy can be even lower than you'd get by simply using that user input as a password. And, unnecessary to say, using a password with more than 68 bits of entropy will have no effect (i.e. 11 characters or more), since at this point collisions are guaranteed to happen (contrast to the max 512 bits of entropy that you can get by using a random keyfile, or about 420 by using a random password with 64 printable ASCII chars).


You should not ask for more output from scrypt than you need.  The CPU/memory cost of scrypt hashing is not dominated by the output size, but rather by the setup process (in Wikipedia's explanation of the algorithm, the values "N" (CPU/memory cost) and "p" (parallelization parameter)).  The output is generated by a single iteration of PBKDF2, using the values from the setup phase of scrypt as the salt.

For the same reason, generating partial output (say, the last few bytes) is only marginally faster than generating the entire output: it's possible to generate only selected subsets of the output of PBKDF2 at low cost, but you need the entire input to be available to do this.

PBKDF2 generates its output as a series of blocks by concatenating and iteratively hashing the password, seed, and 32-bit block number.  For output of less than 2^32-1 blocks (128 GB for PBKDF2 as used by scrypt), revealing part of the output has no impact on the security of the rest of the output.  After that point, however, the output starts repeating itself.


What party is protected by not turning on CORS?

CORS is only to prevent cross-origin reading inside the browser.

Before CORS was implemented in the browsers simple requests (i.e. form upload, embedding image etc) could do cross-origin requests (and thus also CSRF attacks) could display the response inside the browser but could not access the response from inside JavaScript. And XMLHTTPRequest and similar were restricted to access same-origin only but could read the response within JavaScript when doing a same-origin request (Same-Origin-Policy).

CORS mainly deals with the latter restriction: if the server explicitly allows cross-origin access then cross-origin XHR will be allowed both to send a request and also to read the response from within JavaScript (like only with same-origin before). And the browser can include existing cookies and similar when doing such cross-site request and thus do cross-site reads within a previously authenticated session.

But what does this mean for applications outside the browser: Since these are not expected to be used as an attack vector for cross-site reading in the first place they are irrelevant in the context of CORS. Of course, if such an application actually implements browser-like behavior and actually supports authenticated cross-site requests then it should also implement the relevant protections browsers have, i.e. Same-Origin-Policy and CORS.

Note that CORS is not a replacement for authentication. A server still has to implement proper authentication to restrict what kind of data the users can retrieve. But with CORS a cross-site requests can be made which uses the existing authentication to retrieve protected content cross-site - but only if allowed by the CORS policy.


Windows discovery through unsecure WMI ports

WMI ports should only be enabled on the internal network and denied from outside to inside in your network firewall

Things you can do to improve security:

Set DCOM Security to Allow only specific Users
Set Namespace Security to Require Data Encryption for Remote Connections
Get a WMI Explorer/Tester to actually perform various VMI tests
Don't forget to secure WinRM

Read some tips here.


Is stripping out  characters an effective way of preventing XSS?

It depends on the context the injection happens.

Obviously, if the injection happens in the context of an elements content like this one:

Your search for "❌" has returned the following results:

< is required to switch from text to markup. But even here, if you echo user input in a

You’ll need to look for other characters as you’re not in the plain text context. Here you should take care for characters which are special inside JavaScript string literals as well as certain sequences that can denote the script element’s end tag, e.g. </script>, or </script/.

Similarly, if you print user input in an element’s attribute value:

<input type="text" name="search" value="❌">

Here you have to take care of characters that are special for double quoted attribute values, i.e. the delimiting " quote. If you’re using single quotes or no quotes at all, different rules need to be applied.

Additionally to that, you don’t just have to look for syntax but also for semantics. Like there are javascript: and data: URIs that can be used for XSS. Or there is a JavaScript that uses part of the user supplied data for some evaluation, or retrieval of some additional script code, etc. There are hundreds of examples.

So always take the context into account in which you want to put user supplied data and encode that data correspondingly.


Strategy against browser exploits on Windows?

First thing: change the Yahoo password.  Since the scanners didn't come up with anything, most likely, the exploit grabbed the saved password from somewhere on the computer, and sent that password to its home server.  The emails then aren't being sent from your friend's computer; they are just using your friend's password.


How to securely ask for additional PII / account verification?

This kind of scenario essentially features a trade-off between usuability and security, and which option you decide to go for will depend on the risk appetite of your organisation.

Ideally from a security perspective you should not encourage users to click links in e-mail given the lack of reliability of e-mail and the prevalance of phishing scams which involve getting users to click on links in mails.

So the best option from that perspective would be to send a mail to the customer (or contact them via another channel if they've provided those contact details) and ask them to go to the site themselves in the browser, log in and go from there.

Of course this isn't a great user experience and that's why a lot of companies choose to put links in e-mail for people to click.  So if you do do that, some things to consider

Try to avoid using 3rd party click tracking sites, so at least the user is going to your domain and can verify that assuming they know what to look for of course.
Consider digitally signing your e-mails.  Again I'm sure a lot of users won't notice but it helps for those who are more security aware to have some extra confidence that the mail is legitimate.


>>> test
'0b100100001100101'
>>> type(test)
<type 'str'>
>>> test2
18533
>>> type(test2)
<type 'int'>

bin() returns a string.  Remove the bin() to get an integer, and use that for the chksum input.  The following sent out the packet correctly for me:

from binascii import hexlify
from scapy.all import *

test2 = int(hexlify('He'),16)
send(IP(dst='127.0.0.1')/UDP(dport=53, chksum=test2)/DNS(rd=1, qd=DNSQR(qname="query")),verbose=0)


Strange attempts from Azure IP on our client data

Please contact this guy

If you need his name, register to https://censys.io/ and whois the ip.

This person is the one in charge (for abuse) of the following ASN: MICROSOFT-CORP-MSN-AS-BLOCK AS8068

The ip you stated seems to be pretty well known for misbehaving. Try to figure out if microsoft is not playing by the rules or if its an attack attempt performed by a tier.

And mention the fact that the IP have fallen into a sinkhole. Since recent botnet's CnC server(s) use Domain Generation Algorithm, mentioning CnC server past domain name wont be very relevant.


There are many features in the PDF that can be used in malicious ways without exploiting a vulnerability.  One example is given by Didier Stevens here.  Basically he embeds an executable and has it launch when opening the file.  I am not sure how today's versions of readers handle this but its a good method of using PDF features in malicious ways.


How to manage a custom session in a webapp?

To quote directly:

  Only use inbuilt session management.

  Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies.

What this is saying is that, if you've got a secondary system which doesn't/can't use inbuilt sessions, you shouldn't send that second session token as a cookie or header, but instead should put that token into your inbuilt session. That way, you have one single session token which may point to others if needed.

When they say "the native session management", they mean something like $_SESSION on PHP, or the Session object in ASP.NET, whereby the session data is stored server-side and a token is maintained on the client-side in order to identify the session for that user.

For example, let's say you've got three webapps. You later roll out a single sign-on (SSO) system so that you don't have to separately log into each. According to the OWASP guidelines, it would be a bad idea to implement it such that visiting each separate application gives you separate session tokens. Instead, the SSO should give you a single session token, which should be used for all three applications. If separate identifiers are required for each, these identifiers should be stored in the session data, so that they can be read from there.

The benefits of this are:

Expiring the main session expires others automatically - no latent sessions.
Less attack surface for cookie management issues (e.g. Secure or HttpOnly flags).
Less likelihood of session token leakage.

A quick PHP example of how you might handle this in a webapp:

<?php
session_start();
$sid = isset($_SESSION['app3_session']) ? $_SESSION['app3_session'] : NULL;
if ($sid != NULL)
{
    // verify SID for this particular app
}
?>

The SSO would create the initial session and populate the app3_session value.