Active Directory Certificate authentication trust

Certificate-based authentication in Windows require at a minimum:

authentication certificate's chain ends with a trusted root CA
issuing CA certificate must be installed in the NTAuth DS store.
revocation information is up to date for every certificate in the chain (except root CA, of course).

So, if root CA is compromised, only first requirement is met. There is no way to forge an already existing issuing CA certificate with the same public key. Certificates in NTAuth DS store are compared with exact match. This means that if root CA certificate is not installed in the DS store, it cannot be used to issue authentication certificates. Even if attacker attempts to do so, they won't work, because root CA certificate (as issuer of rogue authentication certificates) is not installed in the NTAuth DS store.

In order to craft legitimate authentication certificates, an attacker must compromise the CA which certificate is installed in the NTAuth store.


Can Google access data in their Confidential Computing VMs?

I found: https://www.youtube.com/watch?v=0-ISmJNxGiY
Watching 11:00-15:30 it seems my theory with the internal web server is pretty close to how it is designed.
So this confirms that it is indeed possible. This is HUGE: In time we will be able to run on untrusted hardware as long as we trust the CPU. So this answer is indeed outdated: How to prevent a hosting company from accessing a VM's encryption keys? The answer is not entirely wrong, because a dedicated attacker could open the AMD CPU and attach wires inside the CPU, but it would make the attack much harder - especially if AMD actively made the CPU tamperresistant.
But since Google does not seem to provide the information from the slide at 15:00 (i.e. I do not get the PDH and do not get to talk directly to the CPU) it seems Google still has control over the server: They have an (undisguised) Man-in-the-middle, namely their control panel, which could be lying about your VM being spawned on an AMD CPU.
This leads me to the conclusion that Google Confidential computing VMs are probably well guarded against attacks from other VMs running on the same server (like https://rambleed.com/), but they are not currently guarded against an attack from Google.
If, however, Google gave me access to the PDH this could change.
With the certificate from the AMD Secure Processor I can set up a secure channel to this unique CPU using Diffie-Hellmann (the chip endorsement key https://youtu.be/0-ISmJNxGiY?t=728 and the platform Diffie-Hellmann https://youtu.be/0-ISmJNxGiY?t=660) - pretty much like https, where you can also check the certificate is from the correct website by following its chain of trust.
The hardware outside the CPU will thus be similar to the internet when talking https: You do not need to trust the hardware (just like you do not need to trust the internet), because it only sees encrypted data.
Said differently: With normal computers we have no problem connecting them to internet that we do not regard trustworthy: We use encryption, so that anyone spying on the data going into and out of the computer will only see encrypted data. We can still check that we are communicating with the correct recipient using digital certificates.
AMD SEV just moves this limit inside the CPU: Everything going in and out of the CPU will be encrypted. And a cloud customer can check he is talking to the unique AMD Secure Processor by using the digital certificates.
The hypervisor (which is the first OS that boots on the machine and which is used to provide internet access to the AMD Secure Processor) does not have to be trusted. The hypervisor is isolated from the VM: The hypervisor can read and write the encrypted memory, but not the key for this encryption (https://youtu.be/0-ISmJNxGiY?t=86). A bit like VPN: You can have an untrusted connection carry a trusted connection on top of it.
The hypervisor can control VMs, but it cannot set the encryption key for the VM. A bit like an ISP who can throttle your internet connection without being able to decrypt your VPN.
The trusted VM starts by having a unencrypted, untrusted BIOS (https://youtu.be/0-ISmJNxGiY?t=563). This BIOS is then hashed and encrypted by the trusted CPU, and the hash is given to the customer. This way the customer will know if the BIOS for the VM is changed. If the customer accepts the hash as correct, he will then inject a secret (e.g. an encrypted disk image or a key to open an encrypted disk image stored on untrusted storage) (https://youtu.be/0-ISmJNxGiY?t=639), and then the VM boots in the encrypted RAM.
Summing up the similarities between https and AMD SEV:

Feature
HTTPS SERVER
AMD SEV

Untrusted features

Fast storage
Full disk encrypted SSD
Encrypted RAM

Slow storage
Encrypted remote backup
Full disk encrypted SSD

Control channel ("network traffic")
https encrypted
Diffie Hellman encrypted

Trusted features
The whole server
AMD Secure Processor

Certificate
TLS-certificate for https
certificate for secure processor

Certificate authority
e.g. Thawte
AMD

Key for fast storage
full disk encryption key
RAM encryption key

Key for slow storage
backup encryption key
full disk encryption key

Key storage
small boot disk
secure encrypted NV-storage

Would I recommend CIA do their confidential data processing in North Korea's confidential cloud (assuming they have one)?
No: AMD's SEV makes it much harder for an attacker. An attacker cannot simply take a snapshot and use that. He can, however, still corrupt memory, and if he is willing to open the CPU he may be able to bypass some security by attaching wires. But these attacks are out of reach for a normal cloud hosting provider.
So it does not protect against a truly dedicated evil hosting provider, but it does seem to protect against a sloppy hosting provider, who does not have major resources for attacking the customer's data.


Avoid being hacked with brute-force attack

There are a few things, options, settings etc; that you could set in order to improve application and underlying server hardening. Here are my recommendations on what I believe to be a good balance between easy implementation and effectiveness.

Limiting Connections

The biggest instant impact, that may not cause too much difficult to configure depending on the specific option you go for, would be to limit who can connect to the application.

Black listing is certainly an option but as you have described the attacker is constantly changing IP addresses. I would recommend you do not do this.

A white list would be a better suggestion and allowing only certain IPs to access the application. This would stop the attack in its tracks.

You could combine this with a VPN, this would mean those working from home (with most likely dynamic IPs) could easily connect to the application without having to get someone to give them access.

Secure Passwords

If this slow attack has in anyway resulted in an account being breached, you really need to question your password policy. There are many many references on this site giving password advice, I will not go in depth here.

If your password is worth its salt (haha) this attack shouldn't phase you.

Change the default username

If you can, change the default username from admin, you will throw a lot of people. I mean, first user I always try is admin.

Do Not!

Do not disable the account after X tries, you are just asking for a DoS.
Do not (or at least avoid) blacklist so many IP addresses, they are probably popular VPN services, which many people use a lot.


Anomaly on new laptop. Does it suggest tampering?

There's simply no way to know. What you are describing could be evidence of a botched tampering job or a simple flaw that occurred during assembly. There's no way that anyone would be able to determine whether or not it was tampered with given the information you've provided. Most likely it's fine.

Is there any particular reason you would suspect tampering? Did you buy the laptop from a reputable company? Was it purchased online and delivered (which makes interdiction possible) or did you pick it out in the store (in which case targeted modifications are infeasible or impossible). If you do not have a solid reason to suspect that you are being targeted, then the likelihood is that this is benign.


Return oriented programming (ROP) - Why does it bypass ASLR and what are pop/pop/ret for?

ROP is only a bypass for DEP - ASLR actually is the protection against ROP. The code section is randomized and that's why you can't (normally) use ROP against ASLR - to bypass it using ROP, you'll need an information leakage which discloses how the address space was changed.

As for the pop/pop/ret gadgets, these are used in the context of using SEH for code execution - a means of bypassing some analysis/protection methods other than DEP and ASLR.

Here's an explanation for POP,POP,RET in the context of SEH: https://dkalemis.wordpress.com/2010/10/27/the-need-for-a-pop-pop-ret-instruction-sequence/. As for ROP, the best resource I know of are Corelan's tutorials: https://www.corelan.be/index.php/2010/06/16/exploit-writing-tutorial-part-10-chaining-dep-with-rop-the-rubikstm-cube


Need help on understanding obfuscated code in CVE-2012-4969 exploit

From what I can tell, the string YMjf\\u0c08\\u0c0cKDogjsiIejengNEkoPDjfiJDIWUAzdfghjAAuUFGGBSIPPPUDFJKSOQJGH in question is interesting. However, the use of \u0c08\u0c0c is the value of EDI after during the use after free. As for the rest of the string, it just looks like that is what was used in another person's 0-day before it was translated.

Some information was adapted from http://blog.vulnhunt.com/index.php/2012/09/17/ie-execcommand-fuction-use-after-free-vulnerability-0day_en/


You didn't give us information about how the XML is used/parsed afterwards. Still I've got two points on this:

By using something like http://host/file.xml?a=b%20x=y someone will be able to add an additional attribute depending on how you deal with the output, this might be a problem. Also some parsers take the first occurrence of an attribute, some the last and some even concatenate values with the same key. So what about http://host/file.xml?x=z%20x=y which may result in something like <element x=z x="y" /> (of course this also depends on how strict your parser is and what values are accepted for x.
Depending on the parser, there might be ways to encode characters like "/> when sending them to your application without them being HTML entity encoded.

If you provide more information, we might be able to give you a more specific answer. Anyway, I would highly recommend not to insert unchecked user input into any XML. If really needed, you should at least use some kind of filtering (the best would be a whitelisting of accepted values or at least a regex for what you want to accept). In addition, the XML parser should also be provided a schema to validate the XML.


How does the public key get authenticated during an ssh session

What about this description?

  The client begins by sending an ID for the key pair it would like to authenticate with to the server.
  The server check's the authorized_keys file of the account that the client is attempting to log into for the key ID.
  If a public key with matching ID is found in the file, the server generates a random number and uses the public key to encrypt the number.
  The server sends the client this encrypted message.
  If the client actually has the associated private key, it will be able to decrypt the message using that key, revealing the original number.
  The client combines the decrypted number with the shared session key that is being used to encrypt the communication, and calculates the MD5 hash of this value.
  The client then sends this MD5 hash back to the server as an answer to the encrypted number message.
  The server uses the same shared session key and the original number that it sent to the client to calculate the MD5 value on its own. It compares its own calculation to the one that the client sent back. If these two values match, it proves that the client was in possession of the private key and the client is authenticated.


What you describe here is little more than a randomly generated session id, however most of the things which differentiate this from a session id are a disadvantage to your security. The one advantage is that you are storing state at the client and hence have a scalable, fault tolerant solution. But it does require rather a lot of processing to decrypt an asymmetric cypher.

However as the token contains encrypted data, you are putting your trust in the effectiveness of the algorithm and its implementation. Users will be in posession of both the cypher text and at least part of the cleartext - which is a big help in breaking the encryption.

As described, there is nothing to protect against a mitm (e.g. setting a ttl and key re-negotiation mechanism) or xss attack.

As it stands you need to be very careful with the disposition of the secret - e.g. in backups, failed disks, san images etc. Compare this with a random session id which expires with the session.

Certainly splitting the key pair (there does not appear to be a requirement for either part to be considered "public") adds some value, particularly if the authentication server is running a different software stack and not exposed on the internet.

But personally I would prefer a SSO server using established protocols (e.g. openam) and a random session id, optionally supplemented by single use tokens in local storage for tin foil hat security.


ssh on port 22 is a well known port.  If you leave port 22 open with ssh running on the internet and check your logs; you may see a couple thousand attempted entries a day (trying a variety of usernames).

knockd does not require a port being open or bound to a process while sshd requires the port being both open and bound to a process.  knockd requires your router to forward packets sent to the specific ports to your server, but a software firewall can either drop (ignore; no response) or reject (send back icmp-port-unreachable or similar) the packets.  Since knockd is just listening to your ethernet interface (and not examining the content of the packets in anything but the most superficial ways), it can detect that packets were sent to these closed ports without doing any additional processing on the packets that then get dropped by the software firewall (e.g., iptables).

So if you define a custom knock with say three ports randomly chosen; you've just added 48 bits of entropy (each port is between 0 and 216-1) before anyone can access your server.  Granted; don't relax your security on sshd; as anyone sniffing traffic can observe your secret port knocking pattern and replay it; at which point they can start trying to attack sshd.


How do I delete secret subkeys correctly?

As explained by Peter Lebbing and Daniel Kahn Gillmor on the mailing list, the answer for gpg 2.2.15 is to ask gpg-agent to delete the secret subkey.

# Obtain the keygrip of the subkey you want to delete.
$ gpg --with-keygrip --list-secret-keys "$YOUR_FINGERRINT"

# Ask gpg-agent to delete the key for you.
# There should be a graphical confirmation prompt.
$ gpg-connect-agent "delete_key $KEYGRIP" /bye

gpg-agent is the program that actually manages the secret keys.
Each secret key corresponds to a file named "$GNUPGHOME"/private-keys-v1.d/"$KEYGRIP".key.
In order to delete a secret subkey, the user must obtain its keygrip and then ask gpg-agent to delete it.

Documentation for the delete_key command:

$ gpg-connect-agent 'help delete_key' /bye
# DELETE_KEY [--force|--stub-only] <hexstring_with_keygrip>
#
# Delete a secret key from the key store.  If --force is used
# and a loopback pinentry is allowed, the agent will not ask
# the user for confirmation.  If --stub-only is used the key will
# only be deleted if it is a reference to a token.
OK

Apparently, there is no way to tell gpg to ask gpg-agent to delete a secret subkey on the user's behalf.
An issue has been opened about this.


Can you trace network attacker by ip address?

Prove ? No. Trace back, possibly. Most likely, a determined adversary who is focused on you may have compromised one or more intermediate systems through which they pivoted their attack to obfuscate their movement. You will likely need to go before a bench to subpoena DHCP / PPPOE logs, server logs from intermediate systems, etc.

Call in a pro forensics team like Mandiant or Verizon, and coordinate with LE. Based on the questions you are asking, this is probably above your grade.


Did I get hit by the recent Java exploit?

If Java is turned off, it is unlikely that a Java exploit could have hit you as it would have first had to exploit the browser in to executing Java despite being off.  It is worth clarifying that Java and JavaScript are not at all related though and verify that it is in fact Java that you have disabled.


How to ensure the third party CDN is secure (and stays secure)?

The security measures you are thinking of already exist. Take a look at this example from jQuery's CDN page:

<script src="http://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>

The notable part is the integrity="sha256-...", which a browser should check against the script to ensure the contents hash to the same value.

This defense is sufficient enough to mitigate your concerns, as an attacker can't modify the CDN script without it being detected. That is, unless you don't trust the website at all and the sha256 itself was placed by an attacker.


This is a pretty standard type of transaction.  By far, the most important thing is that you perform the entire transaction on the server, not on the client; you cannot trust the client.  To make things work nicely for an end-user, you can run these transactions on the client, but they cannot be definitive until the server has verified them.

Also, make sure you perform the whole thing in a database transaction.  If you subtract 10 points from User A, then fail to add them to User B for some reason, User A would be pretty angry if they didn't get their 10 points back; it's even worse if it happens in the other direction, as users can game the system to generate free points.

One thing you may or may not be concerned about are replay attacks.  Imagine that you are on my network and I MitM your connection to the server while you make a transaction to give me 10 points; then, I later resend that same HTTP request several more times to drain your account.  There are a few different countermeasures you can take, but you should be able to lean on TLS to prevent this.

Which reminds me, absolutely all of your traffic that sends a session (or arguably, all traffic period) should go over HTTPS.  This prevents a number of issues, like the above and session hijacking attacks.  You did mention this already, but I figured I should re-iterate it.


Is it a win for an attacker, if they overflow the most recently malloc'd buffer on the heap?

A win for an attacker is a bit of a vague term.

Depending on other safeguards you could possibly fill up memory and overflow the stack. Or you could initialize memory which might be used later with certain values. Or you could just make whatever entry is in this spot too big and make other code fail which relies on its size.

Exploiting usually relies on a careful combination of many things and people find very creative ways to use even the most innocuous errors.

Even overflows by a single byte have been exploited.

Is it a win? Depends on the circumstances. Is it a problem? Definitely.


You can clear an entire event log, but not individual entries.

If you're an administrator on the machine, you can go into Event Viewer and clear the Security log, by right clicking it and going into Properties, then clicking Clear Log. This will remove all logs, then add one entry that states the time and user ID that cleared the log.

Keep in mind that this may not necessarily destroy all traces of the security logs, since remnants of the login event may still exist in other event logs and log files. Furthermore, on systems that belong to a domain, the login logs may be stored on the active directory server as well as the local machine.

For example, the following logs usually contain duplicate evidence of logons, bootup events, or other activity that can be linked back to a username:

Applications and Services » Microsoft » Windows

TerminalServices-LocalSessionManager » Operational
PrintService » Admin
ReadyBoost » Operational
User Profile Service » Operational
Application-Experience » Program-Telemetry
Application-Experience » Program-Compatibility-Assistant
Diagnosis-Scheduled » Operational
Diagnosis-Scripted » Operational
Diagnosis-Scripted » Admin

Windows Logs » Application

Filter by User != SYSTEM and User != N/A, then order by time. Easy to spot events that correlate to specific times.


It has nothing to do with security. Anyone who controls DNS records for a domain name (e.g., bitnik.org) can create any number of A records.  Using dig (which queries DNS records) from my location, I'm getting the same two servers (cloudflare) for anywhere from 3-22 w in a row.

drjimbob:~$ for i in $(seq 3  22); do dig +nocmd $(printf 'w%.0s' $(seq 1 $i)).bitnik.org +nocomments +nostats +noquestion; done
www.bitnik.org.     290 IN  A   162.159.243.12
www.bitnik.org.     290 IN  A   162.159.242.12
wwww.bitnik.org.    290 IN  A   162.159.243.12
wwww.bitnik.org.    290 IN  A   162.159.242.12
wwwww.bitnik.org.   290 IN  A   162.159.243.12
wwwww.bitnik.org.   290 IN  A   162.159.242.12
wwwwww.bitnik.org.  290 IN  A   162.159.242.12
wwwwww.bitnik.org.  290 IN  A   162.159.243.12
wwwwwww.bitnik.org. 290 IN  A   162.159.243.12
wwwwwww.bitnik.org. 290 IN  A   162.159.242.12
wwwwwwww.bitnik.org.    290 IN  A   162.159.242.12
wwwwwwww.bitnik.org.    290 IN  A   162.159.243.12
wwwwwwwww.bitnik.org.   290 IN  A   162.159.242.12
wwwwwwwww.bitnik.org.   290 IN  A   162.159.243.12
wwwwwwwwww.bitnik.org.  290 IN  A   162.159.243.12
wwwwwwwwww.bitnik.org.  290 IN  A   162.159.242.12
wwwwwwwwwww.bitnik.org. 290 IN  A   162.159.243.12
wwwwwwwwwww.bitnik.org. 290 IN  A   162.159.242.12
wwwwwwwwwwww.bitnik.org. 290    IN  A   162.159.242.12
wwwwwwwwwwww.bitnik.org. 290    IN  A   162.159.243.12
wwwwwwwwwwwww.bitnik.org. 290   IN  A   162.159.243.12
wwwwwwwwwwwww.bitnik.org. 290   IN  A   162.159.242.12
wwwwwwwwwwwwww.bitnik.org. 290  IN  A   162.159.242.12
wwwwwwwwwwwwww.bitnik.org. 290  IN  A   162.159.243.12
wwwwwwwwwwwwwww.bitnik.org. 290 IN  A   162.159.242.12
wwwwwwwwwwwwwww.bitnik.org. 290 IN  A   162.159.243.12
wwwwwwwwwwwwwwww.bitnik.org. 290 IN A   162.159.243.12
wwwwwwwwwwwwwwww.bitnik.org. 290 IN A   162.159.242.12
wwwwwwwwwwwwwwwww.bitnik.org. 290 IN    A   162.159.243.12
wwwwwwwwwwwwwwwww.bitnik.org. 290 IN    A   162.159.242.12
wwwwwwwwwwwwwwwwww.bitnik.org. 290 IN   A   162.159.242.12
wwwwwwwwwwwwwwwwww.bitnik.org. 290 IN   A   162.159.243.12
wwwwwwwwwwwwwwwwwww.bitnik.org. 290 IN  A   162.159.243.12
wwwwwwwwwwwwwwwwwww.bitnik.org. 290 IN  A   162.159.242.12
wwwwwwwwwwwwwwwwwwww.bitnik.org. 290 IN A   162.159.242.12
wwwwwwwwwwwwwwwwwwww.bitnik.org. 290 IN A   162.159.243.12
wwwwwwwwwwwwwwwwwwwww.bitnik.org. 290 IN A  162.159.242.12
wwwwwwwwwwwwwwwwwwwww.bitnik.org. 290 IN A  162.159.243.12
wwwwwwwwwwwwwwwwwwwwww.bitnik.org. 290 IN A 162.159.243.12
wwwwwwwwwwwwwwwwwwwwww.bitnik.org. 290 IN A 162.159.242.12

Note the semi confusing command is just a bash loop to run the commands:

dig +nocmd www.bitnik.org +nocomments +nostats +noquestion
dig +nocmd wwwwwwwwwwwwwwwwwwwwww.bitnik.org +nocomments +nostats +noquestion

with all the values from 3 to 22 w's.  Note querying more or fewer w's will result in no record found, SOA (source of authority) is dns.cloudflare.com.

Just someone randomly decided to set it up like that -- why? Who knows. Also, if you make an HTTP request to the root for any of the other domains, you will get a temporary redirect (HTTP: 302 Found) to the one with 22 w's ( http://wwwwwwwwwwwwwwwwwwwwww.bitnik.org/).  See the HTTP response headers, which tells your web browser to make another request at the URL given in the Location line.

jimbob:~$ curl -I www.bitnik.org
HTTP/1.1 302 Found
Server: cloudflare-nginx
Date: Thu, 20 Mar 2014 21:13:47 GMT
Content-Type: text/html; charset=iso-8859-1
Connection: keep-alive
Set-Cookie: __cfduid=d742e5312b8eb7d1ff745449ae453dfc61395350027711; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.bitnik.org; HttpOnly
Location: http://wwwwwwwwwwwwwwwwwwwwww.bitnik.org/
Vary: Accept-Encoding
CF-RAY: 10e4ea69390e01ed-EWR


Yes, you could use a SSL client certificate for this.  Each device would receive its own SSL client certificate.  The device could authenticate to the gateway by connecting over SSL and authenticating using its client cert.  This would allow the gateway to allow access for authorized devices (those devices whose client cert is on an approved list, or those devices who cert is signed by an internal CA set up for this purpose).


Is using OAuth for login less or more secure than maintaining your own passwords?

The idea behind OAuth is that as a service you do not need to know the credentials (yet again) in order to authenticate and personalize the service.

You are correct in that the bearer tokens (part of OAuth 2 in fact) are just as sensitive as username/password. but so is a hash of it.

The idea is that with OAuth 2 you authenticate with the OAuth 2 Server-provider, the server than hands you (or in fact the application your authenticating with) a set of tokens to use.

Bearer token, short lived token to directly use for authenticated requests.
Refresh token, Long lived token to get a new Bearer token.

The OAuth application uses these together with its own preregistered secrets (Application ID and Application Key) and a TLS connection (https) to keep things secure and secret.

The end result is a scheme that is at least as secure as the login scheme of the OAuth service provider,
without having to maintain a new set of credentials and without having to disclose the credentials to the possible 3rd party that is the OAuth client service.
As a bonus there is no requirement for the client to use TLS and still have a secure login
(although I highly recommend TLS for any web-application myself).

And when 'grants' are used it is possible to limit what information the tokens can be used for,
like facebook, google and github show users that authenticate with oauth.

The following image taken from Wikipedia illustrates how oauth works differently than username/password schemes and why it can be advantageous.


Storing all phone call conversation recordings would be infeasible. Phone companies keep logs to bill you from (from, to, time, duration, etc) and within jurisdiction they can be court ordered to disclose such information (to an extent).

With that said it may also be perfectly legal for the restaurant (a participant in the the call) to record all calls for training purposes. I know in Australia it is legal if disclosed at the beginning of the call.

Unless the pranks are violent, sexual or repetitive to an extent of harassment, or to an emergency service (police, fire, medical) I really don't think the police or anyone else in that matter will care enough to follow it up- They hopefully have more important things to worry about.

If you are concerned consult legal advice as recommended by Terry Chia.


Can the router admin page be faked by an attacker?

Yes, this could happen in theory. The webinterface could be faked by the attacker if she manages to get full control over the router (e.g. rewrite firmware), so that your normal DNS server is displayed on the settings page, while in fact a malicious one is actually used. In theory the attacker could also fake the firmware update function, so that you think you update the firmware but the router is in fact still vulnerable.

However, that would be a quite advanced attack that would have to be tailored for the specific router model, and not something I would normally worry about. But if you are feeling suspicious, do a factory reset.

So can the factory reset be tampered with? Possibly on some router models, if the memory where the original state is saved is writeable. Also, some models might not restore the firmware but only settings leaving infected firmware intact. But again, this would be something out of the ordinary and the average home user should loose any sleep over it.


SSL cert for securing on-premises IIS web application

We have a customer, let's call them ABC123 Ltd, who have an existing website on abc123.ie hosted by some hosting provider or other. It's just an informational site with no login\commerce function so currently just runs over HTTP.

Just because it's an information site does not mean it shouldn't be using HTTPS.  There are security and privacy reasons to do so, but there are other reasons as well, including getting referral information from HTTPS pages and not being penalized in Google search results.

  They now want to implement a web application that will be hosted on-premises under IIS. They will be communicating with this web application using an Android app on tablets, via an IP address and port (the customer has a static external IP).

Using an IP makes life more complicated.  As you've seen, it's not a common setup to run TLS without a hostname.  It also reduces operational flexibility - it's much easier to switch traffic to a different server when using DNS, which is something you'd want to do while recovering from a machine failure, or while rolling out a new machine, or doing a canary, or for overriding the app to talk to a development server, or any number of other things.

Since they've already got a domain, they can tack on a subdomain to that if they want, or use a new one for internal traffic.  If you're concerned about making internal IP addresses visible (but not visitable) externally through DNS records, you can add the record only to the LAN DNS server.

Since you control the clients, you may also consider using client certificates to control access to the service.


Why is it okay for Google Authenticator to provide scratch codes?

The idea behind two factor authentication is to use something you know and something you own to authenticate.

In your example you're usually using your normal password (something you know) and your phone (something you own). In the case of backup codes, they should be downloaded once and printed off in case you lose/forget your phone as something you own. However Google allows you to view them again, probably as users were losing them. Ideally a new set of backup codes would be generated in this case.

  If an attacker gains access to them (in addition to your main password
  or key), can't he log in and then reset Authenticator, synchronizing
  it with his own phone to give himself permanent access?

Yes he can which is why a strong password in the first place is a good idea. As Google asks for this when making changes to the way you sign in. If an attacker has stolen your session or is performing a man in the browser attack, they still need your password to make changes. If they have your password it's game over.

  How is using Authenticator for MFA any better than using two fixed
  passwords or using single-factor authentication but appending the
  scratch codes to your original password?

Authenticator is better as it isn't a static password appended together, essentially making it a single factor. Use of one time passwords makes the opportunity for an attacker to use them much smaller. Backup codes are also one time, once you've used one you can't use it again.

So what's the best way of using authenticator?

Don't use backup codes - This reduces flexibility however.
Get a hardware token - As Google Authenticator is just implementing OATH TOTP and HOTP you can get a programmable OATH hardware token. This reduces the attack service further as it's a completely disconnected token, an attacker can't use your phone for authentication.

What about other authentication methods?

Personally I use a Yubikey together with Duo Security Linux Integration for SSH authentication. It works a treat.

You can also use a Yubikey directly with Google Authenticator.

Finally, like most things in life you have to compromise. Some authentication can be really easy to use at the expense of some security, others can be annoyingly difficult to use but are very secure. Try and figure out what matters to you and find the best compromise.


Is hijacking a webcam after visiting a website a plausible threat?

Hi this is a scam that has been doing the rounds for a bit now do not worry about it :)

https://www.cert.govt.nz/businesses-and-individuals/recent-threats/webcam-and-password-blackmail-scam/
https://krebsonsecurity.com/2018/07/sextortion-scam-uses-recipients-hacked-passwords/

What has happened is your credentials were leaked in one of the many breaches that occur and scammers are using this personal information to try and make you believe that have embarrassing content.

If you look up your password on https://haveibeenpwned.com/ you will find a breach. Now what the bad guy has done is find a list of email addresses and credentials and is now emailing trying to make a quick buck with no effort.

My advice is change your credentials and ignore it.


Is ignoring them ok?

No.

Explanation

I'll try to make this simple.  The most restrictive of the two will take precedence.  So, if you have read-only NTFS permissions on a folder inside of a share where you have Full Access share permissions, you'll still only have read-only to that folder inside of the share as the more restrictive of the two (read-only NTFS) will win; vice versa as well.  And it's the same for deny/allow permissions.  Denys always take precedence so remember that.

What To Do

Basically, setting your share to Everyone with full access, and then restricting the actual access to the folders/data inside of the share by using more restrictive NTFS permissions is the way to go.  That is, of course, unless you want to restrict shares even more and only have certain users see the shares, at which point Access-Based Enumeration comes in handy and you'll want to enable it.

What you've set on your example folders above will accomplish what you're looking to accomplish.

See this for more examples and a further in-depth explanation.


Can data be decrypted with the public key if encrypted with the private key?

Looks like public key is not secret. But if I encrypt with private, someone can decrypt with public which is easy accessible. Where is logic?

So let's go the public encrypt -> private decrypt route.  You're seemingly already aware of the use case of this.  Users are able to encrypt things with your public key, that only your private key can decrypt.  This is useful for when say a user on the internet wants to send a message that only you, as the owner of the private key, can decrypt.

This is all well and good, but what purpose does the other direction serve (encrypt w/ private -> decrypt w/ public)?  The answer is, you can help assure that you are a owner of the private key to a corresponding public key when you encrypt a message with your private key, and the public key is able to successfully decrypt and verify the message.  This is the basic idea around Signature Generation and verification.


Is Content Security Policy an approach that is worth to support?

CSP, along with the HTTP cookie secure flag, HSTS, and X-FRAME-OPTIONS, will forever remain my favorite HTTP response headers for improving the security of users for all time.

Also see -- Enabling Browser Security in Web Applications


Are there any addons that disable only some functionality of scripts?

Actually, NoScript provides options for white listing and plugin behavior in the client preferences.

If you click on the NoScript icon in the browser toolbar, you should see a drop down menu link titled "options". Selecting that will open the NoScript preferences pane, and from there you can configure virtually all aspects of the NoScript behavior. In fact, NoScript even offers a tab called "WhiteList" with many common sites included in the default distribution, such as "google.com", "msn.com", etc. So, you should be able to achieve the desired result from within the plugin settings. My testing was done within FireFox (which is included in the TOR browser bundle), but the same features exist in the Chrome version of the plugin too.

With regard to a more relaxed version of NoScript, you could try Web of Trust. It operates like a community managed blacklist.

Now, on to the broader question. First, NoScript can block a lot more than JavaScript, and a lot of people use it as a whitelist to mitigate all the most common client-side threat vectors, including JavaScript, Flash, Silverlight, Java Applets, etc. From the perspective of anonymity, all of those tools could likely be used to aid in identifying you if the web site you're connecting to was specifically targeting TOR users. Also, JavaScript code can be obfuscated to make it more difficult to identify with a simple text-parsing program.

So, as a general security precaution, NoScript can add a lot of value. If the default settings are too paranoid for you, my suggestion would be to configure the NoScript white list preferences to allow JavaScript and possibly plugin content from trusted sources while privately browsing with TOR. This might take a bit of time to setup, but after you have your most common sites whitelisted it shouldn't be too much of a hassle to maintain. As noted by @Curiousguy below, you could further mitigate your risk of MITM attacks by only white listing HTTPS sites to take advantage of the PKI.


how to generate a pem certificate with Openssl using 'TLS1_ECDHE_RSA' ciphers for fips platform

You don't describe exactly why the handshake is failing (error message) but claim that this is because of the certificate. An obvious problem with this certificate is the totally insecure signature algorithm MD5 which is usually not supported with TLS 1.2 clients anymore:

Signature Algorithm: md5WithRSAEncryption

Apart from that the certificate is self-signed, i.e. there is no trust path to a locally trusted certificate at the client.

Issuer: C=US, ST=California, L=SanJose, O=A1, OU=Regression, CN=Regression/emailAddress=regression@networks.com
Subject: C=US, ST=California, L=SanJose, O=A1, OU=Regression, CN=Regression/emailAddress=regression@networks.com

Also, the subject of the certificate does not match the URL which would also result in validation problems.

And finally this is a x509v1 certificate which compared to a x509v3 certificate has no information about usage restrictions, CRL and OCSP URL's, Subject Alternative Names etc.


How can I create a unique identifier that can not easily be reversed?

What you can do is to provide the participants any userID that is easy for them (like their email address, etc.) This userID is stored in a protected database that the analysts have no access to. When an analyst performs queries, the application creates random userIDs that are mapped to the real userIDs temporarily (even just for that session), thereby providing a unique "key" that might be required for typical SQL-like query tasks, but that "key" is decentralized from the real userID mapping. Once the random key is used, it is dumped and never associated with the user again. This creates a "double-blind" reference that will provide some protection.

There is still risk that a determined analyst might be able to pinpoint users due to aggregation issues, but that risk needs to be evaluated based on the type of data the analysts have access to.

The trick will be the application design that prevents analysts from accessing the userID data. That is a db-application level design issue that an architect can help with.


The most common format for hashes on Unix-like systems has the form $ALG$SALT$OUTPUT where ALG is a small number identifying the algorithm, SALT is a salt for the hash and OUTPUT is the output of the hash function. SALT and OUTPUT are encoded in base64.

Algorithm 1 is “MD5 crypt”, a construct based on iterating the MD5 hash function. This algorithm was not (and still isn't, as far as I know) defined by a formal standard. It was introduced by Poul-Henning Kamp in FreeBSD in 1994.

Normal APIs add a salt. The original implementation forced a 48-bit salt. The iteration count is fixed to 2477, which the author benchmarked for 34µs on a high-end PC of the time. Your hash has an empty salt, which is unusual and required the developer or administrator who configured it to bypass the usual tools and probably call a library function directly.

Current Linux systems usually use algorithms 5 and 6, which are based on iterating SHA-256 and SHA-512 respectively. These constructs are broadly based on the same principle as PBKDF2, but compute the iterated hash differently.

You can find a wealth of information about password hash algorithms in the documentation of the passlib library, and of course the library gives you Python implementations. This algorithm is passlib.hash.md5_crypt.


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

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

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

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

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

TL;DR

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


Security Concerns in an Inventory TOTP Scheme using Time-Variant Keys

The security scheme of TOTP states that the secret is a long-term shared secret. The scheme doesn't make any assumption about validity of tokens in cases which are simply not foreseen by the specification. So you are asking for something which is completely outside the scope of what the TOTP concept addresses.It's like asking "if inc on paper was invisible, how would we read?" and the answer is: Inc is not invisible, for a very good purpose.
Maybe you want to ask something different like "how can we make this more secure by changing the long-term shared secret to something more dynamic". If so, please rephrase the question.


How are PCRs Checked and are external TPMs vulnerable to hardware attack

Measurements are taken by software, then extended into the PCRs held by the TPM. The TPM can enforce restrictions on who and when can extend and reset which PCRs (though this is pretty much set in advance, per the table section 3.1 in TPM 1.2 spec part 1). Those PCRs can be read by pretty much any user on the platform, and seen on the LPC bus.

The TPM doesn't perform any validation on PCRs--the measurements extended into PCRs and the order in which they are extended is up to the software performing the measurements.

The TPM uses the PCRs for a variety of lockdown functions (e.g. securing data through a seal or bind operation). When the PCRs are used in this way, the TPM uses its own PCR storage, as opposed to receiving the values over the LPC bus. When PCRs are provided for remote attestation, the PCRs are accompanied by a TPM quote, which is a signature of the PCRs made with a key that only the TPM can use for signing. If PCR values are manipulated in any way, this manipulation can be easily discovered. There are really no opportunities to use spoofed data to gain access to secured data.

If an attacker has access to the LPC bus, a denial of service might be possible by spoofing a locality to extend data into a PCR used to secure data. In most cases, only the expected PCR values can be used to retrieve PCR-secured data. By extending a PCR used for this function, the value would change from the expected value.


Is drive-by-download possible with NoScript?

A drive-by-download can refer to several things.

A download that happens with the user's consent, but they didn't really understand that the consequences.
A download that happens without the user's consent or knowledge

The first method is not very "drive-by" in my opinion, but it is still useful to recognize that this is still possible.

Tricking someone into downloading a file can be as simple as them thinking they are clicking a regular link and then downloading an EXE, PDF, etc. You don't need JS or a plugin to do this, but it helps. A very simple example would be a "popup" (just a piece of html styled with CSS to look like a popup) that says "you have a problem with your computer, click ok to download a fix." Clicking this would initiate the download of an EXE, that the user may or may not run.

The second method is a little more rare, and little more dangerous because it can affect even the computer-savvy user. This often involves some sort of exploit in the browser/OS itself or a plugin (flash, adobe reader, etc). NoScript would prevent any exploit that relied on javascript/plugin that was hosted on a domain that was not whitelisted. So if you whitelisted security.stackexchange, and someone hacked into the server and added malicious JS, then you would not be safe from this. NoScript will also not protect you from any other OS/browser vulnerabilities that do not get blocked by NoScript obviously. Take for example, the Windows Metafile vulnerability. It required no JS/plugin and allowed for arbitrary code execution on the victim's machine.

The basic answer to your question is that, yes, drive-by-download is still possible with noscript installed. Even technically possible with javascript and other plugins disabled. However, keep in mind that it still helps to mitigate the threat.


Difference between SELF XSS and REFLECTED XSS

The self xss is basically social engineering where attacker convinces user to paste code into browser and execute it.
example:-I may ask you to paste a malicious JavaScript code into your browser URL bar which will give you logs about surfing data and look for such random tit-bits from which you will understand the difference between self xss and reflected xss with those logs.you may complain after trying that no results are found,but too late to complain.what I'm actually doing is, hacking your machine,masquerading the procedure to look like your help.

while reflected xss is browser executable within single HTTP response onto victims browser.
They are activated through clicking a malicious link.
Refer details,simple diagrams and example from this nice article(I haven't read it entirely but looks good enough to satisfy the thirst for information):-
https://www.incapsula.com/web-application-security/reflected-xss-attacks.html


What does the pgp public key length depend on?

The "length" is a formal characterization of one of the mathematical values that constitute the key pair. Thus, the public and the private key don't have independent lengths per se; the private/public key pair has a length, which, by extension, is also said to be the length of the public key and of the private key.

The length is not the actual bit length of the encoding of either the public or private key, although there are correlations.

For instance, a RSA key pair consists in the following elements:

A prime integer p
Another private integer q
The "modulus" n which is equal to the product of p and q
The "public exponent" e (a usually small integer, often 65537 by Tradition)
The "private exponent" d (a bigger integer, computed such that e*d = 1 modulo p-1 and also modulo q-1)
The value dp = d mod p-1
The value dq = d mod q-1
The value q-1 which is the inverse of q modulo p

The RSA key length is the size of the modulus n: when we say that the key has length "2048 bits", we really mean that 22047 < n < 22048.

The RSA public key consists in n and e. When encoded, it is thus somewhat bigger (in bits) than n, since it must have room for e as well.

The RSA private key consists in p, q, n, e, d, dp, dq and q-1. Thus, it contains the same n as the public key, and therefore has intrinsically the same "length". (Technically, with only n and d, you can do the same operations, but the other values allow for about four times faster processing, and better resistance to side-channel leakage, which is why the standard RSA private keys contain all eight integer values.)

The key strength is somewhat impacted by the length. When n is too small, it is technologically feasible to recover p and q from n (this is known as integer factorization), at which point all the private key elements can be recomputed. Thus, a larger key (meaning, a longer modulus n) makes for better security, up to some point. Indeed, when the key is so large that integer factorization is completely out of question, now and for the foreseeable future, then the key won't be broken, and increasing its length any further does not practically change the security (there is nothing less breakable than unbreakable). On the other hand, larger keys imply higher costs (storage, network bandwidth, CPU) so you don't want to overdo it. 2048-bit RSA keys are fine for now and the next 30 years as well; beyond that, future is not really "foreseeable".

Key length is not the only factor for security; it must be also properly generated and used. Side-channel attacks are, in practice, a much more plausible attack path than upfront integer factorization.

For other algorithms such as ElGamal or ECDSA, the mathematical objects are of a different nature, but the same concepts apply:

The "length" is that of the key pair and relates to one of the mathematical elements that both public and private key share.
Longer keys mean higher security (up to the point of unbreakability), and higher usage costs.


Is it safe to use virtual machines when examining malware?

Are virtual machines safe for this?  The answer is the same as for a lot of questions of the form "Is X safe?": no, it's not absolutely safe.

As described elsewhere, bugs in the virtual machine or poor configuration can sometimes enable the malware to escape.  So, at least in principle, sophisticated malware might potentially be able to detect that it's running in a VM and (if your VM has a vulnerability or a poor configuration) exploit the vulnerability or misconfiguration to escape from your VM.

Nonetheless, it's pretty good.  Probably most malware that you run across in the field won't have special code to escape from a VM.

And running the malware in a VM is certainly a lot safer than installing it directly onto your everyday work machine!

Probably the biggest issue with analyzing malware samples in a VM is that some malware authors are starting to get smart and are writing their malware so that it can detect when it is run in a VM and shut down when running inside a VM.  That means that you won't be able to analyze the malicious behavior, because it won't behave malicious when it's run inside a VM.

What alternatives are there?  You could set up a sacrificial machine on a local machine, install the malware on there, then wipe it clean.  Such a test network must be set up extremely carefully, to ensure that the malware can't propagate, can't spread to other machines of yours, and can't do any harm to others.

References:

Is it safe to install malware in a VM  (Summary: "There is no simple answer", and there are some risks)
How secure are virtual machines really? False sense of security?  (Summary: there are definitely some risks that could allow malware to escape the VM)
Does a Virtual Machine stop malware from doing harm?  (Summary: there have occasionally been vulnerabilities that has enabled malware to escape the VM)


What happens when you SIM-unlock a cellphone

The phone's manufacturer does some crypto (most likely an obscure and proprietary algorithm) in order to derive a NCK code (unlock code) from the IMEI and presumably a secret key, and that code toggles something in the mobile phone modem to disable a whitelist of allowed networks, so the phone is now considered SIM-unlocked.

For the iPhone, NCK codes were (are?) used as well internally but the process was as the unlock request goes through Apple and the user himself isn't prompted to enter the code. Instead the phone will get it automatically from Apple the next time it's activated (along with the usual stuff it gets during activation like client certificates for notifications and iMessage). Apparently this has changed and SIM-locking is now enforced by the OS rather than by the modem; the allowed networks are now defined in a WildcardTicket, a configuration file received from Apple's servers upon iPhone activation.

I'll leave it to someone more experienced to provide more details and possibly tell which algorithms are used to generate these codes.


Is an HTTP 301 redirect to HTTPS, insecure?

Since you're doing a 301 redirect over HTTP, someone could man-in-the-middle that connection and redirect you anywhere they wanted - in particular they could actually not redirect you at all, and instead get between your computer and https://login.example.com, monitoring your connection and serving you its contents under the name http://login.example.com instead.

A way to mitigate this is to use an HSTS HTTP header - when the user first loads your page, it tells their browser that your site is to be loaded on HTTPS only until some date in the future (the directive typically has an expiration date set in the far future). This means that once the user connects to your site once via HTTPS, they will always do so in the future until the expiration of the HSTS directive.

This leaves one last scenario - say that the attacker MITMs the connection BEFORE the user's browser ever sees the HSTS header from your server. In that case the user's browser never knows that it shouldn't use non-HTTPS connections. A way to mitigate this is to include your website in the HSTS preload list, which means that web browsers ship already knowing that your site is HTTPS-only. Chrome, Firefox, Safari, IE11, and Edge all have an HSTS preload list that includes the Chrome HSTS Preload List, and in a few steps you can submit your site too - more information on the Chrome HSTS Preload List.

If you put your site on the HSTS preload list and complete what that entails, then you can have reasonable assurance that anybody using new versions of those browsers won't be vulnerable to an HTTPS-to-HTTP MITM downgrade attack by a casual attacker.

Just keep in mind that once your site is on the HSTS preload list, it's not very quick to get it back out of everybody's browsers, since any browser that hasn't been upgraded (again) will expect your site to be loaded via HTTPS only.


decrypt .asc file from enigmail not work

You show the output of a key file. Also the name looks like a key ID. So you did not save the encrypted body but a key attachment.


Does API access token that only have access to public information need to be kept secret?

Your question is very specific to the usage of 'Instagram Basic Display API(Long live access token)' which is not just limited to display/access public information of a profile.
You can perform Refresh Access Tokens everyday which leads to DOS attack. (User node and Media node can be accessed only with latest access token). Exceeding Rate limit also leads to DOS attack. You can control entire account if you can get Graph API token :)
Irrespective of it's usage, every API access token to be protected and how to protect is depend on your application architecture. There are many articles listing best practices. Reference-01   Reference-02 Reference-03


Site Executing control characters in title tag

Many vulnerabilities occur as a result of smaller non-exploitable bugs which cause different parts of the software make false assumptions about each other.

Returning user-input in a web applications response obviously suggests the possibility of cross-site scripting (XSS) attacks. These can be eliminated by proper input/output filtering/encoding.

Applying a transformation like parsing the control characters you mentioned can however make your payload slip through the applied protections, for example the following pseudocode:

transform(filter_xss($input))

can result in valid HTML/JS for the following input:

test\x3cscript\x3ealert(1)\x3c/script\x3etest

Multibyte characters can also be useful for exploitation.

Also it seems possible that the user input gets parsed by some kind of command shell that would make more dangerous attacks, namely command injection possible. Based on the operating system you can try different metacharacters to achieve remote code execution, these are some for *nix:

https://web.archive.org/web/20120810003039/https://www.cse.unsw.edu.au/help/doc/primer/node109.html


When LinkedIn was hacked in 2012, nearly 6.5 million password hashes were leaked. Because LinkedIn failed to salt their passwords, it was easy to compute hashes of common English words and combinations, and analyze which were used the most.

I'm not saying this is the only way, but it's one of the possible ways to figure out the "worst used passwords", as you say.


Search Engine security for searches associated with the same searcher

There was a documentary I saw a few months ago on Netflix that told about how Google has data on everyone's searches. They showed an example of some guy who searched for numerous ways to kill his wife. He also searched for a good place to get a sandwich in the middle of his murder searches. So the documentary visits the guy and it turns out he was a writer for a crime tv show. And his wife is very much alive.

It's probably a good idea to assume that nothing you do on the Internet is a secret unless you go to great lengths to make it that way.

(I think the documentary was titled something like "terms and conditions may apply")


Depends on how well written the virus is. (Most of them are pretty badly written!) However, I doubt the writer cares much about the long term survival of the worm once it's grabbed all your email addresses and then mailed itself to them.
It's not the intended vector for infecting other machines, but yes, that would work.
AV tries to intercept the worm before it gets resident in memory (by checking files when written to the disk, scanning attachments in mail, etc.) but once the worm is running the AV is indeed vulnerable to having it's processes attacked, which is why booting from a clean disk (such as a LiveCD) is such a vital part of malware cleanup.


Why doesn't the 802.11 standard implement TLS for wireless handshakes between clients and routers?

SSL relies in TCP/IP. TCP/IP relies on the physical and data link layer to have been established.  WiFi is part of physical and data link layers.  The idea being that you need the lower level links to be established before you can carry on a conversation at the high level.

It's a little like asking why can't a distant person who's only reachable by radio communicate the frequency to listen on in english.  Because to communicate in english, you first have to have a radio link, which means knowing the frequency.


nmap finger print looks alot like shell code and not what's on nmap.org

In some cases, nmap will get data back in response to port probes and be unable to match it to anything in its fingerprint database.  When that happens, it will print the data for you to examine in case that helps you.  Since for many ports and protocols the data received by nmap is binary (e.g., not just ascii), it gets hex encoded as you see above.  Otherwise it would be unreadable and probably make a mess printing to the screen.

The fact that binary data is reduced to \x hex encoding for both binary malicious payloads and binary service response data is due to the fact that they're both binary... nmap's output is not an indication that it's malicious.


Why won't pdf2john extract the password hash of this encrypted pdf? Getting blank results

Does it work when you try to encrypt and crack a PDF yourself?

Here is a rundown on encrypting and cracking it with the tools you described:

Get a sample PDF file sample.pdf.
Encrypt it. I'm using qpdf with the password abc123.

$ qpdf --encrypt abc123 abc123 256 -- sample.pdf sample_encrypted.pdf

Extract the hash.

$ ./pdf2john.pl pdf-sample_encrypted.pdf > pass.john

(I used pdf2john.pl from here.)
Crack the hash.

$ john pass.john
Loaded 1 password hash (PDF [MD5 SHA2 RC4/AES 32/64])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
abc123           (sample_encrypted.pdf)
1g 0:00:00:35 DONE 2/3 (2018-04-12 13:37) 0.02787g/s 585.4p/s 585.4c/s 585.4C/s 123456..franklin

Use the "--show" option to display all of the cracked passwords reliably
Session completed

If it works when you encrypt it following these steps, but not with the file you got, consider that the file may be corrupt or encrypted with an unsupported method. Ask your friend how he encrypted it and try to reproduce it with his approach. Ultimately, without access to the file it's hard to pin down out where exactly you went wrong.


How can apps deal with phone number recycling/reassignment when sending password resets?

These days, phone number reassignment isn't even the largest security concern for apps that use SMS as any part of the authentication process.  This is relatively rare and cannot be used (or at least is very difficult to use) to target a particular victim.  In essence, when it happens it does so accidentally and not maliciously.  While still not good, it could be worse.  In contrast even just using SMS is increasingly being recognized as an insecure security solution even if you don't change your phone number.  There have been an increasing number of high profile attacks that have happened due to weaknesses (of all sorts) around SMS itself.  The short of it is that SMS itself was never really designed with security in mind, and phone companies are very slow to pick up on this fact and more proactively protect their users.  Here are some good reads for examples:

https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

https://www.howtogeek.com/310418/why-you-shouldnt-use-sms-for-two-factor-authentication/

What can you do about this?  Not a whole lot, unfortunately.  Many services come with text-messaging as the default (or even only option) for both 2 factor authentication and password recovery.  When this is the case, there unfortunately isn't much you can do short of complaining or using a different service.

If you're building your own service, and there is anything in the least bit valuable in it (which includes virtually any personal information) then make sure and get up-to-date on best practices for modern security, and make those the default.


Recommendations for a Certificate Management tool for Linux

You may want to try EJBCA. It is free, opensource, graphical, and runs on Linux.

Note that proper certificate management is 95% procedures; software can only get you so far.


Would a recording of a complete GSM session provide a proof of authenticity?

If you mean "prove" in the sense of ensuring that the call is authentic and cannot be reputiadated by the other party then the answer is no.

Cellphone encryption is used only for the over-the-air portion of the call - between the mobile telephone and the base station. A GSM telephone has to authenticate to the base station but there is no guarantee the base station is genuine.


How do programs like keepass protect their data even when it's loaded into RAM?

I believe the answer can be found here, under the 'Process Memory Protection' section.

The first part:

  While KeePass is running, sensitive data (like the hash of the master key and entry passwords) is stored encryptedly in process memory.

This describes the data that is stored in RAM that is encrypted, which it can do, as this data is never displayed in it's raw form to the user.

And the second part relating to your actual passwords and usernames:

  Additionally, KeePass erases all security-critical memory when it's not needed anymore, i.e. it overwrites these memory areas before releasing them (this applies to all security-critical memory, not only the password fields).

This describes that your passwords are not actually encrypted whist in RAM, but are erased and the memory freed as soon as they are no longer required.

It is a little confusing that they say 'In memory protection', because as this documentation proves, this doesn't necessarily mean 'encrypted'.


although @mahbubut-r-aaman mentions it in passing, I thought I'd expand on the bit about SSH.  The answer I'd say for securing FTP is don't use FTP.  The reason being that it (by default) sends usernames and passwords in the clear, which isn't considered a very secure approach.

Instead you could look at SFTP (which uses the SSH protocol) or FTP(S) which uses the FTP protocol with SSL for encryption.

Additionally I'd suggest looking at a solution like fail2ban to help block password guessing attempts.

changing the port that it listens on is a bit helpful in avoiding the noise in your logs of random attacks, but you shouldn't rely on it.

locking down access to specific source IP addresses is a good idea if it's practical as it'll limit who can attempt to access the site.


As a developer, what should I never output to logcat?

Your release build should output nothing to LogCat.

After all, writing information to LogCat adds zero value to the user. While the CPU and battery cost is minimal, minimal is still more than zero, so the cost does not justify the (non-)value. You cannot access the user's LogCat data, except where you are the user (or the user happens to be an Android developer).

As a side benefit, you will not leak private information or security data to LogCat, if you do not log anything to LogCat in your release build.


What's the security risk of using a protocol-relative URL in a CSS stylesheet?

Your question links to a blog post by Paul Irish, which mentions that this is now considered an anti-pattern. (Since 2017)

Why was // used at all?

The reasoning was that you could write //mysite.com/some/resource and it would resolve to either http://mysite.com/some/resource or https://mysite.com/some/resource, depending on whether or not the site was called with HTTP or HTTPS.

Loading HTTP resources when your site is served over HTTPS can be problematic, as browsers usually complain about websites loading mixed content. Notably IE6 would display a big error message, asking you if you were really sure if you want to continue.

So why not redirect everything to HTTPS?

Because back in 2010, when this blog post was made, HTTPS was considered expensive. Not just because Let's Encrypt didn't offer free certificates back then, but because there used to be quite a performance difference between HTTP and HTTPS. These days, this is not the case anymore, and the overhead HTTPS causes is negligible.

What happens if I use //? Is it dangerous?

Not really, but there is also not reason to use it. The recommendation today is to use HTTPS on everything. Really, there is no excuse anymore to offer plain HTTP aside from redirecting to HTTPS. When browsers finally see HTTPS as the default, then there will be no reason for HTTP existing at all.


Calculating entropy of a graphical password (Passface)?

If you have a set of 100 total unique faces and have to choose 5 different faces to represent your passface, then the total number of possible face combinations is 100 x 99 x 98 x 97 x 96, or 9,034,502,400.  Similar to your 100^5 estimate, but slightly less because you can't choose the same face more than once.  Some people would say this represents the possible entropy (e.g. 33 bits) of a passface in this scenario.

But that doesn't seem to be what you're asking.  You seem more interested in the probability of an attacker randomly guessing a passface using the normal authentication system.  If 9 faces are presented for selection then the attacker has a 1 in 9 chance of guessing the correct face.  If they have to choose the correct face from the 9 different presented face choices 5 times in a row then the number of possible choices are the 9^5 you mention, or 59,049.

I'm not sure what you mean by "it's not the same 9 [faces] though".  If you mean each of the 5 grids don't contain the same 'decoy' faces along with 1 valid face then you're correct.  Each of the 5 grids contain a different selection of decoy faces.  But the 9^5 possibilities figure still works.  You can comment or edit your question if you meant something else.


Can CVSS score be different from that calculated from vector

No, it can't.

The score is calculated based on the metrics in accordance to the CVSS specification. There are no custom metrics one could use to adapted the score.

For many issues, there is of course some room for interpretation (mainly regarding attack complexity and the three impact metrics), and I have the feeling that sometimes the metrics may be fudged a bit to get the desired result.

Regarding the separate display and storage: Displaying the score is of course for usability reasons, and storing the score in the database may be done to avoid having to recalculate it each time.


SQL injection using URL query string (web application/php server)

Best practice, server and client-side: always, always sanitise your inputs, outputs, and use prepared statements.

You could look at using a WAF (web application firewall) which will detect attempted SQL attacks etc and offer a layer of protection and also customise responses if they are detected.  Other than stopping an attacker via something like IP blacklisting, if you have an Internet-facing service then there will be malicious actors trying to attack.  To prevent this, you need secure, well-written code, such as prepared statements.


How to store the access token / password reset token in the database?

Since you know that your plaintext tokens are unique (or at least this is a logical inference) you don't need a salt. The salt's intention is solely to provide hash-uniqueness in the case of identical passwords, but since your input space is intended to be guaranteed unique, you don't have this problem.

Additionally, since you have control over the randomness and size of the plaintexts, you don't need to worry about weaker passwords being cracked through traditional means, so bcrypt isn't really necessary to slow down the process. If your input space is large and random, you can just hash it with a strong cryptographic hash (e.g. SHA256) with no salt. This allows you to simply check if H(token) is in the database when generating a new token (uniqueness check).

The process for validating a reset request is then quite simple: take the user ID and the plaintext token (as supplied in the reset link) and check that they match up in the database by computing H(token) again.

Alternatively, if you still want to use bcrypt, you could ensure uniqueness by prepending the random token with the user ID before putting it through bcrypt. This doesn't require you to verify uniqueness (it will always be unique due to the ID prefix) and still allows you to verify the token just fine.


Just adding basic token by POST parameter for securing the API. It is safe?

There are some things to take into consideration:

Using an integer that increments to 1 for every new user is predictable, so IDOR vulnerabilities arise;
Tokens should be of a high randomness and must have a lease time. Consider using JWT for example;
Transfer the data using encryption.

If it is just some kind of experiment, consider hiding your API against nginx balancer with authentication. It is pretty straight-forward to configure basic authentication. In more advanced scenario you may want to use client-side certificates. Check this article for the implementation.

The result defaults will be displaying the entire data if a post has
no parameters

Also consider removing functionality for displaying the entire data.


How to configure routing infrastructure so that the appropriate network traffic gets passed to the honeypot machine (windows xp)

It's a honeypot. Who do you want to catch?

If you want to catch random people scanning your network, put it on your DMZ with a publicly accessible host name. Something juicy like, financial01.yoursite.com.

If you want to catch someone who has already penetrated your network and is poking around, put it behind a router with a bunch of other machines. Again, choose an identity for it that will catch attention -- 100 open ports, maybe?

A honeypot is your way to solicit the attention of bad people. Put it where they will look. Then wait.

Also, read the answers for this question. It discusses a lot of the things you're looking for, and elaborates on how you can protect the rest of your network from all the attention your honeypot will get.


Is it safe to set up IP address to domain name redirection?

From a security point of view, is it safe to redirect an http request for direct IP address to the domain name?

yes, usually it is no problem. if you are in super-paranoid mode you might follow the approach below.

Traffic that goes to the IP directly, even if there are domain names registered, are usually scanners and bots, and maybe, every now and again, a developer. Search engines don't access IPs directly, except when you have no domain names configured.

This is a quite legitimate catch-all setup for nginx that defines a response to any access that is not defined through a virtual-server-conf (it just returns HTTP Status 400):

server {

    listen 80 default_server;

    access_log off;
    error_log off;

    # basically just return an error
    return 400;

}


Data recovery uses

Hardware can send instructions that a PC may be unable to normally
Drives can be cooled to keep them colder, which may help with recovering data from overheating drives
The power supplied to the drive may be isolated from the power for the connected computer, so a dying drive cannot damage the computer

Legal evidence uses

Hardware blockers can be certified so that it can be said that no editing took place
Automatic imaging can speed up downloading large amounts of data
Hashes can be automatically recorded when an image is made, for use in comparisons later
Some forms of malware designed to attack analysts machines can be detected before they do damage


Which protocol should I use for secure message transfers between two servers?

TLS - for sure.
You can use client certificate and choose strong ciphers.
If servers are not limited in trafic - add some entropy data flow inside the socket.
If you wish to transfer two directions - https is not a solution. SIP. Or XMPP. Or WebSocket or any other TCP Socket implementation with TLS support.
In addition to comments:

TLS is well implemented, open source, fast and reliable transport layer protection. So, when we speak about channel encryption, it provides enough security, if to set up both sides properly: strong ciphers, avoid SHA1 and SSLv2/3 usage (Jan 2021 - TLSv1 is dead too).
It is very important not to give to potential attacker a chance to determine any significant part of message for compraison. Modern ciphers can stand against this decryption method. However, I think that it is good style if you mix some random data that can be considered pseudo entropy to the data channel.
As long as you need to communicate between two servers, let's say that data transfer model must be equal on both sides, so each part can act both as client and server, having equal data transfer abilities.
Of course, it will be TCP - needed to guarantee packet receipt. This task data takes one IP packet, so if UDP (DTLS) looses packet, even transfer fact will be lost.
XMPP or SIP: one of servers will be local for SIP or XMPP (I prefer the last) server and remote for another. So, it is additional authentication for data transfering backends. (2021 update) Websocket - nice solution too if you wish to code. Number of frameworks to implement client and server.
As for self signed certificates. If you create correct chain with Root - Intermediate and Server certificates properly signed - both servers can check their validity by adding Root and/or Intermediate certificate to trusted CA list.
Why not https? Trafic can pass operator's proxy and you will never know it. Some proxies use to bump ssl. Moreover, it is public port that for sure has risk of botnets attack. It will be single side communication, where one always is a server and another is a client, where client to server side instructions need to pass additional authentication and web oriented backend. And the last - it is not so fast, cause http is not designed for service data transfer. I would say, that https is good only for low security level data such as session validity confirmation.

I would create an XMPP bot that is reliable, has reach and flexible stanzas set for anything: presence, data transfer and even files transfer. If the system must be extremely paranoid - OTR encryption can be added.
Conclusion: For 1024 symbols messages (1 or few IP packets) TCP as transport protocol to ensure delivery (socket), TLS as transport layer security to simplify implementation, CA signed certificate to avoid MItM. Application layer - SIP / XMPP / WS


Installing SSL on load balancer and the internal IP

If both IPs are answering to the same name, then go ahead and use the same certificate on both.  It doesn't gain you anything to get a second certificate with the same name on it.  There are no security weaknesses introduced by using the same certificate on two IPs on the same server.

The only possible difference is if you ended up needing to revoke and replace one certificate you'll end up revoking/replacing both, but if one cert on your server got compromised, any other certs on that same server are probably suspect too.

Upon re-read, it looks like you're talking about the cert on two separate systems - the load balancer will terminate SSL and pass HTTP back to the actual server?  And the server will have the cert itself to terminate internal connections?

My answer doesn't really change.  The threat environment isn't worsened all that much by you pasting the key into the load balancer over (usually) secure HTTPS, and if the effluent hits the aerator on either system, you don't gain much security or convenience by using different certs.


How should I tell school that they are vulnerable when I wasn't given permission to check?

If there is a teacher or counselor you can trust completely, that you know will keep your name secret even if the school administration starts making threats about firing people, I'd go to them first and talk to them in private. They don't need to understand computers or security (and you don't need to go into detail about the issue), they just need to be trustworthy and good at navigating the administration politics in the school: you need advice about the personalities of the people involved and how dangerous it would be for you to report the issue. If they're at all wary of reporting, then you should keep quiet.

If someone with enough power gets embarrassed, they might start looking for someone to fire or expel (or, in the worst case, to have arrested), to give the illusion that they are in control of the situation. If you're friendly with and trusted by the administration and IT department, and you know they've supported students in the past even when it made them look bad, it may be less risky to share the issue, but I'd still recommend going through a trusted intermediary.

If you can't talk to someone you trust to keep your name anonymous and you can't report the issue anonymously (and it sounds like you can't), it is probably best for you to keep quiet. And that means completely quiet: don't talk about what you found on forums, don't tell your friends what you found, and don't try it out again in a few weeks "to see if it's been fixed:" you don't want to show up in any logs as having anything to do with this, especially if it gets exploited by someone else. It sucks, but start by protecting yourself.


Security web scanner tool for IIS/SQL Server

I'm not quite sure you're looking for a preventative tool or a detective tool.

A SQLI is basically a method to get an app server to send valid sql queries to the database, right?  Pen testing can show you the "how" given the myriad of ways to send queries to be executed by the sql server.  If you're looking for a preventative (and sometimes detective) technologies, a web application firewall and database firewall may fit better than a app test tool (rational, core impact, etc).  A web application firewall usually comes with signatures for a bunch of vuln including different SQL injection methods but some of the advanced products will fingerprint typical request and response data to make sure a valid request doesn't generate a response that's atypical.

A database firewall picks up where the  web app firewall left off and keeps an eye on the actual query and response.

Imperva offers both web and database firewall.  Secerno/Oracle offers a database firewall, but I think it's only for Oracle dbs.  I'm sure there are other vendors that offer a database firewall.


Does a renewed certificate open old messages?

What "opens" (decrypts) a message is not the certificate, but the private key. The certificate contains the public key, which is mathematically linked with the private key, and is used to encrypt messages.

When the certificate is expired, people stop using it; that is, they will stop encrypting new messages with the public key contained in the certificate. But, as long as you keep a copy of your private key, you will be able to decrypt messages which have previously been encrypted and sent to you.

Renewal is the act of obtaining a new certificate from the CA. The CA may include the same public key in the new certificate; or it may require that you generate a new key pair. This is up to the CA and its policies. This does not change the core principle: private keys do not "expire". Expiration is a rather artificial way of invalidating a public key which is cryptographically fine (as Peter Gutmann puts it, the "expiration date" should be called "renewal fee due date").


What considerations should apply for self service Renewing, Revoking, or Unrevoking a certificate?

You are using the expression "zero-knowledge proof" but it does not mean what you believe it to mean.

A ZKP proof is a kind of cryptographic protocol by which a Prover demonstrates to a Verifier a given property on a secret value. The proof is "zero-knowledge" if it does not divulge any extra information to the verifier. For instance, suppose that there is some secret integer x, and a publicly known value gx mod p for known integers p (a big prime) and g. The prover wants to demonstrate his knowledge of x; he could do that by simply showing x to the verifier, but that would divulge x to the verifier, and this would not be "zero-knowledge". The protocol described in the Wikipedia page is a ZK protocol which achieves the desired result.

Thus, a "zero-knowledge proof" is not some weaker kind of proof. It is actually stronger (or at least "better" in that it resists verifier impersonations). You seem to oppose ZKP with a simpler "show-the-password" kind of authentication which you sort of assume to be "stronger" or "more authenticating" in some way. In that you are sorely mistaken. I thus assume that when you are talking about "zero-knowledge", you are in fact thinking about something else which has no actual similarity with what is normally designated by "zero-knowledge".

Certificate renewals may use the same public key than the previous certificate, or a new one. If the same key and name are used, then the operation can be done from the CA side without actually talking to the certificate owner: this is just automatically extending the association between the user's name and his public key.

The revocation system as used in X.509 is in fact equivalent to very short-lived certificates which are automatically renewed on the CA side. In "true X.509" formalism, a user's certificate is really the combination of the certificate itself and a fresh enough CRL or OCSP response, and the CA "renews" the latter on its own accord.

If you renew a certificate with a new, distinct public key, then you need to make sure that the new public key is indeed owned by the user. Some authentication, explicit or implicit, is then required. This can be a show-the-password protocol; this can be a renewal request signed with the previous certificate; there are many possibilities. Risks attached to such a procedure are the same as usual: impersonation by an attacker.

Issuing the new certificate based on a request signed with the previous one makes people nervous, because this means that if an attacker steals the previous private key, he can use it to obtain a new certificate with his own key pair, thus extending arbitrarily his illegal access. This really begs the question of why you are "renewing" and what you really expect out of such an action. In general, a user should want to change his key pair because he no longer has access to the previous one, or it has become too weak with regards to cryptanalytic advances; in that case, the user should be, by definition, authenticated again with something else than his knowledge of the previous private key.

Revocation is an emergency mechanism meant to contain the damage resulting from a potential private key theft. As explained above, revocation and renewal are two facets of the same thing; revocation is equivalent to a refusal to renew. As such, it is supposed to be a rare occurrence, triggered by an abnormal situation. You don't want to make it complex for the user, otherwise they won't report key theft. In particular, don't say or even let it be assumed that revocation is expensive and/or will result in some black mark or otherwise negative reputation attached to the user. Otherwise, nobody will ever report potential key theft, and things will be worse.

The main risk in revocation is thus underreporting. However, overreporting can also be an issue if anybody can trigger the revocation of anybody else's certificate; there is a potential for DoS. The usual trick is to make reporters responsible and to handle massive attacks heuristically:

When a private key theft is reported, make it signed by whoever does the reporting, and keep an audit trail.
If too many thefts are reported in a short time, trigger alarms, wake up sysadmin, and enter crisis management mode.

In any case, if the private key is (potentially) stolen, then all certificates which are still valid at the current date and contain the corresponding public key must be revoked. Expired certificates need not be revoked. That's indeed the point of expiring: to keep revocation information small.

Unrevocations: well, don't do that. It does not work reliably, or at all. You can renew: just do it. You can renew with the same public key if you can come to the conclusion that the private key was not, in fact, stolen. In any case, revocation is an emergency mechanism and we are in inquest mode.

(From your description it seems that you are trying to use revocation as a kind of authorization mechanism. This rarely ends well.)


Does KRACK mean that wifi cafes will never be safe again?

This is based on the false assumption that Wi-Fi cafes were ever safe. That is simply a false assumption.

  So if the client is patched, what if you don't know whether the WAP is or isn't? Doesn't this mean that one can never trust anonymous wifi cafes again, since there's no way to know whether they've patched their WAPs?

Public Wi-Fi is often open (i.e. no encryption) or use a PSK that is distributed to all customers. Not saying there aren't some using WPA2-Enterprise, but I personally haven't seen any.

KRACK creates an opportunity to determine the WPA/WPA2 PTK/GTK so traffic can be decrypted and possibly manipulated by an attacker. If your client is patched, this will significantly limit what the attacker can see or do.

With Open Wi-Fi you have no encryption. With PSK (where the attacker also knows the PSK and can capture the 4-way handshake), you don't have reliable encryption because anyone around has the capability to decrypt your traffic. Either case presents an easy opportunity for an attacker to create a MitM situation. In other words, you are already totally exposed and are not safe in any sense; all before KRACK was ever found or publicized.

The only way that KRACK might make such public Wi-Fi more vulnerable is if the site is using WPA2-Enterprise (i.e. setting up usernames/passwords for clients). But if a site is putting that much effort into providing secure access for customers, then odds are good they will put the effort into patching it as well.

End result though is still the same. Public Wi-Fi shouldn't be considered safe.


How to store banking information,collected on website, securely and implement encryption?

You aren't in scope of PCI for having bank account numbers. You might face other regulatory requirements including general data protection issues depending on your region and business type.

That said, many of PCI requirements make for good guidelines when you are designing and operating an application that handles sensitive data.

So, from the viewpoint of app architecture, you might consider issues like:

putting the database on a separate server, potentially with network boundaries between them
encrypting the data, using a key that isn't stored in the same place as the data; potentially, tokenisation (even if manual)
separating the admin interface from anything accessed by a wider userbase, potentially on a different server, and enforce access restrictions in a reliable way (eg firewall rules)

and so on. The aim being to ensure that a compromise on a widely-available interface (eg public web site) doesn't spread to give full access to the sensitive data in the database.


If my users use Google OAuth for authentication, can I allow 3rd party apps to read data on my site?

You rely on OAuth providers to have users share their identity with you. If you want apps to read info from the users from your database, you effectively have to become an OAuth provider yourself. Your apps should only deal with you and your user identities, not any third party providers that your book club uses.

How this would look if a user signs up and wants to use an app:

user clicks sign in with Twitter
Twitter asks user if it's okay to provide your book club with information
you have the link to Twitter and can create an account, read the tweets, whatever
your user wants to install an app on the book club
they go to the app, the app invokes the same process that you did with Twitter, but with your book club
Book club asks user if it's okay to provide app with information
user agrees and the app has your book club's user info and access token

What if the app wants to enable third party signin via your book club? Well the user has to click "sign in with book club". If they are not signed in, how do they sign in on book club? Right, by using Twitter, Facebook, etc. Effectively you are chaining different auth providers. But two steps should still be manageable for a user.


AES CBC over TCP - when is new IV needed

There are three points to be made, I think:

Do not build your own protocols ! Or, at least, do not believe the result to be secure. Otherwise, stick to well-studied protocols, like SSL. If your goal is to learn, then go on.
In CBC, the IV (or previous block) must be unpredictible for the attacker. Consider SSL, where data is split into records (that's your "messages"). Each record is sent atomically. In SSL 3.0 and TLS 1.0, the last block of a record is also the IV for the next record; this means that an attacker observing the stream and being able to input some data of his own in the cleartext stream can observe a record, learn the IV for the next record, and then compute the cleartext data he wants to insert in the next record. That's the basis for the BEAST attack which was published last year for SSL (actually an older attack, but NEAST is about make it plausible in HTTPS context). So, to sum up: you must choose a new, random IV (with a cryptographically strong generator) whenever you are about to encrypt plaintext data which was obtained after having sent over the wire the previous encrypted block.
You need an integrity check; otherwise, an attacker could modify your messages, and beside the obvious problem of using corrupted data, this can endanger their confidentiality as well. Do yourself a favour and use an encryption mode which includes integrity, e.g. EAX. This makes the problem quite simpler:

The IV need no longer to be unpredictible, only non-repeating. A simple counter will do.
You need a new IV whenever you start a new message.
By construction, the receiver cannot process a message without having received it completely (because its contents cannot be trusted until the integrity has been checked). So your incentive for breaking data into messages is to limit RAM usage on the receiver; and you need to close the current message whenever you want to "flush" the data.

The old-style way to add integrity is to use an independent MAC construction (such as HMAC) but combining symmetric encryption and a MAC can be tricky (see this question for details) so you'd better use EAX (or something equivalent like GCM).


Common Encryption types with keys stored in Base64

Encryption is a mathematical operation which scrambles your readable data into unreadable data. To make the resultant ciphertexts less predictable, algorithms have to ensure that the entropy is high.

In other words, if you take a large plaintext sample - for example a wikipedia article, the number of occurrences of 't' and 'e' would be considerably high and that of non- printable characters would be  almost nil. If a substitution cipher (a for c e for b etc. Caesar ciphers, rot13 etc. ) is used an attacker can use this knowledge to retrieve plaintext from ciphertext.

The outputs of modern ciphers such as AES would be so random such that there is no one to one character mapping possible. This can be cumbersome when your application has to handle it as a string. So they encode the ciphertext to base64 strings - to make it printable.

In other words, just because the ciphertext or key is encoded in base64 you wont be able to predict the cipher suite.


How do I share secret key files with Docker containers following 12 Factor App?

12 factor says that the config needs to be stored in the environment. So why not simply pass the secrets to the container over environment variables? If there are many, pass a master key to a key store that is lying on a volume mounted at start.


Is an improperly configured HTTPS site inherently more dangerous than plain HTTP?

An improper TLS connection could be a positive signal that a middleman is interfering with the connection.

Imagine if you got a letter supposedly from a friend, but then at the end it was signed with someone else's name. If the letter wasn't signed, you probably would have trusted the letter, but the fact that it has someone else's signature is extremely worrying.


Would putting important information on a flash drive that never touches the internet be secure?

The technical answer is yes, as long as nobody just steals the USB flash drive. You can mitigate that with full-disk encryption, but I don't think people breaking into your house are going to be looking for your SSN anyway - they're much more interested in taking the most expensive objects they can carry out by hand and easily fence.
One issue with storing this information on USB flash disks is that they have poor retention. They're not particularly reliable for long-term backup storage, and you should expect some degradation in the data after a year or two.
For something as not-that-sensitive as your SSN, I would recommend just storing it in your password manager. A local one like KeePass offers plenty of security. You should be using one anyway for your passwords.


sanitizing input/output in php/codeigniter

I recommend reading through the resources that OWASP has available.  This is a totally standard subject, and there's a lot written on it.

Make sure you do the input validation on the server.  Don't trust the client to do input validation, since the client can be bypassed.

Input validation: The nature of input validation you do depends upon the type and expected range of possible values for the field.  Usually you'll end up constructing a whitelist of allowed characters and checking that the input contains only those characters; or writing a regexp that characterizes valid inputs and checking against the regexp.  This will likely be different for each input, because it needs to depend upon the type and expected range of values for that input.

You should combine input validation with output escaping.  The proper form of output escaping depends upon where the data is being inserted into the output.  For example, if you are interpolating data into a HTML document in between tags, then use htmlspecialchars to escape the data before inserting it into the HTML document (to prevent cross-site scripting).  On the other hand, if you are inserting a URL, you also need to check that it uses one of a whitelisted set of protocols (e.g., http:, https:; but not javascript:).