iPad accessible when I connect to internet?

If it's your device, then the short answer is no, you'd have to give them permission. They can view network traffic coming to and from your device, which may be what they're talking about.
Most BYOD management tools  - for example, if you're connecting your iPad to a school or business network and installing specific applications - create a separate partition for the purpose.  The administrator typically has control just over this partition - they can remotely wipe, install, etc - but will have no access to your personal data.


Yes, it can be done. It has been used by some companies to allow deduplication of encrypted files. As in order to view the contents you need to know the hash, it is fine in principle (assuming you choose proper ciphers, hash, etc.)

However note that it allows metadata correlation. As the NSA, if these people all share the same file, even if I don't know what it is, I know they have the same contents. Similarly, if an entity suspects it may be infringing their copyright, using a consistent hashing means they could determine that a given file is what is being shared.


Plausibly deniable SSH - does it make sense?

Technically, the first bytes of a SSL connection, and the first byte of a SSH connection, differ. Basically, with SSL, the client talks first, and the very first byte has value 22 (0x16) for the record containing its ClientHello (see the standard). With SSH, client and server talk simultaneously, but the server can wait for the client to talk first, and they send their "banners" which starts with "SSH" (see the standard), so the first byte from the client will be 83 (0x53, for an ASCII "S").

Thus, you could write some server software which listens on port 443, looks at the first byte, and, depending on that byte, redirects to a local SSH or SSL server. The two protocols can be multiplexed on the same port that way (I used to do that for SSL vs RDP). However, of course, there will still be SSH traffic on the socket when you do SSH, so packet inspection things will still see "SSH-like patterns".

The same applies to your idea. Even if you do a complete SSL-based dialog first, the moment you switch to SSH on the same socket, the packet inspectors may detect you. If you really want to evade them, you have to do the SSL thing completely: begin with SSL, then do the SSH inside the SSL tunnel. Basically, run a SSL-based VPN. From the outside, it will just be SSL all along; inside, arbitrary IP packets, which may convey some SSH or anything else, really.

(Note that SSL encryption does not hide packet size, and SSH traffic includes a lot of small packets which imply a traffic pattern distinct from "normal Web". A nosy sysadmin may still find out about your attempt at evading the local policies. Crime is not an easy craft !)


What is the purpose of changing the default SSID?

Changing the Default SSID would serve no particular security purpose where it's not entirely predictable (e.g. 'netgear'). It would allow you to easily identify your wireless network though, if there are lots of others about.

It used to be the case where companies used one string for all their APs that it was relevant to Rainbow table generation (more info here) as the SSID is involved in generating the key (details here)

It could be that the articles you read were confusion the idea of changing the SSID with the idea of changing the Pre-Shared Key.

Changing the PSK can be a good idea, in case there is a problem with the methodology used to generate the first one being predictable (IIRC this has been a problem with some makes of access point in the past).

Also changing the PSK periodically can be beneficial if you're worried about someone brute-forcing the existing one or your worried about someone who has had access to the network and should no longer have it (e.g. in a company set-up where someone leaves the company)


Personal Cloud Storage vs. File Sharing Services

A lot depends on how good you setup and secure you personal cloud storage.
The risk you have when running one on your home-network is that potential malware could more easily spread to your storage. And your storage could cause vulnerabilities to attack your home-network. However, if you secure it well, or even ran it on a separate network these problems can be fixed.

When talking about integrity and confidentiality, home-network will win for sure. You shouldn't be trusting big companies with sensitive/personal data. There are services offering a secure and privacy-respecting cloud-storage, but yet, your own files hosted on your own device is of course better.
If you're able to secure that device against others.

Another thing you could (should) do, is encrypting your files before uploading them to the cloud. Yet, would you give your most precious possession to a company, even when you've putted it in a 'safe'? Ain't it sometimes better to keep the safe at home? Otherwise the company could still be trying to crack your safe without you knowing.

And indeed, when you want to host loads of files your own cloud storage can be more economical depending on electricity costs etc.

Reliability? Depends. Those official services can offer up-time insurances you cannot. On the other hand, when your network is down you could eventually dial home and ask the person there what's wrong and instruct him to fix the problem. Google won't appreciate it when you dial them to give instructions.

tl;dr: I'd go for a home-based personal storage. But rather on a separated network and well secured.


This is a fairly horrible entry in the combined audit log and Microsoft certainly don't make it easy to decipher.

It appears to happen when a users device with an on-prem AD account sync'd to Azure AD tries to authenticate.

From what I can tell, the IP address should be related to the client device - which may itself not be on-prem at the time of authentication.

There are a couple of support articles related. As often the case with MS web support, they are fairly inpenetrable. 1, 2


Secure way to hold private keys in the Android app

All android 7+ devices are equipped with Trusted Execution Environment (TEE) as a mandatory requirement for Google apps licensing. It's a hardware backed keystore which provides isolated storage and data processing for cryptographic blobs. In Qualcomm Snapdragon and Samsung Exynos SoCs, TEE is based on ARM Trustzone. Some devices like in Pixel and iPhone have their own discrete TEE (Google's Titan M and Apple's T2 chip) which is called strongbox. Discrete TEEs are more isolated than ARM Trustzone and independent of the SoC used.
You can use android keystore provider APIs to

generate private keys

generate secret keys

sign and verify data

import encrypted keys

authenticate user for key use

Verify hardware-backed key pairs with Key Attestation

Every key stored within the keystore can have the following parameters set:

alias - used to identify the key.
key size (API 23).
purpose – encrypt/decrypt (API 23).
encryption mode, algorithm and padding (API 23).
should the key be authenticated with the keystore before usage? (API 23).
the time duration for which the key can be used after a successful authentication (API 23).
should a key be invalidated on new fingerprint enrolment? (API 24)
should a keystore require the screen to be unlocked before performing cryptographic operations? (API 28)
should a key be protected by a StrongBox hardware security module? (API 28)

You can also use it to encrypt authentication tokens for login, store passwords and encrypt the key which encrypts your app's large sensitive data.

"should a key be protected by a StrongBox hardware security module? (API 28)" seem to be very important in terms of overal security level.

For android 9+, apps can set preference to store keys in strongbox by calling setIsStrongBoxBacked(true). If it throws StrongBoxUnavailableException then apps should fallback to hardware backed keystore. Strongbox is immune from critical side channel vulnerabilities in SoC's CPU which may affect hardware backed keystore. The security of hardware backed keystore falls on the chipmaker of SoC: Gaping 'hole' in Qualcomm’s Secure World mobile vault leaked sensitive data.
Hardware Security Best Practices recommend StrongBox Keymaster. The module contains the following:

Its own CPU
Secure storage
A true random-number generator.
Additional mechanisms to resist package tampering and unauthorized sideloading of apps.

Android keystore system
How Secure is your Android Keystore Authentication? (Outdated, published before android 10 release)


Should I recreate Git tags after revoking a signing key?

What happens to the changesets and tags already signed?

Nothing will happen to them - they remain signed, but with the revoked key.
Revoked keys stay on keyservers (and on people's disks, if they have a local copy), so the signature can still be verified.

  Should I rewrite them with the new signing key?

That depends on what you want to achieve, but probably yes. The whole point of signing tags is to certify "I (rather: the onwer of the private key) really created this tag."

By revoking your key you are effectively saying: "Don't trust any signatures with this key, they may be forged." So if you want to give users of your repository a way to verify the authenticity of tags, you should re-sign them.

Technical note:

You cannot re-sign a tag in Git, because the signature is an integral part of the (signed) tag. For details see for example Can I sign a git tag after it was created? on stackoverflow.com.

You will have to create a new tag, and sign it with your new key. Also note the general caveats about changing/replacing tags: You will either have to create the tag with a new name, or replace the existing tag. If you do the latter, people who previously fetched the old tags will have to manually delete them, otherwise they will not get the new tags.


It is a classic Ransomware.
You have been infected. How? there can be many answers.
It ould be any of the shady websites you visit ;) or a legit website that has been infected
I have mentioned the link below though I am not sure how effective it is as I have not been infected with this thing yet.
What do you mean by "managing internet usage"?

Here's a Blogpost on how to remove it:

  Step-by-step guides to uninstall Dirty Decrypt.exe Virus

  Manual Removal Guide:

  Step 1: Boot up the infected computer, press F8 at the very beginning,
  choose “Safe Mode with Networking” and press Enter to get in safe mode
  with networking.

  Step 2: Press Ctrl+Alt+Del keys together and stop Dirty Decrypt.exe Virus processes in the Windows Task Manager.

  Step 4: Search for all infected files and registry entries and remove them from your computer as follows:

  %Temp%[RANDOM CHARACTERS].exe
  C:\Documents and Settings\
  C:\Users\< Current User >\AppData\
  HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System “DisableTaskMgr” = 0
  HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\random


Why AES is not used for secure hashing, instead of SHA-x?

A block cipher has a key; the secrecy of the key is what the cipher security builds on. On the other hand, a hash function has no key at all, and there is no "secret data" on which security of the hash function is to be built.

A block cipher is reversible: if you know the key, you can decrypt what was encrypted. Technically, for a given key, a block cipher is a permutation of the space of possible block values. Hash functions are meant to be non-reversible, and they are not permutations in any way.

A block cipher operates on fixed-sized blocks (128-bit blocks for AES), both for input and output. A hash function has a fixed-sized output, but should accept arbitrarily large inputs.

So block ciphers and hash functions are really different animals; rather than trying to differentiate them, it is easier to see what they have in common: namely, that the people who know how to design a block cipher are also reasonably good at designing hash functions, because the analysis mathematical tools are similar (quite a lot of linear algebra and boolean functions, really).

Let's go for more formal definitions:

A block cipher is a family of permutations selected by a key. We consider the space B of n-bit blocks for some fixed value of n; the size of B is then 2n. Keys are values from a space K, usually another space of sequences of m bits (m is not necessarily equal to n). A key k selects a permutation among the 2n! possible permutations of B.

A block cipher is deemed secure as long as it is computationally indistinguishable from a permutation which has been chosen uniformly and randomly among the 2n! possible permutations. To model that, imagine a situation where an attacker is given access to two black box, one implementing the block cipher with a key that the attacker does not know, and the other being a truly random permutation. The goal of the attacker is to tell which is which. He can have each box encrypt or decrypt whatever data he wishes. On possible attack is to try all possible keys (there are 2m such keys) only one is found, which yields the same values than one of the boxes; this has average cost 2m-1 invocations of the cipher. A secure block cipher is one such that this generic attack is the best possible attack.

The AES is defined over 128-bit blocks (n = 128) and 128-, 192- and 256-bit keys.

A hash function is a single, fully defined, computable function which takes as input bit sequences of arbitrary length, and outputs values of a fixed length r (e.g. r = 256 bits for SHA-256). There is no key, no family of function, just a unique function which anybody can compute.

A hash function h is deemed secure if:

It is computationally infeasible to find preimages: given a r-bit value x, it is not feasible to find m such that h(m) = x.
It is computationally infeasible to find second preimages: given m, it is not feasible to find m' distinct from m, such that h(m) = h(m').
It is computationally infeasible to find collisions: it is not feasible to find m and m', distinct from each other, such that h(m) = h(m').

There are generic attacks which can find preimages, second preimages or collisions, with costs, respectively, 2r, 2r, and 2r/2. So actual security can be reached only if r is large enough so that 2r/2 is an overwhelmingly huge cost. In practice, this means that r = 128 (a 128-bit hash function such as MD5) is not enough.

In an informal way, it is good if the hash function "looks like" it has been chosen randomly and uniformly among the possible functions which accept the same inputs. But this is an ill-defined property since we are talking about a unique function (probabilities are always implicitly about averages and repeated experiences; you cannot really have probabilities with one single function). Also, being a random function is not exactly the same as being resistant to collisions and preimages; this is the debate over the Random Oracle Model.

Nevertheless, it is possible to build a hash function out of a block cipher. This is what the Merkle-Damgård construction does. This entails using the input message as the key of the block cipher; so the block cipher is not used at all as it was meant to be. With AES, this proves disappointing:

It results in a hash function with a 128-bit output, which is too small for security against technology available in 2011.
The security of the hash function then relies on the absence of related-key attacks on the block cipher. Related-key attacks do not really have any practical significance on a block cipher when used for encryption; hence, AES was not designed to resist such attacks, and, indeed, AES has a few weaknesses in that respect -- not a worry for encryption, but a big worry if AES is to be used in a Merkle-Damgård construction.
The performance will not be good.

The Whirlpool hash function is a design which builds on a block cipher inspired from the AES -- not the real one. That block cipher has a much improved (and heavier) key schedule, which resists related-key attacks and makes it usable as the core of a hash function. Also, that block cipher works on 512-bit blocks, not 128-bit blocks. Whirlpool is believed secure. Whirlpool is known to be very slow, so nobody uses it.

Some more recent hash function designs have attempted to reuse parts of the AES -- to be precise, to use an internal operation which maps well on the AES-NI instructions which recent Intel and AMD processors feature. See for instance ECHO and SHAvite-3; these two functions both received quite a bit of exposure as part of the SHA-3 competition and are believed "reasonably secure". There are very fast on recent Intel and AMD processors. On other weaker architectures, were hash function performance has some chance to actually matter, these functions are quite slow.

There are other constructions which can make a hash function out of a block cipher, e.g. the one used in Skein; but they also tend to require larger blocks than what the AES is defined over.

Summary: not only are block ciphers and hash functions quite different; but the idea of building a hash function out of the AES turns out to be of questionable validity. It is not easy, and the limited AES block size is the main hindrance.


An article I read suggested that hackers will be able to record key
  strokes from an IE bug, but surely that means modifications to the
  server side code?

The IE bug I believe you are referring to is mentioned here.

  an attacker may create a web page at evil.com, which the attacker
  controls, and include on the evil.com page a visible frame displaying
  the login page for example.com. The attacker can hide the frame's
  borders and expand the frame to cover the entire page, so that it
  looks to the browser user like he or she is actually visiting
  example.com The attacker registers some javascript in the main
  evil.com page which listens for all key events on the page. Normally,
  this listener would be notified of events only from the main evil.com
  page -- but because of the browser bug, this listener is notified also
  of events from the framed example.com page

However, the user would:

Have to be using a vulnerable version of Internet Explorer.
Already be trusting evil.com to enter their credentials for example.com. That is, evil.com could just as well be displaying something which looks like example.com's login page rather than an IFrame.

  I have enabled sandbox mode with sandbox="allow-forms allow-scripts".
  Is this secure enough or should a different approach be taken? .

The main risk if the other website is malicious or compromised, then it can do what it wants within the IFrame only. The sandbox attribute is widely supported, however you may wish to not write the IFrame at all for unsupported browsers. You are not specifying allow-top-navigation so they cannot redirect the user away.

The Same Origin Policy will prevent the framed page from manipulating yours. I guess the main risk you're taking is that the site could attempt a browser exploit or a cross-domain attack on another website (e.g. XSS, CSRF) by you sending the user to a site that they have not chosen to trust.


What makes an Android application vulnerable to SQL Injection?

SQL injection attacks apply when an application uses SQL and carelessly assembles SQL requests with attacker-provided elements. Here, "carelessly" means "without using prepared statements". Prepared statements are the correct way to do SQL with externally provided data; many developers try to think of it in terms of "escaping quoting characters", which is a bad method and leads to disaster (even though some escaping ultimately happens, only prepared statements guarantee that it is done properly).

Android is not a factor in all this, except very indirectly: Android comes with SQLite, hence developers are very tempted to use it and thus fiddle with SQL, even in cases where it is not strictly necessary. When your only tool is a hammer, problems had better be nails, because there's going to be some serious hammering. Of course, when developers are given the power of SQL but are not careful enough to use it properly, then SQL injection attacks become a definite possibility.

Another effect is that Android applications are based on a Java-like language, which is inherently protected against buffer overflows (because all array accesses are systematically checked) and double-free and use-after-free situations (because of the GC-based memory management). Therefore, other kinds of attacks mechanically constitute a bigger proportion of all overall vulnerabilities. Having lots of SQL injection vulnerabilities in Android apps may be, in fact, the result of having comparatively much fewer of other kinds of attacks.


find if 0-day flash bug was exploited (on a particular machine)

Well inadequacy is relative, in that you don’t know what they’re doing, but if you’re willing to do the research then you can find out i guess?

Sandbox the browser using something like Sandboxie, which will then tell you what its trying to access, you could also install Wireshark on a machine and point all traffic going out from that machine to the machine with Wireshark on it, so to see what packets are being sent and received.

Besides that, a console that will allow you to see what calls Flash makes to your local system.

Personally, I don’t use Flash anymore and opt in for HTML5, but then again there are not enough sites using it fully as of yet.


How does Tor protect against fake entry nodes / total redirection?

[Is there] a list of hardcoded entry servers with known public keys

Every server is capable of acting as an entry as every packet is either a packet to be forwarded or an exiting packet. This is achieved by encrypting each packet to a specific node. Each node has a public key listed which is used to negotiate a session key with that node.

The principle behind this is called onion routing. The fine details are expansive, so reading the article is best. The summary is that the packet is encrypted for the last node, then that is encrypted for the 2nd to last node, and so on.

Without controlling every node in the chain, linking the original sender to the raw packet would require traffic analysis.

Since the public key of a Tor node is published, no node in the chain can redirect your traffic in a meaningful way. It must pass to a node that is capable of decrypting it. A symmetric key is derived using a signed Diffie-Hellman exchange, and thus will not be accepted from a node that doesn't possess the matching private key for the published public key. That key exchange and layered encryption is what protects you from malicious nodes removing downstream nodes from the chain.


The CA doesn't send any public keys to clients.

The CA signs the server's public key with their private key and then gives that signature to the server. When the client connects to a server, the server then sends both its public key and the signature to the client.

Clients already have the public keys of all CA's they trust. These are called root certificates. Clients use those public keys to verify that the signatures on the public keys of any servers they communicate with are valid.

Now for the problem "how do the public keys of the CA's come to the client"? Some web browsers come with their own set of root certificates, others use the certificate store of the operating system. Most users blindly trust the vendor of their browser / os that the list of CA's they curated is trustworthy. So downloading and updating your web browser or operating system is a critical process for the CA infrastructure. A powerful adversary who can manipulate your internet traffic or controls the fileservers from which you receive your updates could smuggle their own CA root certificate into those installers / updates. But if they are able to slip you a backdoored update, then they can do far worse things.


How to fix AWS security hole ALAS-2018-1045?

The confusion you are facing is that Amazon & RedHat back port fixes into their known stable branch, this is to say that

gnupg2-2.0.28-2.32

Really indicates gnupg2 core version 2.0.28 with revisions 2.32;

If I am understanding your question correctly, you should run: rpm -q gnupg2-2.0.28-2.32 --changelog and inspect the changelog to ensure the installed version contains the backported fix for CVE-2018-12020


Publicly documenting your API gives attackers a head-start in identifying possible ways to abuse the API.

If you expect to host a functional Swagger UI page, ensure that your API's Cross-Origin Resource Sharing policy is not overly permissive, and that you have Cross-Site Request Forgery protections in place.

Similarly, take care to defend the Swagger UI page against frame-jacking, e.g., via the X-Frame-Options header.

Aside from those, consider these other business-related risks:

your API document is a reflection of your organization, and so should not contain things like profanity
your API may reveal exactly what sort of sensitive data it handles

social security numbers and other PII would be a big draw for attackers

your API may reveal your organization's business connections, for better or worse

for example, if your API document includes a query parameter named "exclude_data_we_stole_from_the_fbi", you may attract attention from the FBI for stealing their data

the frequency of updates to your API may signal your development or maintenance velocity to your competitors


Instagram security and two factor authentication

I think instagram uses fingerprints from the web browser, ip and os from the owner of the account, as soon as someone tries to log in and this fingerprints does not match the original one instagram will send notification, if ethical hacker tries to log in I think he needs to know the exact fingerprints and/or use something similiar or spoof the SMS code which the owner of the instagram account will get.


There are many known ways to identify packers. The 'most common' packer UPX and its variations are usually flagged as 'suspicious' by Anti-virus engines due to a signature detection in the EXe.

There's a couple of handy tools called:

RDG Packer Detector which detects specific packers based on signature checking (presumably the same way AV does it
PEiD detects most common packers, cryptors and compilers for PE files as well as allowing for disassembly (available to download via softpedia)
A simple signature DB checker in python for you to play with (not sure where to grab the DB from though (try here?)

There's also a list here of a couple of variations of packers

Once you detect the type of packer, you can use automatic unpacker (if one is already available) or you can start manually unpacking it.

  Are existing anti-virus tools good at detecting whether an executable
  has been packed with a custom packer?

No, not really, they'll be looking (like the above tools) for signatures. If you ever spend time in blackhat forums, people advertise 'FUD Crypters/Packers' which means that they've usually modified the way their packers work so that AV's don't pick up the signatures for a while allowing for malware to slip through.

According to symantect (as quoted in this paper)

  Symantec has collected a large number of packers - more than 2000 variants in more than 200 families.

The paper mentioned above also has a lot of information regarding the techniques used, the counter-techniques employed and more which will answer the second part of your question.


Is a Windows (fresh installation) 7 really this safe against NMAP or am I missing something?

The phrase "safe against NMAP" does not make any sense. An NMAP scan is not an attack.

NMAP detects and reports open ports. It does not tell you whether these open ports serve a legitimate purpose and/or pose a security risk. Nor are open ports the only possible source of security risks. An NMAP scan is only one of many elements in a machine's security assessment. You can neither conclude that Windows 7 is safe just because NMAP reports no open ports nor that other OSes are less safe because NMAP does report open ports. This holds independently of the NMAP options you are using.


Can Chrome browser history be seen on work wifi, even if not re-loaded?

It will only show up in their history if the page loads something.

The problem is there are many things that can cause the page to load something other than explicit user actions. Some sites may auto-refresh on a timer (slashdot used to do this). Some sites may use ajax or websockets to check for new content on the server (stackexchange does this). The traffic generated by such scripts is likely to be visible to anyone monitoring your internet connection.


cc-memtest for testing memory security for OpenBSD

From the blog you cite:

  ..Attempting to run my test application, cc-memtest, ...

Which means its the authors own test application so please contact the author of the blog article.

Apart from that it should not be too hard to construct a program which does these tests as long as you understand mmap(2) and mprotect(2). You will even find some code if you look closer at the pictures in the article. But help in this area (i.e. programming) is off-topic here and I recommend you just read the man pages.


Should I set a password for 'root'@'localhost' in MySQL?

The first rule of 10 Immutable Laws of Security Administration written by Scott Culp, is a good law regarding your situation:

  Law #1: Nobody believes anything bad can happen to them, until it does.

Even though your server is only accessible from within your local network, try to think of how many computers or servers are connected to that internal network. Pivoting from one computer to the other is part of a hackers job, and having perimeter-only security will save you from nothing as soon as one of the employees are victim to a spear phishing attack, and click that link in that email.

Another possibility is, what happens when someone can get a shell using a vulnerability in your website? The person can then try to access and run MySQL-commands from the shell, and in the worst case drop/dump your entire database?

Yes, managing passwords in a multiuser environment is hard, that's why software such as KeePass and LastPass offer Multi-User databases, such that multiple users can have access to the same keychain and same passwords.

My recommendation is, secure it with a strong password, because it's probably not going to be as much of a hassle as you think, and it could potentially stop your database from getting leaked or dropped. The more friction you create for potential hackers, the better!

Be proactive!


When paying for something on line, is paying with a checking account less risky than paying with a credit card?

In regards to your specific question, which is safer technically depends on the site and how they implemented their security.

That said, the credit card is a safer bet from a recovery standpoint. If your banking details are compromised, the attacker can drain your entire checking account, and there's very little recourse to get that money back. However, if your credit card details are stolen, you aren't liable for the fraudulent charges made, the credit card company is.

This answer applies to the US, where the FTC mandates the following protections:

Credit card fraud liability cannot exceed $50.
Debit card fraud liability is $50 if reported within two days of fraudulent charges.
Debit card fraud liability is $500 if reported within 60 days of fraudulent charges.
Debit card fraud liability is max if reported after 60 days or not reported at all.


In the X.509 standard (I am linking to RFC 5280 which is nominally an X.509 profile but it contains a workable copy of X.509 itself; the true X.509 standard is not free), a "Domain CA" exists. Specifically, this is a CA certificate which contains a Name Constraints extension of type "dNSName". See section 4.2.1.10, which contains this paragraph:

  DNS name restrictions are expressed as host.example.com.  Any DNS
     name that can be constructed by simply adding zero or more labels to
     the left-hand side of the name satisfies the name constraint.  For
     example, www.host.example.com would satisfy the constraint but
     host1.example.com would not.

which is exactly what you are looking for.

Now the trick is to get an existing recognized root CA (i.e. a CA which can emit certificates which Average Joe's Web browser will accept without any scary warning) to sell you such a certificate. Remember that the business model of a commercial CA which charges you 250$ per server is to be able to keep on charging you 250$ per server; since your goal is precisely to avoid giving them so much money, I guess that they may object, by, e.g., not signing your CA certificate.

Also, support of Name Constraints by existing deployed Web browsers might be a bit flaky. This is not the most widely used X.509 feature ever.


Is AES easier to crack when the input is small?

No, Unless...

It shouldn't be possible to "brute-force" possibilities unless you provide an oracle for an attacker to utilize.

An oracle in this case allows the attacker to feed as much chosen plaintext as they'd like into your encryptor, and receive encrypted output to check against.

If this is the case, you need to safeguard your data, preferably by setting an Initialization Vector for a block cipher mode like CBC or CTR (use GCM if possible), and making it so that the IV is chosen by the oracle (and not by the attacker).

Though you should really be doing this anyway.

I don't think the approach of padding your blocks with random data would be very effective in an attack against an oracle.

It could possibly mitigate an attack in the extreme edge case of only having 1 block of encrypted data, but it wouldn't be nearly as effective as just properly setting an Initialization Vector.

tl;dr No, unless there's an oracle for an attacker to exploit. If there is, make sure you're setting the initialization vector (oracle-side).


How can an attacker use a leaked private key?

Here is an example:  My dad started getting browser certificate warnings when he went to Gmail.  I looked in his hosts (C:\Windows\System32\drivers\etc\hosts ) file and some malware had edited it to redirect requests to gmail and a bunch of other sites to bad IP addresses that I assume the attacker controlled.  His browser warned him because those bad IP addresses did not have the correct private key of the certificate.  Now, if they had used a heartbleed type attack to grab those private keys, they could better impersonate the sites and my dad would have never seen a warning.


Active Directory "Forgot password" feature without email or text

The problem is that when a user has forgotten his password, you need a special procedure. Private question/answer is generally seen as a poor way, because users generally do not remember what they asked first, whether it was upper case or lower case... and if they can remember it without risk, then anybody that knows about them could answer too... Anyway you say you do not find that secure enough.

But if you want something else, you have to find a other channels. Common ones include a secondary mail address (said differently a secondary authentifiable identity) => something you know and text message on a mobile phone (something you have) - and I can hardly imagine others. Ideally, if your security requirements are medium to high, you could combine both:

when a user has forgotten his password, he asks for a reset procedure (on a HTTP semi-public page - no authentication here)
you send him one unique token on his private mail (no link in order not to break the anti-phishing com...)
you send him a second unique token on his phone with a text message
when he has got both, he connects on the reset page, types his id, the 2 tokens and the new password he wants - the password should be typed twice to avoid typo

That way if either the mail of the phone have been compromised, or if one of the messages are intecepted, an attacker  would not have enough information to reset the password. But I must admit that users could find that complex...


Pentest Results: Questionable CSRF Attack

This does not seem to be a CSRF vulnerability.

If an attacker needs to know a CSRF Token, then it's not an attack. And your approach to CSRf does seem to be correct.

Issues which leak the CSRF Token can indeed result in a CSRF attack, but then the problem isn't incorrect CSRF protection, but those issues (XSS, encryption, CSRF Token in URL, and so on).

Still, I would ask the tester for clarification. Who knows, maybe the attack always works with that specific token, because it is hardcoded somewhere, or because the special characters are causing some sort of problem for your application. Or maybe it is possible to use a token from a different user, or maybe the token check just doesn't work at all and it accepts arbitrary tokens. The report should have contained more details, so I would check back with the tester about this.


Handling the loss of a phone with FIDO UAF

According to the documentation, it appears that there is no graceful way to pass registration over to another device. Only deregistration and re-registration.

This makes sense since the keypair is generated on the device.


Should you let users know if an email has been taken during registration validation?

An intuitive and simple solution is to make sure that an automated script (malicious script) cannot try to register with a list of e-mails in order to figure out which ones are registered. For example, use CAPTCHA challenge as part of registeration to make sure it is a human trying to register an account. In this way, even if few user e-mails are tried, a massive number cannot be checked. Note we are assuming strong CAPTCHA cannot be easily broken.

But if it is super sensitive and you must hide who is registered at the target website even from human users, then finish the registration and do not show any error message to the user that the e-mail is already registered; and just inform the user at the end of the process that now they have to confirm the e-mail belongs to them, please go and check your e-mail; In the backend, if the e-mail is already registered, then do nothing; just send an e-mail to the owner of the e-mail and inform them: seems you tried to re-register at our service again, if you have forgotten you have an account with us, this is your username, and if you cannot remember your password, go to the password reset page. To be at the safe side, you can mention that if you did not try to register with us again, please ignore this e-mail.

If the e-mail is not registered in the database, in the backend, create a random one-time use token in a URL and send to the new e-mail registered and ask them to confirm the new account if they meant to create a new account.

This way is you absolutely hide everything from the bad guys;


Can server side communicate using cipher that not listed in the CipherSuite?

In short: the client offers the ciphers it likes to use in the ClientHello message of the TLS handshake. The server chooses one of these ciphers based on what is configured on the server side. This means that the server will not chose a cipher from the clients listed when it is not configured on the server side too.

What you describe can thus in theory not happen. In practice it can happen if you look at the configuration of one server but the client actually connects to a different server. This can be for example a SSL terminating load balancer which might forward the clients traffic again with SSL to you, but where the SSL handshake is done between the load balancer and the client and not your server and the client. In this case your configuration does not matter but instead the load balancers configuration is the relevant one from the perspective of the client.


Why Antiviruses does not check the library modules of exe to detect hook?

This is to avoid what is called a false positive, i.e. when the user receives an alert about a danger while there was actually no danger at all.

Do you remember this rich era when, while you were browsing the Internet, you where facing a dozen of times per day an alert bow stating something like "Alert ! The web page you are viewing contains some secured elements and some unsecured elements ! Are you sure you want to proceed !". The result of this was just that people were trained to ignore their browser's alert message and blindly click on the OK button, which was fully counter-productive from the security point-of-view.

Now this is the same with your SetWindowsHookEx API call. An anti-virus has no way to determine the intent of a software, it can only rely on a subset of facts. So, maybe the use of this API call enters as a part of an heuristic taking into account several other parameters helping the anti-virus to determine when a software has got a suspicious behavior, but the sole presence of this API call is not sufficient since it is also used by many authorized applications (same thing if you write a simple Batch file deleting all your documents: your anti-virus will not prevent you from running it).

These are the very reason why, while anti-virus provide a good level of protection against well-known malware, it can never be a bullet-proof protection and the first and better line of defense remains the user who should be properly educated in recognizing and refrain from opening suspicious files.


Attack on Tor with stolen private keys of main nodes

The directory authorities votes on what the Tor network consensus that lists all relays should look like so that a majority of the authorities need to behave badly in order to publish a malicious consensus for clients. See https://metrics.torproject.org/consensus-health.html for how the voting goes. All the private keys is not needed to win the vote and perform attacks you already mention.

You might get a more detailed answer over at the newly opened Tor Stack Exchange.


"Harmless" script which downloads malicious script

You can always come up with ways to bypass real-world virus scanners. Scanners look for data present in known viruses. They can't look for exact matches in executable files. That would mean virus programmers could evade detection by changing one byte of the file without having an impact on the behavior of their executables.

Virus scanners instead look for patterns. Peculiarities found in samples of a virus are selected to attempt to sort of fuzzy-match executables with samples of known malware. There is an inevitable false-negative/false-positive trade off in this selection process.

There is no way any scanner can catch 100% of all malware. There are more forms that malware can take than there are forms virus scanner can look for. There is also no way to programmatically determine with certainty whether a program is harmless or not for all possible executable files. An anti-virus cannot mindread, so it doesn't know the difference between a program that only does what the user wants it to do and a file that does something that the user doesn't want it to do.

(That's ignoring the fact that it's not possible to tell what some programs will do without executing them. See "halting problem".)

We have never been able to rely on virus scanners. There have always been false positives and false negatives. Traditional virus scanners can also only detect viruses that the world has already seen. If it's a new type of virus, then a scanner won't be able to detect it until after people have been victimized.

More advanced anti-malware systems might profile the behavior of programs and terminate a process if it appears suspicious. This might capture some additional previously-unseen malware, but the problems of false positives/negatives and inability to distinguish malicious behavior from benign behavior still puts serious limitations on anti-virus systems.

A virus scanner then may try to look for the kind of behavior you describe. It's possible (with a performance penalty) to look for the presence of an interpreter or for downloaded scripts in network packets. However, interpreters of different varieties are common in benign programs. The downloaded script could also be encrypted, obfuscated, or hidden in legitimate traffic using steganography. So even if a virus scanner tries to detect this kind of behavior, it would be virtually impossible to detect all malware.

Any kind of anti-malware is probably a lot, lot, lot less effective than the average person believes them to be.

Now for the really scary part. It's not required for a malicious person to trick you into running a seemingly "harmless" executable before delivering malware in a second download. Often they can use a benign (but harmful, because they have exploitable bugs) program which users typically already have installed on their computer.

Software that downloads and runs programs with admin privileges is ubiquitous. It's called "auto-update".

Real world auto-update mechanisms are frequently implemented in such a way that attackers are free to run whatever code they want if they can spoof the update server.

A malicious update file can be substituted for a benign one. An easy way to do that would be to wait for the domain of the update server of unmaintained software to expire and take control of that domain.

That's not strictly necessary, though. A man-in-the-middle attack is also an easy task if update packages are not authenticated or if there is any mistake in the authentication checking code. (Both of which are too common.)

Crucially, to prevent this kind of attack, a digital signature system should be employed with public key pinning in any auto-update mechanism.

(And that's, obviously, only good as long as the private key is never revealed to untrusted parties, trusted parties don't turn untrustworthy [I read that this happens often with Chrome browser addons, for example], the code is implemented flawlessly, and the original download of an application is legitimate.)


How is the create-react-app package tree properly sanitized?

You can use https://snyk.io/ scanner.

The dependencies of applications like react are really complex. There are same packages in multiple versions used. Also, such projects when they evolve they add more npm modules which makes it even more complex. When adding custom modules, it's good to make sure that they are in the most recent version, they are used by others, they have been recently updated etc.


How do I instantly disconnect from my ISP during an exploit or suspicious activity?

Although it looks like a nice feature to have, such kill-switch is not actually useful for common users.

Most of the times you won't even notice the exploit happening and even if you detected something strange, it is too late to stop it from running. Let's if you have such a kill-switch, how can you know for sure you stopped it in time? So, such feature can give a false sense of security.

A more drastic version of this is cutting the power to your computer and in certain cases it does makes sense. A simple example I can think of is being a bad guy and quickly cutting power to your computer when the police storm in. This prevents forensics being performed on your PC. There are tools and even hardware devices for this, for example https://github.com/hephaest0s/usbkill

You could also script something that performs the Zone Alarm feature you mention.
Right click windows desktop, New, Shortcut to create a windows shortcut then paste this

%comspec% /k netsh interface set interface name="Local Area Connection" admin=disabled

Then go into the properties of that shortcut and chose a shortcut key. You can also look for similar tutorials for other operating systems.

But remember, pulling out in time is not a good infosec practice :)


Is stolen client side certificate a valid concern for SSL communication? How to build an automatic revocation system?

Theres lots of way to detect this scenario.

1: You can detect the double login since Host_A and Host_C would be logged in at the same time, unless the attacker somehow prevents Host_A from accessing Host_B.

2: You can use the IP of the host to detect if the client IP suddenly switches. I suppose you want to have a API client that communicates with a API endpoint on Host_B, and thus, the client IP should be static.

3: You can "fingerprint" the API client, and if the API client is behaving differently (another useragent or is sending different headers), its considered a compromise.

There might be another sign of tampering, where you can detect something that is not normal. Suppose that your original API client does take a fixed time to perform specific operations. You can then time these actions and if the API client does the action quicker or slower, it can be a sign of attack.

Now to action. To faciliate quicker revocation, I would suggest, in addition to revoking via CRL. As your server can know which certificate is stolen, you can instead configure your API service to not accept logins with that SSL certificate, effectively a "soft revoke". This means that the certificate is blocked immediately, instead of having to wait for the SSL server to reread and parse a CRL into the SSL system.


How are 1x1 pixel images used in a malicious context?

Single pixels are used for traffic monitoring. There is at least one legitimate usage known to me: The German organisation VG Wort uses so-called Zählpixel to distribute some money to authors of copyrighted texts on the internet based on visits to their texts.

There are also tracking devices by advertising agencies (including the Referer Header they learn which IP visits what web page) one might consider legitimate.

Also authors of malware want to know their "customers", and single pixel images are a stealth way to learn about them.


Getting exploit reliability when using the off by one framepointer overwrite on linux

I had an extremely similar homework problem that I had in a security class. The reliability of your exploit depends on how large the buffer is. If you are overflowing a particularly large buffer, then your exploit will have a larger chance of working.

Here is how your exploit sandwich should be structured:

[NOPS][Shellcode (usually about ~60 bytes)][FP overwrite]

As you know, you will only be able to overwrite the last couple of bits of the Frame Pointer. This will cause the EIP to point into your sled if you are lucky enough. If you have a buffer of size 265 like in your example, here is how a good sandwhich would look:

[NOPS * 150][Shellcode][FP overwrite] << FP Overwrite MUST be at index 256

Now as I said, the reliability of your exploit is going to rely on the size of the sled you can produce. If you buffer is 1024 bytes, then your exploit will be very efficient.

If you come up with a good value for your Frame Pointer overwrite, then you are going to have a lot more success with your exploit. Also creating the largest possible sled is going to be key here as well. For this exploit, it is probably safe to use:

NOPS = (size of exploited buffer + 1) - length of shellcode - 1

simply:

NOPS = (size of exploited buffer) - length of shellcode

This will give you the largest change possible of landing in your NOP sled. Now just play with the FP overwrite value and find a value that is pretty consistent.

helpful info on off-by-one errors:

http://en.wikipedia.org/wiki/Off-by-one_error

How a nop sled works:

https://stackoverflow.com/questions/14760587/how-does-a-nop-sled-work

Here is the article I had to read for my class, it was really helpful:

http://insecure.org/stf/smashstack.html


Intercept Android's http/https traffic with shell access

Simply use SandroProxy (on-device) or mitmproxy (off-device), these will help you perform a MITM attack by generating valid certificates on the fly.

Then use your root permissions to install the CA certificate for your MITM proxy to the system key store (which is located somewhere like /data/misc/keystore from memory) which will avoid the usual warning you get when you install additional certificates.

You should be able to create iptables rules to route traffic via your proxy, or modify the connection settings.

If you're just using it for debugging purposes and you don't mind if the user sees a warning then you don't actually need root, you can just add the CA certificate to the user store.


Is my application affected by curl vulnerabilities if using HTTPS with a single server?

HTTPS does not solve the problem
Judging from the linked description

HTTP authentication leak in redirects - regardless of protocol, the client issues the custom Authorization: header when redirected.
Specific to HTTP/2. May or may not be influenced by SSL

So, the advice would be as stated in the issue description: patch or upgrade your curl.


How do i know if I have moved or copied a file from my SD card to PC?

There is no way of knowing. When storing sensitive data you should securely encrypt them before storing them on an external medium.

Even if you had cut them off, the files will still reside on the device and will still be recoverable unless you have securely wiped them off the drive using a file shredder. Most file systems just allocate the space as free but the bits containing the actual data will still be on the device.


Communicating through 127.0.0.1 can be thought of as just another IPC mechanism, but one that re-uses existing protocols. Just like shared memory or UNIX domain sockets or pipes, it's one of countless ways that two processes can communicate on a single system. If you trust that the processes on your system have not been compromised, then you can "blindly" trust connections going through 127.0.0.1.


How to securely transfer data from a public website, to a VPN-secured website?

You could use a synchronization service, like SyncThing or Resilio to pull data from the public server. When the users fill the forms, put them on the public server (on a protected folder), and use SyncThing/Resilio to send it to the private server. Use a cronjob on the private server to load the forms on your database.

Both use data encryption and peer2peer networking to transfer files, so the data is protected from snooping while in transit.


Threat: After testing, files have been found to be benign.

Threat Level: As stated this is more of an annoyance.

Cuckoo Score: (1.6 out of 10) This url shows some signs of potential malicious behavior.

http://cuckoo.cert.ee/analysis/2196788/summary

Cause: As mentioned, could be an Advertising Network code issue.

Solution: Updating to Windows 10, version 1803 solved the problem. MS Edge is built into Windows 10.

Latest Windows update as of May 2018:

This updates Edge to:


How does one decide whether to block malicious scanning activities?

Ideally you would like to manually inspect any abnormal occurrence. Since there are only 24 hours per day, this necessarily implies some heavy pruning, in which you automatically filter out the bulk of the automated scans. For instance, I see in my logs many attempts at accessing phpMyAdmin. I don't have this tool on my server, therefore I can safely ignore all attempts at exploiting its flaws. With similar rules for some other common attacks, I can lower the level of noise in my logs sufficiently so that I can afford to manually check the remainder.

Any attack attempt is cause of concern until you have fully understood and analysed the attack, and concluded that "it cannot work" (e.g. my case with phpMyAdmin), at which point you can ignore it. On the bright side, experience shows that between the discovery of a vulnerability, and its wide scale industrialization by bot nets, there usually is a delay of a few weeks, so patches will come first if you maintain your server properly.


Should pypi subdirectories be accessible from web browser?

That is Intentional behavior in their Web Application, The reason is PyPI is the official Third party Software Repository of the Python. It is just like catalog of all Open source Python Packages. The .htaccess Options -Indexes is not the problem here, as these are Open Source Packages and it's public faced so, anyone can go the Site and Download manually, if not than i could search the Same from my Terminal by pip search twitter for example and it will List me the same number of twitter keyword packages which the  pypi.python.org/simple has.

The Opensource deals like this, If you notice than the Ubuntu Repo, Debian repos Have no .htaccess and you can easily read all the folders and sub-folders of the repo. Most Software providers and Open source community works in the same way, because there is no Harm in Information disclosure of an open source as they are already open !! Another Reason is they can MIRROR all the content of the site packages and can use for Download if Problem in Main Repo persists.

I assume that, you are Referring to Hackerone's Python Internet Bug Bounty Program, and if you report this bug than surely it's a N/A there due to Intentional behavior


How can I authenticate a client connection in a secure way?

First, I suggest avoiding assumptions about encryption overhead. You should measure. My PC from 2001 was already powerful enough to transfer data with SSH at the full speed of a 100 Mbit/s link, with encryption. My actual PC, a common Core2 at 2.4 GHz, can do AES encryption at 167 Mbytes per second (yes, megabytes, not megabits), more than enough for gigabit ethernet, and that's using a single core -- I have three other cores.

If you want to authenticate a client then the client must have something special that the envisioned malicious user has not. Cryptographically speaking, some piece of secret data, which we will call a key because that's what keys are: a piece of secret data, used in an algorithm which is assumed not secret. Note that this entails a structural flaw which cannot be really avoided: anybody with read access to the code of the client may perform some reverse engineering and recover the key. This can be made a bit more difficult through code obfuscation techniques, but not to the point of making it impossible.

Also, you want to authenticate the connection, i.e. not only the act of initiating the data tunnel, but also the data which is actually transfered. Otherwise, the attacker could hijack the connection once the authentication step has been performed. This implies using a cryptographic integrity check, which is called a MAC. At that point, adding encryption is easy. SSH uses both symmetric encryption and a MAC.

Out of existing building blocks, I suggest the following solutions:

Use SSH. The client connects through SSH and uses a hardcoded password to authenticate itself (the password is then the key I was talking about above). Man-in-the-middle is avoided by the usual mechanism of SSH, i.e. the SSH client should keep a copy of the server public key.
Use SSL/TLS. This is very similar to what happens with SSH. The client knows that it talks to the correct server because the server public key is presented as part of a X.509 certificate, which is signed and can be validated by the client. The client must have knowledge of the certification authority public key. Alternatively, the client may already know the server certificate and just check that this is the same certificate than the one sent by the server. Once the tunnel is established, with encryption and integrity checks, the client may just send his key "as is" to prove its identity.
Use SSL/TLS with a client certificate. In this setup, the client has a public/private key pair. The private key is the key I was talking about. The public key is encoded into a certificate that the client shows during the SSL handshake. All of this is standard SSL stuff, hence supported by existing SSL libraries. Compared to solution 2, this avoids the need to include a key-sending message in your application protocol, and it also allows the use of MAC-only cipher suites, in case it turns out that encryption is too computationally expensive (which I doubt).
Use the client key in a Password Authenticated Key Exchange in order to derive a common session key, then used for a MAC (and possibly encryption). The point of PAKE protocols is that they can tolerate low-entropy secrets, i.e. passwords which fit in the brain of human users. Running a MACed tunnel has a few subtleties so the proper way is to use an existing protocol. This then calls for TLS with SRP. The "password" is hardcoded in the client (and although SRP tolerates short passwords, nothing prevents you from using a long and very random password). The beauty of the thing is that this suppresses any mucking with certificates or known public keys. The client is authenticated by virtue of its knowledge of the password. Simultaneously, the server is also password-authenticated by the client. As an added bonus, with SRP, the server only stores a password-derived piece of data, which is not directly usable by the client, so an attacker reading the server database does not gain automatic access as a "client".

My favorite solution is of course the one with SRP. It is elegant. Unfortunately, SRP is rather new, so not all SSL/TLS implementation support it. But GnuTLS does.


If I delete my router's history can my ISP still provide it to my parents?

If I delete my router's history, is it still visible and can my ISP still provide it to my parents? Or is it deleted from existence?

Your ISP's record of your network usage isn't in any way affected by you doing anything to your router. You could wipe its memory, subject it to an EMP, and crush its chips to dust, and it wouldn't have any effect on them. :-) They maintain their own logs, which you cannot delete.

Whether your ISP will provide that information to your parents is another question, I expect it varies by locale/jurisdiction and possibly ISP.

You can make it (nearly) impossible for your ISP to know what sites you're visiting by using Tor or similar. The project includes Tor Browser, based on Firefox ESR, which makes it really easy to browse over Tor. You can also use the Brave browser (no affiliation), based on the Chromium project, in its "Private window with Tor" mode. This is not user-configuring a browser for Tor (which the Tor project advises against, it's too easy to miss out important things), it's a browser from privacy-obsessed people with a Tor-enabled private browsing mode. Both Tor Browser and Brave have trade-offs, see this tweet thread (in particular the replies from Tom Lowenthal, their Security & Privacy PM). Some people say "You should never browse with Tor with anything but Tor Browser" but it's more nuanced than that.


How secure is hardware Full disk encryption (FDE) for SSD's

TL;DR: Do not use hardware encryption on any storage medium no matter whether it's a thumb drive, an HDD, or an SSD! That's a really, really bad idea!

Hardware manufacturers are know to have included back doors or just bee very, very stupid about encrypting the data. This goes as far as them just using the same key for all their devices or them letting the encryption keys lay around unencrypted and hoping that no one will change the firmware in a way that allows someone to access them without knowing the password. I've heard and read this a lot and can't possibly show you my actual sources but here is an article confirming what I just claimed.

Hardware manufacturers are also known to have been forced to lower the level of encryption. Same way I know this as above and this article confirms it.

Just picture what's happening when you use hardware encryption. You buy that magical device from someone who claims that only people who know the password can access the data stored on this. That person does not show you how it works. They may also lie to you (see article linked in the previous paragraph) with you having very little chance of ever finding out. You have no way of verifying or disproving those claims.

Of course, don't trust software encryption by hardware manufacturers either. I bought a USB stick about 5 years ago from SanDisk (still have it and last used it an hour ago) which came with an "encryption software". I never used that encryption software, not only because it's against all standards one should uphold about encryption (see last paragraph) but also because after very little research I found that that software (which only worked for MS Windows which itself is another very good reason to never use it) writes 1 or 2 characters (I forgot whether it was 1 or 2 but that doesn't matter) into a file which it created in the Windows user folder if the correct password has been entered. Those 1 or 2 characters showed the application that the user had permission to access the files. If you simply wrote the correct content to the file (which is the same for everyone using that software), you could access the data stored on the thumb drive without knowing the password. So don't use that either.

Software encryption is much better because you as the user control which software is used. You can take a look at, pay someone to take a look at it, if it's commonly used (And it should be!), others will have a look at it anyways, and if it's openly developed, there are people publicly arguing about how it should be to be as secure as possible and those people don't trust each other.

Furthermore, you have an easier time switching out the software used for encryption. If you use hardware encryption, once you have the hardware, you use the specific encryption that hardware provides. You'll be reluctant to spend a lot of money to buy new hardware and throw the old hardware away, even if it's revealed that there are security issues because "It's not that bad." and "No one will attack me, anyways." whereas you would've thrown out a software with similar flaws and exchanged it for a different one within one day.

Only use encryption software if it is free and widely accepted to be secure. That it is free requires that you can get hold of its source code if you don't know that. (Not that it being open source is necessary, not sufficient.) If you are denied access to the source code, never trust the application! This of course includes not trusting it about protecting your data from unauthorized access. If it isn't widely accepted to be secure, it's very likely that the people who created it made mistakes (one can make an awful lot of mistakes about encryption and has to do a very good job in order to make encryption secure) or even maliciously made it insecure which can include not encrypting anything at all.


Block a file from being accessed over the internet

The file is not going to be accessible over the Internet. There is nothing offering the file to remote people.

What can happen, though, is that someone can hack in and gain access to your computer, and from that level of access, gain access to any file on your computer.

The most important protection for this is to do exactly what you have done: encrypt and password protect the file.

As an additional measure, you could store the file on a removable drive and disconnect the drive when you do not need access to the file yourself. This is not as secure as it sounds because once you connect the drive, then anyone who has hacked into your computer could then also access the file. But it is an additional measure.


If you can create iMessages using SQLite, then you need to root the phone. So if the phone is rooted, you can't trust these messages.

Another case would be if you rooted the phone and then unrooted it, this way one can perfectly fabricate it.

Another thing is analysis of the SQLite file. If you add records to appear as they are yeards old, but in the file they are added at the end, then you might conclude these are fabricated. This also can be sorted by redumping the SQLite file, so exporting it to SQL queries and importing into file again. This way records will look like they have been saved years ago.

So by unrooting the phone and redumping the sqllite file you can pefectly fabricate it. You would need to unroot in a way to not leave any traces of rooting.

Finally you would need to make sure on the flash there are no old copies of SQLLite file.


Malicious NPM Package - Does it fit into OWASP Top Ten 2017?

It seems clear to me that a maliciously coded library is perfectly covered by A9:2017-Using Components with Known Vulnerabilities. I thought that A9 was created for this very use case.

Although the wording from OWASP talks about older libraries that have vulnerabilities discovered over time (Heartbleed) and replaced, there is nothing in the wording that suggests that this must be the reason for the vulnerability. Intentional malicious coding works just as well as a reason.

A debate might arise over whether or not "malicious coding" can be equated to a "vulnerability" since the malicious code could be working as intended without unintended effects. I think this debate is a little pedantic and the spirit of the OWASP Top 10 is supported by equating the two ideas.

Maliciously coded libraries are not a "misconfiguration". A misconfigured library is one that is not vulnerable, per se, but introduces vulnerabilities due to misuse.

Maliciously coded libraries could introduce XSS vulnerabilities, but A7 is too specific in this case.

Insufficient Logging and Monitoring is a meta issue that affects all potential situations and is too broad to be applicable to this threat scenario.


Does this reflected XSS vulnerability pose any real threat?

It will render that content in the div and show the alert.
  My question is if the act of rendering the contents of the textbox on the client side could pose any kind of threat? If so, what could a malicious user do?

If this is the case I would fix it (defence in depth), but as AviD pointed out without seeing the full site and its context, it is difficult to comment further.

  When the user saves the record everything is HTML encoded when it gets to the server and then saved to the database, so there is no stored XSS vulnerability.

As an aside, you should only encode the data when output - unless you are storing rich text that the user has control of (in which case other steps should be taken), you should store the text in raw format and then encode when output. This is because the encoding required differs between HTML, JavaScript, XML, etc - the context in which it is output is all important.


How to configure more than one same Hardware Security Module (HSM)

I don't know the HSM Let's Encrypt is using. But all major vendors have different mechanisms for doing backup and recovery to an encrypted medium.

One vendor-specific example:

If you setup nCipher/Thales HSMs from scratch a so-called "world key" is generated which is stored encrypted on normal disk and with which all keys used for crypto operations within the HSM are encrypted.

The world key itself is encrypted with a key stored distributed on a so-called "admin card set" (Shamir's Secret Sharing). So with the files and a configurable k-of-n subset of the admin card set you can restore the world key to a new blank HSM and thus let the HSM decrypt all the key stores also restored to the HSM. They call it "add HSM to security world".

Of course you have to implement your own organizational and technical security controls around that to implement a really secure backup and recovery process.

Having said this you still have to trust the HSM vendor that there is no back-door in the firmware to extract the keys in an undocumented way.


There is no indication of ARP spoofing, at least not in the information you have provided. What you should see in case of ARP spoofing is that your default gateway has the wrong MAC address, i.e. you would need to verify the MAC address in this entry:

172.16.130.193        00-25-90-ea-31-33     dynamic

Everything else are all perfectly valid entries:

224.0.0.22            01-00-5e-00-00-16     static
224.0.0.252           01-00-5e-00-00-fc     static
224.0.0.253           01-00-5e-00-00-fd     static
239.255.67.250        01-00-5e-7f-43-fa     static
239.255.255.250       01-00-5e-7f-ff-fa     static

These are multicast addresses, not your neigbhors. From Wikipedia Multicast Address:

  IPv4 multicast addresses are defined by the leading address bits of 1110, ... The group includes the addresses from 224.0.0.0 to 239.255.255.255. Address assignments from within this range are specified in RFC 5771...

172.16.130.255        ff-ff-ff-ff-ff-ff     static

And this is the broadcast address of your network


I left my debit card unattended -- how exposed am I?

Yes, you card can be misused at various places. Though, it has never happened to me, I believe there are some websites which accept payments from debit cards without any secure 3D password. All they ask for is CVV and Card#.

I would suggest you to block it right away.


Except for user space network stacks the operating system fully handles the complete TCP handshake in the kernel and notifies the application only once the connection is fully established. The kernel part is handled in a lightweight way, i.e. usually there are no kernel threads involved. What's happening in user space after the connection is established depends on the application. Some applications create a new thread or a new process for each new connection while others handle it  inside the same thread and process.


What's the purpose of the MASK in a WebSocket?

The reason for the masking is to make websocket traffic look unlike normal HTTP traffic and become completely unpredictable. Otherwise any network infrastructure equipment which is not yet upgraded to understand the Websocket protocol can mistake it for normal http traffic causing various problems.

This is especially a problem for caching proxy servers and leads to possible attack scenarios. Specifically crafted websocket traffic can cause cache poisoning by tricking the proxy servers into mistaking a part of a websocket communication for a request and response for an unrelated URL, cache it like a legitimate response and send it to other users which request that URL.


One option is to generate the users key from their password at login (or store randomly generated keys encrypted with it). This is then stored in memory while they are logged in and wiped from memory on logout / session expiry.

There are still issues here -

How do you enforce wiping the key on session expiry? - an action occurring here isn't usual server workflow.
You need to take steps to prevent the keys being paged out to disk.

Another option is to encrypt/decrypt at the client side using something like the WebCrypto API.


Questions about RSA/asymmetric key encryption?

You're looking for two things, both of which RSA can provide:

You want to encrypt a message so it cannot be read without the private key of the destination.

This is encryption TO the public key of the destination.  You're doing this already!

You want the destination to be able to verify that you, the approved source, is in fact the one who sent the message.

This is signing and verifying.  You need to sign the message with your (the source's) private key when you're encrypting it to the destination's public key.  Then the destination uses your (the source's) public key to verify who sent the message.

An example of using GPG to do this from a batch file (i.e. automated commands - you SHOULD have an RSA key pair for nothing but this, since the passphrase is vulnerable in the batch file).  If you have a human sending commands, they should NOT use the --passphrase argument; have them enter it into your software so it's not vulnerable!

  gpg --batch --encrypt --sign --local-user "Your own private key <YourEmail@you.com>" --passphrase "Put your private key passphrase here" --recipient "DestinationKey <their email>" --output "test.command.gpg" "test.command"

You will, of course, need to make sure the destination verified the message, and that the signing key is, in fact, the correct one.

Another reference is What is the difference between encrypting and signing in asymmetric encryption?.

EDITED TO ADD: As far as alternatives to RSA for asymmetric encryption, the two most common that I'm aware of are DSA (based on discrete logarithms, and please try to use a |p| >= 2048 and a |q| >= 224, just as you'd use at least 2048 bits for your RSA key) and EC (Elliptic Curve - be very careful which curve you pick - the 25519 curves seem to be well regarded so far, ans use at least 256 bits) variants like ECDSA (Elliptic Curve Digital Signature Algorithm. See Signatures: RSA compared to ECDSA and RSA vs. DSA for SSH authentication keys for references.


What registry windows keys malwares target often?

The most common?  Probably HKLM\Software\Microsoft\Windows\CurrentVersion\Run -- it's how programs arrange to be run at startup.  Of course, a lot of perfectly harmless programs also use it, so watching it won't gain you much.

The problem with simply watching registry keys for modification is that normal programs also change many of them.  You can't, for example, tell the difference between a spyware toolbar installing itself and an ordinary toolbar being installed just by watching Internet Explorer's section of the registry.


How to handle CRLs correctly in long-term electronic signatures?

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

The theoretical background is the following:

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

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

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

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

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

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

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


Program claiming a dedicated user to run itself

Clamav is a daemon. The Linux Standard Base Core Specification recommends that daemons run under individual User IDs. This way you have fine-grained access control for each daemon, and in case one of them is compromised, the attacker does not automatically have unlimited access to the system (as they would if the daemon ran as root, for example).


How to check if I have a rogue SSL/TLS certificate?

RCC or Sigcheck will do that for you.
RCC checks the Firefox root store too.


Every single browser tracks every single user!
They need telemetry and analytics for a better understanding of the user's habits.
Actually, I think if you conduct the same experiment with a different browser, you will probably get the same result. Facebook, Google, and all the "others" have what it's called "activity trackers" which means that they can track you even if you're not using directly their services (typically, Facebook will track you even if you are not on Facebook).
Technically this could be done via the "like" button, for example, any website that offers a "share", "like" or whatever feature specific to Facebook, lets Facebook track you!
More generally, every one (Facebook, Google,...) use also what's called  "Web beacon" or "tracking pixel" which is:

An HTML code snippet that is loaded when a user visits a website or opens an email. It is useful for tracking user behavior and conversions. With a tracking pixel, advertisers can acquire data for online marketing, web analysis, or email marketing. With log file analysis, long data evaluation, or using appropriate analytical tools, this data can be used for different purposes, for example retargeting.

This said, and to answer your question, the fact that you were tracked, is probably more related to the web page you visited and not to the browser you used.


Will my 445 port still exposed when I connect a windows machine to my android phone's hotspot/tethering nerwork?

This depends on how you connect it. If you connect to a network Windows gives you the option to decide what kind of network this is. If you choose that you are on a public network (which is usually the default) then the SMB services will not be exposed to the network. But if you chose private network instead they will.

Note that exposing this port to the Android phone does not necessarily mean that it is exposed to the internet. As korockinout13 correctly says in his answer the phone will do NAT which means that the port will not be directly reachable from outside. But, the port will still be reachable from the local network, i.e. from any other systems connected to the same hotspot. This means that if any of the systems connected to the hotspot is already infected the attack might spread from this system to your system.


External Penetration test by third party

The "scope" generally does not state something like "You can't root the machines", as a client you want to know if this is possible IMHO. Once root access is acquired it's basically game over anyway.

What the scope should say is the amount of servers and its server names / IP's and that it the assessment is restricted to these devices only. This to prevent that once a machine is compromised, the security consultants start to work their way in to the rest of the network.

Let's asume that there is a buffer overflow in a daemon or an application. Would you want them to spend time on exploiting this buffer overflow or find more vulnerabilities?

Generally, as a security consultant, I explain the situation to the client that given enough time the buffer overflow could most likely be exploited. I will ask if they want us to continue on exploiting this or spend time in to looking at other parts of the system.

Also, we report high and critical vulnerabilities immediately and have a daily evaluation on the findings.

Talk to the consultant(s) on a daily basis, communication is key here (something the consultant(s) should do towards their clients anyway IMHO).


Can an ISP block BitTorrent peer discovery but not file transfer?

As far as I remember the bittorrent protocol have two main components, one on UDP with DHT(Distributed Hash tables) and the current file transfers (upload and download) over TCP. All the management is doing by DHT and for an ISP is easy to identify this traffic and in consequence drop/block. Bear in mind that the traffic signatures for bittorrent are well know and ISPs can differentiate between the peer information(using DHT) and the upload/download component on TCP. This is in general for the majority of the bt clients as far as I remember.


Does a random set of secondary passwords add any security?

Well, it certainly doesn't make it more insecure. You still have your primary password, which we'll just assume is stored correctly.

And in addition to this (I'm going to assume that you have to enter both, not one or the other; if that would be the case, this wouldn't be very secure, see the links @D.W. provided in the comments.), they have a secondary password. Let's assume it's stored in the worst way possible: plaintext(*).

so we don't care what happens in case an attacker steals the database (hashing of this additional password wouldn't add a lot of security for that anyways).

  So my question is, does this kind of secondary password add any security?

This still adds security. The benefit of the randomization is that someone could intercept you logging in once, and still not be able to log in themselves without them taking further steps.

This isn't a whole lot of added security, but it is some and I think it makes sense as an defense in depth strategy.

Example of what this might protect against:

You are at a friends house (or you have visitors at your place, or your using your laptop in public for online banking [don't do this]) and have to send them some money. They look over your shoulder and see you entering your password(s). Without the randomization, they can log in themselves and see how much money you have, what you spend it on, etc. And if you forget your cell phone and are using mTAN they can steal from you.

With the randomized second password, they would have to brute force (either the online login or the hash if they managed to break into the bank(*)), or look at you entering the password a whole bunch of times.

There are 8 over 3 = 56 possible combinations of characters to enter (assuming you always have to enter 3 characters), so refreshing until they get asked the exact same characters might be annoying (or might get them blocked).

Maybe they are not quite sure about your primary password and are hoping to just try a couple of variations, which would be a lot more difficult with the randomized secondary password.

So yes, I think there are real-world scenarios which this kind of randomized password protects against, especially against technically less experienced attackers.

(*) Breaking into the bank seems to me like a far less likely attack vector than someone intercepting the password.

  Or how much additional security will we have if we use a secondary password without randomizing the letters like this?

You mean just having two "normal" passwords? Assuming it doesn't tell you which password was wrong, it's the same as requiring 16+ characters for a single password for online bruteforce attacks. If they do tell you which one was wrong or if you managed to get the hashes, well then it would add the security an 8 char alphanum password gives you.

This of course doesn't defend against the scenario described above.


In Microservice Architecture, how to secure inter service to service

The rule is that a request coming from B to A should provide the same authorization context  as if it came from the API Gateway. The details depend on the implementation.

If all the authentication and authorization is handled at the gateway, and only authorized requests can reach the back end services, B has nothing special to provide: A will answer without wondering about authorization

If the gateway only handles authentication and passes roles to the backend microservices  that are used to control the permissions parts, then B has to provide the roles it received in the request it submits to A

... you mileage may vary...


Exposing internal, rental web app for multiple shops/employees

Your question (as stated by Joshua) isn't necessarily a security concern. But part of it might be, so here is some background information you might want to think about:

If you create a webapplication and create it with security in mind, your two most likely risks might be: 1) Leakage of data (e.g. from your database) and 2) compromization of the server and (afterwards) an attack from that point towards your clients or third parties. If your webapplication is using proper authentication and all the well known security mechanisms it may very well be sufficient and you could just put it on the internet (that's what quite a lot of sites do ;). You could as well put it on an internal vpn and decrease the attack surface in that way. An attacker would have to gain access to the vpn, before being able to attack the server itself. This might increase attack complexity but also increases the complexity of your infrastructure. Since both can be equally safe and unsafe this is not really a security question.


What maximum password length to choose when using bcrypt?

I don't favor silent truncation because it misleads the users into thinking that their entire password was accepted when it wasn't.  I'd prefer a system just set a maximum length, if necessary, and restrict the user to that during password input.  One bad scenario I've heard of is a code change that begins processing characters beyond the previous max length and suddenly the longer password users can't log in.  The system only has a record of the first 72 characters and their longer string doesn't match that without the old system truncation.  That leads to frustrated users.

As an alternative to truncation at 72 characters you should consider pre-hashing the password with something like SHA-256.  The allows the user's entire password string beyond 72 characters to be considered while still providing the computational protection of bcrypt.


Fully analyzing all four would make this answer too long, but let's compare the AWS and AliPay schemes.
Alipay HTTP signatures

To me this looks very similar to the Signed JWT / JSON Web Signature (JWS) scheme (wikipedia, official spec in RFC 7515). So the entire contents of the JSON body will be protected by the signature. But that's not the entire message. The full HTTP message will include headers and be something like (I'm inventing this)
POST /api/v3/payment/paycancel HTTP/1.1
Host: alipay.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Authorization: f2a905cba5482c77c4468d5f62c3cafe35c8c76ff7effae2e15085bd1edb579af9729b487753cc2f95ae9099a005a4ef2c013c8531c0addb8771b527cf3508bb
Content-Type: application/json
Referer: https://www.google.com/
Origin: https://www.google.com
DNT: 1
Connection: keep-alive
Content-Length: 787

{"request":{"head":{"version":"2.0.0","function":"alipay.intl.acquiring.agreement.payCancel","clientId":"211xxxxxxxxxxxxxxx044","reqTime":"2001-07-04T12:08:56+05:30","reqMsgId":"1234567asdfasdf1123fda","reserve":"{}"},"body":{"merchantId":"218xxxxxxxxxxxxxxx023","acquirementId":"2015xxxxxxxxxxxxxxxxxxxxx747"}},"signature":"c1hTR2RBNHRSNEIwd25GNk5yOFNocGZOTXRISVNXdXpMcGRLb05Xc2tJZ0Njc3BNVkZGemdrZXo0QnJtdFlYa01xWmgxdHl6LzhzTk5VM0YyVlR1MGZPeCtaUDRDbm1Wak51OGJjaXU0aFR0bnl0QTNZMUdaL3lYQVVEK21WWUdYZXlETzNmSHJxRGRJN2szeFYvUThGQ09kMGN1bFRzTjZSUk14TVpxK29xUjJ4K0VqT1hWb2ZwN0JaSndoUUU4VXM0QWw1NzNGUXo1RUhEdkNMeDM1bHEyaG9NaFhMQ1ZMVkRCSGNwQ2dvdHVZNG1nOTFNWGgvcXFjRkdZL2hRS2hHZFdBYlo5dGNwMlE1czJFU2gzN3JxeG5Pd1pycmVwSzhOQzZ2TUJQVWlTUHhRZWZwZXYybkcwSnpBSE9qUlBiQlhZdzFYQlM2UkJZS0FtdWZaWmlRPT0="}

Now, with Alipay's signature scheme, only the JSON body is protected, not the HTTP headers. Could an attacker do damage by intercepting your request and modifying the HTTP headers? Maybe.
AWS HTTP signatures
The AWS page you link to says:

To sign a request, you first calculate a hash (digest) of the request. Then you use the hash value, some other information from the request, and your secret access key to calculate another hash known as the signature. Then you add the signature to the request in one of the following ways:

Using the HTTP Authorization header.
Adding a query string value to the request. Because the signature is part of the URL in this case, this type of URL is called a presigned URL.

While that page doesn't give a whole lot of technical detail, it sounds like they are trying to sign over the entire HTTP request (including headers) and not just the JSON body.

Wouldn't it be great if HTTP signatures were standardized?
It's been tried. Many times.
In 1999 RFC2660 defined the Secure HyperText Transfer Protocol (S-HTTP), which carries HTTP messages inside Cryptographic Message Syntax (CMS) containers -- the same trick that S/MIME uses to encrypt and sign email. For whatever reason, this never caught on.
More recently, I've seen a couple of attempts at the IETF to sign HTTP requests and responses using headers, similar to what AWS does above:

draft-yasskin-http-origin-signed-responses: "Signed HTTP Exchanges"
draft-cavage-http-signatures: "Signing HTTP Messages"

TL;DR: signing HTTP messages sounds obvious, and it is if you only care about signing the payload of responses and POST requests -- do what Alipay has done and use JWS. Signing the entire HTTP message, including the requested URL and other headers is a lot tricker and standards bodies have been trying for over 20 years to come up with an HTTP signing mechanism that is both secure and flexible.


Trace large volume of web traffic, stopped at VPN

Options:

Ask the VPN provider nicely.
If it's sufficient to do so, get the law involved.
Try to send a payload that identifies the machine. Javascript that returns the ip address, accesses another network (maybe not all of it is VPN), etc.

That's about it for tracing info. You may be able to shut them off without too much effort, but I think it is the business of most VPN providers to not disclose information to the public.


As you point out, this is not TFA. It is simply providing you 2 different ways to access your account. You can choose which way you feel is more secure for your situation: a password, or a physical device (such as your phone).

Password advantages:
No one should ever be able to gain access to your account via the provided login mechanisms without knowing your password. If your password is sufficiently long and complex such that it can only be guessed via brute force, then even if Yahoo were hacked and password hashes were stolen, it is extremely unlikely that your password would be hacked prior to you being notified that you need to change it.

Password disadvantages:
Your password could be compromised without you knowing it. For example, this could happen if you enter in your password from a compromised computer (keylogger) or when using a compromised network (MITM attack) and you happen to click through the browser warning about an invalid certificate. Another (usability, not security) disadvantage is if your password is long and complex, it is annoying to manually enter it in on a computer where your password manager is not installed.

Device Advantages:
Someone would need to have physical access to your device in order to login. (Or they must be able to do what you would have to do if you lost your device: reset your password by having access to your email and possibly being able to answer security questions about you). If you have your device on you, then you can be pretty certain no one is currently using your Yahoo account.

Device Disadvantages:
If someone gains access to your device, they can easily access your account. Furthermore, if you lose or misplace your device, you will not be able to use your account until you have your device again, or you will have to recover your account with a reset.

As for which is better in your situation, some things to consider:

Do you frequently use public or shared computers? Then I would lean towards the Account Key.
Is your device frequently left unlocked or using a weak protection algorithm (easy pattern, easy 4 digit passcode)? Then perhaps lean towards a strong password.
Do other people have access to your phone that you don't want to have access to your account? Then definitely use a password.

This FAQ page answers questions about how to recover/reset your account.