Is prior work experience in development or other fields required to break into and acquire advanced knowledge of penetration testing?

sounds like it is time to write your tools. The gap between insecure by design and real world hacking lies in automating how you perform your manual attacks. gl.


Strictly speaking, you cannot measure the entropy of a password. (Or if you like, you can measure it, but the value is 0.) There is no entropy in a password: the entropy is in the way the password is generated.

This is explained in the xkcd comic: “correct horse battery staple” is just one example, what the password illustrates is the procedure to generate that password. Namely: “four random common words”. The next panel gives the quantification “44 bits of entropy”, which is based on 11 bits per word (i.e. choose each word randomly among 211 = 2028 words). That password generation procedure has 44 bits of entropy, which means that on average, an attacker who knows how the password was generated will need to make 243 guesses to find the password. (On average, the attacker needs to enumerate half the password space.)

The comic does not recommend that you pick “correct horse battery staple” as your password. It recommends that you select 4 random words. The pattern is known, but not the random choices. Diceware is a popular variant of this method: you pick words on a list of 65 words by rolling five dice for each word.

To put it yet another way: there are two aspects in choosing a password, the randomness and the cleverness. The method is cleverness and does not contribute to the security of the password. The randomness makes the password secure, regardless of any cleverness. Cleverness is only useful to make the password easier to type and remember. If you're clever, you only get protection against attackers who are less clever than you.

A method like “pick random words” is easy to quantify because as long as the random choices are independent, the entropy adds up. If you add constraints (e.g. generate something and “smooth it out” to make it memorable), you need to count the number of possibilities that remain and take care if the smoothing can map several different random rolls to the same final password.

Yes, there are tools to check the strength of a password. They come in two kinds. The fast ones apply some heuristics. They don't always get it right, because they have no idea how the password was generated; they tend to favor passwords with clever bits over passwords with randomness. Since they see only the final result and not the generation method, they cannot take randomness into account. For example (picked at random — not in the cryptographic sense) passwordmeter.com tells me that “correcthorsebatterystaple” is weak (25%) and “homechasebogbigamy” (which I just generated randomly with the XKCD procedure) is very weak (19%). Yet if I'd only told you how I'd generated that second password and not what the random choice was, it would take 1000 computers about 3 year to find at 100 attempts/second/computer! In contrast, pass+word1! is rated strong (64%).

The second kind of password strength checker is… cracking software. This gives you the perfect measure of your password against that same cracking software. It doesn't tell you much about other cracking software.

The best way to ensure that your password is secure is to measure the amount of randomness that goes into it. N bits of randomness = 2N-1 guesses needed on average to crack it. Figure out how much you want 2N-1 to be and deduce N.

Exercise: to generate “homechasebogbigamy”, I used a list of 4172 distinct words in alphabetical order and generated each word by taking a random word among the first 2048. Assume that list is public. Does the fact that the list was sorted alphabetically reduce the entropy of the password? Is my claim that this procedure has 44 bits of entropy correct?


Is sending IP Address as a parameter with a POST request from a client to a rails server safe?

There's no utility on sending IP address of local device, on which you app is running. There're good chances that you'll get only local ip-address from the device, which is hardly useful. Moreover, in the days of dynamic public IP address assignment from ISPs, IP addresses are hardly used for monitoring or tracking purpose(As there're good chances that public IP address assigned to you by your ISP, may be assigned to some other computer, at another time).


How do I produce a CA signed public key?

Signing a public key is effectively a certificate. These are the steps I take to produce a public key certificate I can distribute to other so that they may communicate securely with me:

Setup

Generate the private Keys:

  openssl genrsa -out private.pem 2048

Generate the public keys:

  openssl rsa -in private.pem -outform PEM -pubout -out public.pem

Create a CSR (Certificate Signing Request)

  openssl req -new -key private.pem -out certificate.csr

Create a Self-signed certificate (you can share this certificate)

  openssl x509 -req -days 365 -in certificate.csr -signkey private.pem -out certificate.crt

Encrypting

  openssl rsautl -encrypt -inkey private.pem -keyform PEM -in data > encrypted_data

Decrypting

Extract the Public Key from the Certificates

  openssl x509 -pubkey -noout -in certificate.crt > certpubkey.pem

Decrypt the data

  openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data > data

If you intend on having your key signed by a CA you'll have to send your CSR file (and some cash) to your CA of choice, they'll give you have the certificate you can use instead of the self-signed cert I mentioned in the steps above.


Windows language pack update with a gibberish name

The official communication from Microsoft at this time:

  “We incorrectly published a test update and are in the process of removing it.“ – a Microsoft spokesperson

I won't add commentary, but will update the answer as more information becomes available.


Is it correct to consider Task Based Access Control as a type of RBAC?

There are some non-canonical (or non-"standard") access control models (besides the well-known MAC, DAC, RBAC...), that are simply not well defined.
As in, anyone can define or redefine them as they want, as long as the model makes sense.

E.g. this post was the first time I heard that model called "Task based access control", though I use/employ/review it a lot. Strangely, that book you linked to was the second time, in a different meaning...

I will point out that in many/most cases that use the model you called TBAC, it is aggregated back up into roles.
That is, the access is granted based on a task, but the access check then compares this task to roles that contain that task, and users that are part of one of those roles.
In other words, tasks can be seen as "sub-roles" - or if its easier, roles become role-containers, and the tasks are the real roles...
See e.g. Microsoft's AzMan tool.

Clearly, this is a huge improvement on straight RBAC, since it gives you some granularity and dynamics to play with, but it's still a form of (extended) RBAC.
Btw, I've also seen this called "Hierarchical RBAC", so...


First of all, you need to disable SSLv3 on your browser, to prevent POODLE attack (SSL3 "POODLE" Vulnerability)

Then, there's no issue using HTTPS even in "not safe" areas, because TLS protect you from Man In The Middle attack, with handshake, end-to-end encryption and Certificate Chain verfication.

One common problem you could encounter, is SSL stripping: the proxy you are connected to can force you to communicate with HTTP only, giving it everything in clear text and then simulate an HTTPS connection with your targeted site. HSTS may prevent such downgrade attack, but it's not widespread actually and presents some limitations with initial requests.


How to get the statistics of users opening the attachment in a phishing mail during a social engineering campaign test?

Not really possible but I will give you some alternatives I can think about:

Instead of attaching the email send a link and say something like "To open the document click here" and here is a link and then track how many people clicked it.
Add a very small white image that will sit on your server and when the email loaded the image will be requested and then count the requests.
As said in the comments:

  What you can do is creating a pseudo-malicious file that only connects back as to count for execution. Especially, since saving a file to disk does not constitute a problem with awareness

These are some of the ideas I have on the top of my head.


What parties have access to the *full* requested URL of a website accessed via the HTTPS protocol?

Only the TLS endpoints1 can read the the full URL because HTTPS provides end-to-end encryption.

HTTPS wraps the full HTTP protocol, including the request line, request/response body and all the headers. The request URL is just one part of HTTP that gets encrypted together with all the other components. If any party was able to read the URL, they would naturally also have access the full HTTP traffic.

Just to be clear, there are still a lot of ways the URL might be inadvertently disclosed:

When moving away from a site by clicking a link, your browser will by default send a Referer header containing the previous URL - which is therefore disclosed to the site you're browsing to.
Browser plugins might send your visited URLs somewhere for analysis or to sell them.
Security products or corporate firewalls that do "legitimate" HTTPS interception (implying you actively installed and trusted their root certificate) could read your HTTP traffic and thereby learn the URL.
The host of the target site (but not the full URL) would routinely be disclosed to a potential eavesdropper due to HTTPS SNI and the client's DNS query.

But assuming a correct setup without any side channel leaks, the request URL just goes through the TLS tunnel like everything else that's transmitted.

1In your example, these are most likely the local device (1.) and the destination host (12.). As @Bob points out, the TLS connection could also end at a load balancer or some other form of proxy.


Security for a low latency online multiplayer game

To the extent that I understand what you are proposing, I'm concerned this is not a great design.  It feels like it might be more complex than necessarily.  I'm concerned by any design that has the server knowing the client's private keys; feels like an unnecessary risk.  The use of "obfuscation keys", XOR ciphers, and the like raises red flags.  For these reasons, I would have concerns about its safety.

I'm wondering if there is a simpler solution.  My recommendation would be: check out Datagram Transport Layer Security (DTLS).  DTLS is a variant of TLS designed especially for datagram protocols, like UDP.  It is designed to work well even in the presence of dropped and re-ordered packets.  DTLS is reasonably well-vetted.  Using an accepted, published, well-vetted scheme is much safer (and much cheaper) than designing your own.  Therefore, if DTLS meets your needs, it seems like it would be a great solution.

If it doesn't meet your needs, come back and let us know what requirements it does not meet, and we may be able to make some other suggestion.


Why I am getting logs from Class E IP addresses (Research - Reserved), and my IPS being blocked with threat name "IP Address Spoofed"

Scanning into your boundary devices from the public internet from unknown IP’s is normal behaviour. Everyone from government agencies, research and education institutes to the bad guys looking to do harm are continually scanning the internet for a variety of reasons.

If your boundary devices or alerting devices such as your IDS/IPS are fagging this up, it is up to you have you manage it. You can either allow them to continue to alert you or you can tune it out once you have deemed it to be benign.

In my experience it is typical for denied connections on boundary devices to be tuned out of alerting tools such as SIEM or IDS/IPS.

If it isn’t benign, then you will want/need to take the appropriate remediative action as per your incident response plan. So for example; If IP’s within your network are being scanned from the public internet, then your IPS is doing its job correctly by alerting you are potential threat, a threat that you should investigate and take action on if needed.


Is it feasible to use DNS query packets as a reflection tool in public WiFi environments?

If you are spoofing an IP address that is outside the range of valid IP addresses in the subnet:

Ever since the plague of spoofed IP address attacks in the 1990s and early 2000s, the best current practice is to configure routers to block IP packets with source addresses that are not supposed to arrive through the interface through which they came. The hotspot or an upstream ISP router is probably applying such filtering.

If you are spoofing an IP address that is inside the range of valid IP addresses in the subnet:

Then the above BCP38 does not apply, but it is perfectly plausible for the hotspot to be keeping track of which IP addresses have been assigned to which MAC addresses by its integrated DHCP server and enforce a policy that only MAC addresses that have gone through the DHCP process are allowed to transfer (non-DHCP) traffic and then only using the IP addresses that they were assigned.


How dangerous is disclosing a table's structure to users?

What you are referring to is potentially an error-based SQLi vulnerability, which falls under a larger category known as In-band/Classic SQL injection. Essentially, these vulnerabilities allow an attacker to both launch an attack as well as gather information about the database from the same communication channel. I say it is only a potential vulnerability because we are not sure if you've actually tried SQLi, rather you've just discovered an error. This can be confirmed via testing, assuming permission.

The error-based SQLi vulnerability you are potentially seeing provides information about database structure (as you've pointed out) which aids in enumeration of the database (potentially the entire database) for the attacker.

It's saying, "Hello friendly internet user who I have no reason to mistrust, the query you are trying to perform (with obviously no malicious intent) is unfortunately incorrect, so here is the exact structure of my database so that your next query can be more appropriately written to achieve success!"

Such a verbose error message should be disabled on a live site or logged to a file with restricted access. A better practice would be to, depending on the situation, provide the user with either a 400 or 500 error while being cognizant to not provide more information than is absolutely necessary.


Linux security modules (LSM) and reference monitor implementation

I've found out by myself.
By default, so without an activated LSM, Linux uses a discretionary access control (DAC) model, as the user (e.g. john or even root) decide by his own whom access is granted.
On the other side, those LSMs (like SELinux or AppArmor) can be activated and configured.
They are managed by an "outside" party, like an organizational administrator, which is not part of the OS users.
This administrative entity specifies access policies, which overpower the DAC ones. This is implemented by the Linux kernel hooks, which are triggered for certain events like file open or write and are then evaluated.
The resulting access control mechanism is dependent on the the particular LSM implementation. So in case of SELinux it is MAC (as an administrative entity specifies mandatory policies).


Is accepting an invalid credit card number a security issue?

Should I report this as a security issue or will it come under fraud management?

There may be a business risk issue, which you can document under security, but how significant it is depends on the business.

You say the web site

  accepts ... credit card numbers for reservations.

What are those reservations for?

If it's a hotel room, then there is limited potential for fraud, since the actual card would be required at check-in time.  An attacker could attempt to impact service by blocking off rooms with bogus cards, thus reducing the pool legitimate visitors could reserve, but I see that as a minor concern based on scalability and sustainability issues.

If it's a game store that is purchasing stock based on pre-order reservations, then the store is extending actual capital to stock games they might then be stuck without buyers for.  This sort of business is more threatened by invalid card reservations, because they're sinking real dollars into the expected sales those reservations indicate.

There are other businesses where 'reservations' are largely meaningless, a way to encourage engagement by the customer at no real cost.  In these cases, the business impact is negligible.

  The interesting thing is they do CC validation if the currency is USD,
  but not for any other currencies.

And that may be reflective of business risk acceptance.  If 99% of their reservations are in USD, then the risk of accepting invalid non-USD card reservations may be negligible.  If implementing non-USD validation has any specific cost to it (fees from processor?  coding time to handle if-then-else branches?) then it's a legitimate option to leave it out at 1% coverage.


Is a certificate's thumbprint considered private?

No, thumbprint is not considered private. This is because, thumbprint is a result of one-way hashing function (SHA1 or other).

By definition, hashing functions accepts messages of variable length as input and produce fixed-length output. Output length depends on actual hashing function. As the result, it is impossible to recover input message by knowing only it's hash (thumbprint). So, you can post thumbprint value in public when necessary without worrying that someone will recover input message that produced specified thumbprint.


Suspicious phone call claiming MS Office not updated lately

Those attacks are becaming common. They usually call people telling the computer is infected, Windows' license expired, or any other "problem". They end up installing software on your computer, sending a huge bill for remote support or steal credit card information.

Using your machine as a DDoS bot is too much trouble for this kind of attack. They usually get money easier just stealing your credit card info or encrypting your data and asking a ransom.


Do I need to salt PBKDF2 when it's used for AES encryption

Absolutely! It's even right there in the PKCS #5 v2.0

  A salt in password-based cryptography has traditionally served the
  purpose of producing a large set of keys corresponding to a given
  password, among which one is selected at random according to the salt.

By using a secure salt, password p1 = tomato will not produce the same key as p2 = tomato even though they're the same password. This has two benefits:

Protection against rainbow tables.
Only one password can be attacked at a time. The same computational effort can't be utilized to "reverse" more than one password.


Is it safe to email the contents of your .htaccess?

There may be harm in divulging your .htaccess file. This is usually one of the reasons why there's a rule to block access to .htaccess, like this:

<Files .htaccess>
Order Allow,Deny
Deny from all
</Files>

The contents of this file may tell users about your configuration, such as where passwords, certificates, and so on reside in the system, and how various physical directories map to virtual directories, etc. It can expose more about your system then you'd like a typical person to know, and definitely more than you'd like an adversary to know just given to them on a silver platter.

While there's technically no harm from the file itself (as long as users can't modify the version on the server), the .htaccess may give malicious individuals information on how your system might be vulnerable. Do feel free to share this file with people you trust if you need help with it. Sending it by email is still safer than using a public forum if viewers might be able to associate the file with your domain/server, but I'd recommend physically delivering it (in person!) on portable media if it's reasonable to do so (e.g. sharing it with a colleague you see at work every day).


Network abnormally slow during night hours

Change the password of your AP
Read the logs of your IP to see who's authenticated at those periods in time
Check your servers logs (is it generating traffic maybe?)
use tshark/wireshark on your server to analyze, use graphing tools like munin and cacti to determine the amount of traffic
If all of the above don't work check with your ISP


Is it OK to pass credentials to the client to allow it to upload files to Amazon S3?

The preferred way to go is to generate a presigned POST request (your backend server asks for it with your own admin credentials).

Then from client-side you upload using this pre-signed POST.

It's effectively a way to have temporary credentials, but much more easy & secure to deploy as it can be restricted to the exact file you need to have uploaded.

Here is the link if you use the Ruby SDK (https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/S3/PresignedPost.html) and you will easily find that for the SDK you use.

Edit: As per comment, link to official AWS doc: https://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrlUploadObject.html


How to ensure authenticity and integrity of a directory

Rather than designing such a system yourself, you might want to take advantage of an existing File Integrity checker such as Aide:

  Aide creates a database from your filesystem and stores various file
  attributes like permissions, inode number, user, group, file size,
  mtime and ctime, atime, growing size, number of links and link name.
  When someone make changes in filesystem, then Aide compare the
  database against the real status of the system and report it to you.

You can configure it to watch the specific files and directories you care about, and notify you of changes.

For the Mac, Aide can be installed with Brew.


Is MAC address filtering effective on a wifi router?

MAC address filtering is a very weak form of wifi protection:

the MAC addresses of your devices can be easily eavesdropped with tools like wireshark
the MAC addresses of their devices can be easily changed (OS dependent, but typically an option in Network Settings).
MAC address filtering is annoying to maintain.  You have to login to your router configuration every time a new device connects, find the MAC address in the settings of the new device, type in 12 seemingly-random hexadecimal digits (or copy from the logs of connection attempts), and still tell the new device the new strong wifi password.

To secure your wifi, make sure you use WPA2 with a strong passphrase (e.g., 6-8 random words) with WPS (Wifi Protected Setup) disabled (WPS is broken).  You should also check that your router doesn't have any known backdoors.

The strong high-entropy password is extremely important.  Wifi passwords can be cracked in offline attacks after capturing a handshake, at a rate of trying millions to billions of passwords per second.  However, 8 words randomly taken from a dictionary with 10000=104 words, means there are 1032 passwords the attacker would have to try (assuming the attacker knew that's how you choose passwords -- the rate will be worse if they don't know this).  At a rate of a billion passwords per second per computer with a million computers, it would take more than a billion years to crack an 8 random word password.  (Note picking a well known quote/phrase is much much weaker even if it is 8 words long.)  A passphrase of six random words would have 1024 (e.g., with a million computers doing a billion passphrases per second it would take only 31 years to break).  Note a four-word passphrase only has 1016 so a single computer doing a billion passphrases per second would take about a month or two to break it.  A three-word passphrase can be broke by a single computer in under 20 minutes.

Note, if you choose to go the random characters route, if you choose characters randomly from uppercase+lowercase+numbers, then a three-word passphrase is about equal to a 7 character password, a four-word passphrase is about equal to a 9-character password, a six-word passphrase is about equal to a 13 character password, and a eight-word passphrase is about equal to an 18 character password.


Is it fine to store single-use beta keys plain-text?

In your question you have identified a potential threat. If you think this threat is real and it would have a sufficiently negative impact on your operations if it were exploited, you should take additional measures as you suggest in your question.

If you are saying the keys in this case are unique identifiers which you do not want exposed, you may need to employ hashing and encryption as needed. If you need to store the keys and need to use the same DB to assign them, you cannot hash them since you would have no way to reverse them in order to hand them out. You would need to encrypt them.

Does the benefit of pre-generation outweigh the risk of having them compromised and the cost of creating keys on the fly? It may make more sense to create them on demand and look at solutions for email verification tokens and how they are managed since it seems you are doing something similar.


Could access to the WHOIS contact methods for a domain name provide any form of access or leverage to the domain?

Note that public whois data may get a good bit scarcer because of GPDR.

Email, fax, SMS, mail, or phone to a whois contact are some of the ways a Certificate Authority can validate the right to obtain a cert according to https://www.cabforum.com Baseline Requirements 3.2.2.4. Thus, unless the legitimate owner has set a CAA record to only the CA(s) it actually uses (who can recognize you as a fake) (and you haven't compromised the logins to such CA(s)), you may be able to get a fraudulent cert for (or under) the domain name.

If you are also able to divert or intercept traffic to that domain name (e.g. DNS poisoning, BGP 'mistakes', ARP spoofing, etc.), and the legitimate owner/site hasn't set HPKP or DANE, using this cert you could impersonate the site.

... except to users who do extra cert checking manually or with a browser extension or similar, and probably many(?) of those users read this Stack and are already on to you :-)


Seamless authentication from an iPad to several enterprise apps - what are the options?

Some ideas:

For web apps, use SAML SSO. They will need to login to one web app, then other logins will be seamless. There's also OpenID and OAuth which do similar things.
For mobile apps, you could have the user just login once when they install the app, and have a long-lived session token.
You could use client certificates. A pretty decent solution, although not widely used.
iOS has "login with Facebook" pretty well integrated with the OS. It may be possible to plugin custom authentication (or even use Facebook)

In fact this link look good!


Does any malware target Tails? The most literal answer has to be yes, because I have written malware for Tails (it requires manual installation as root, but it is still technically malware). I'm sure other people have as well. I have not come across any malware targeted specifically for Tails in the wild, though.

You also have to take into account the fact that Tails is just highly customized Debian, which itself is just GNU/Linux, so the question becomes "Is there any malware which targets GNU/Linux, which is compatible with Tails out of the box?". For example, the "torsploit" attack which exploited an outdated version of Tor Browser may have been able to attack Tails, however the Tails firewall was able to block it. It simply was not compatible with Tails, because it was designed for a generic system without all of the protections Tails had in place. Does this mean that this malware hit Tails? Yes. Does it mean it succeeded in its goal to call home and deanonymize the user? No.

In general, there will likely be little general-purpose malware which is effective against Tails. If you are foolish enough to run a Perl botnet script, you may see your Tails machine connecting to a malicious IRC network to participate in a DDoS. However, it is still possible to target malware toward Tails. The attacker may have to chain a number of 0days, or may have to exploit a number of known bugs in a clever way, but it's certainly possible.

My educated guess is yes, there is malware designed by state-level adversaries which specifically targets Tails, most likely deployed in combination with a warrant and used sparingly against high value targets. Most likely it involves either social engineering, or targeting outdated versions of the operating system.


Zero Knowledge Proof of ownership of an email address

Ideally, you would have example.com provide a protocol to authenticate the users (such as OAuth2, as suggested above). Or simply a "registration password" that is available at some example.com intranet.
Lacking that ability, you would probably want some kind of blind signature. Ideally through a third party. Probably that could use a system similar to the old Mozilla Persona
Adding a trusted intermediary would solve the issue, although you are mostly replacing the platform being malicious with the intermediary being malicious and colliding with the (evil) platform.
An interesting solution would be to (ab)use DKIM signatures. We might assume that all our customers will sign outgoing mail (this will not be the case, but it ubiquitous enough to be a reasonable restriction). On registration, the website provides a token and requests to receive an email at finishregistration@website.com which is DKIM-signed by an example.com key with such token in the subject field.
On validation, it checks that the message indeed passes DKIM for a key by example.com, and then processes the token as usual with url links. For nerdy enough clients, you could allow them to upload the DKIM signed source email, so they can actually verify what they are sending.
The hard part here is that the From: field will contain the email address,¹ so you would need to instruct the users how send an email spoofing an empty sender, accept that people could send you the email with the from: field revealing their identity (maybe they won't care?) or provide a program which can do that on their behalf (so that in order not to give you their email address, they execute an untrusted binary of your choice, to which they provide their email credentials…). Plus, the server itself which shall sign them, may reject/"fixup" a spoofed/empty From:, or include the sender identity somewhere else inside the headers.
¹ and probably the full name, not to mention people that would not removing their email signature full of PII.


What is the difference between Vulnerability Assessment and Ethical Hacking?

A vulnerability assessment is a passive analysis of the current security measures in place. This would involve simply looking at systems and seeing if they meet certain criteria.

Ethical Hacking is a form of offensive and active security where deliberate attempts are being made to exploit vulnerabilities in systems to highlight security issues.

Long story short, one is passive, one is active.


JSON Web Tokens (JWT) as user identification and authentication tokens

Your basic approach is valid: generate the JWT when the user logs in, expect subsequent messages to carry the JWT, trust the subject field in the JWT in those subsequent messages if the JWT is valid. But there are several things you should be aware of:

As Daisetsu say, you could use a MAC ("alg":"HS256") as MACs are specifically designed to prevent alteration of the payload, while encryption algorithms typically (counter-intuitively) are not. However since you're specifically using AES in GCM mode, you already get tamper-resistant encryption ("authenticated encryption"), so that's not really a concern.
When validating an incoming JWT, be careful what you consider valid. For example, I could call your service with {"sub":"me","alg":"none"} and while that JWT is valid in some sense, it isn't something you want to accept.
Since JWT is a draft, not a standard yet, it might change. If it changes enough, the library you're using might have to change in ways that break compatibility with your code.
If you can't store any server-side state, you have no way to invalidate the JWT when the user logs out. In effect your service has no logout function, which may be a security problem especially if you set the expiration time too far in the future.
If you set the expiration time too soon, you may have a problem with users still being logged in but not having a valid JWT. This may lead to awkward error-handling and user workflow issues.

Since you said your server has no access to a database, I assume the actual login is handled somewhere else, perhaps the backend server you mentioned. You didn't say how your server knows that the user just logged in. Depending on user perception of the relationship between your service and the thing they know they logged into, the last two points above might be moot.


That article is wrong and that website in general seems like a very unreliable source for anything.

With the netstat tool, among other stuff, you can see established TCP connections.

When you use Facebook messenger (or any other chat), at least one server is between you and the person on the other side, it's not a peer-to-peer connection. Hence the IP you see using netstat is an IP of a chat server (or whatever other obscure infrastructure, not know to us simple users) that you established connection with.


How to secure file delete/wipe on mobile phones?

On modern Android and iOS devices, some type of file encryption is certainly in place. Without the encryption key, the data is irrecoverable. Therefore, performing a factory reset to remove the key should render the data irrecoverable.
This is assuming you are willing to discard all data on the device.


Accepting Card payments with SNI SSL Certificate

First, there is not such thing as an SNI SSL certificate or an SNI based SSL certificate. SNI is a TLS extension in that the client includes the servers name in the TLS handshake so that the server can pick the correct certificate in case multiple certificates are served by the same IP address. There is no difference in the kind of certificate used with SNI and the one used without. Browsers use the SNI extension for all TLS connections because they don't know if the server needs it or not to serve the proper certificate.

The main question instead is where the endpoint of the TLS connection is. In case of a CDN like Cloudflare this endpoint is the CDN. This means that Cloudflare can look at the decrypted traffic. And, since multiple hosts are served on the same IP address Cloudflare uses SNI to make this possible. But this is only a side effect, not a security problem by itself.

In a similar problem you run if you use shared or managed hosting. In this case at least the company managing the system can have access to the decrypted traffic. And with shared hosting you additionally share the same system with 100's of other users which increases the attack surface a lot: An attacker often needs a single weakness in one of the web applications or a weak password for shell access to get access to the system and with a privilege escalation attack he then can quickly own the whole system and look at the decrypted traffic. Also, SNI is often used in shared hosting to share the same IP address between multiple certificates. But again, the problem is not SNI in this case.

The best option would be if you use your own server as the TLS endpoint, not shared by others and managed in a secure way. And not to use any CDN in front which will be the TLS endpoint instead. But as always you need to clearly evaluate all the risks together: while having a CDN in front which works as a TLS endpoint is bad for security having a CDN which protects you against DOS attacks is again good for security.


Twofish gpg:WARNING: message was not integrity protected

How was the file encrypted? OpenPGP provides an option to integrity protect your ciphertext, called MDC.  Please note this is not the same as MAC or a signature.


It is possible to use tcpdump to read localhost-to-localhost traffic, so I would also consider other programs running locally as possibly capable of intercepting the traffic you're going to encrypt.


Should I use my trusted VPN for all my traffic?

What is your threat model ? Why do you want to use the VPN ?

You seem to think that a VPN is the silver bullet for privacy (thanks to all these ads to fool naive users, even though these VPN providers will probably be the first ones to hand over your data in case of a government/attorney request).

Sorry to disappoint you, it is not. All the VPN does is create an encrypted tunnel between your computer and the VPN server, and all your traffic appears to come from that server to the eyes of websites. That's it.

Why do you think Google or evil advertising companies will have trouble tracking you ? They couldn't care less as to where your IP is your real IP or the VPN server's one. They use cookies to track you. If you want privacy, install a good ad blocker, block all the advertising/analytics crap and you'll regain some privacy.

The only benefit of a VPN is either when you need to connect to your workplace's network remotely (and appear as if you were on their network), or use unencrypted protocols (HTTP, IMAP, SMTP, FTP, etc) over untrusted networks (public unencrypted and often overpriced Wi-Fi garbage, rogue ISP that spies on your unencrypted traffic or alters it, etc).

To actually answer your question, any serious bank uses HTTPS, which is safe to use even on untrusted networks. The VPN won't add any security (but may trigger some alarms on the bank's side because your IP suddenly changed) because it's already secure.


How to authenicate personal computers and phones?

For stuff like "registering a genuine product", the solution is simply serial numbers (which are not particularly secure, but do provide some speed bump to faking a product registration). As a general rule, though, shipping commodity hardware with a unique private key and a meaningful signed certificate is probably more effort than it's worth. What does it actually get you?
Like, sure, Apple would definitely prefer that Hackintoshes never become widespread, but it doesn't actually harm them that much if a few exist and this kind of system isn't needed to just keep the number low. Microsoft, Sony, and Nintendo want to be able to identify unique consoles on their network, and might actually bother with a system like this, but it eats into the already-poor margins on the hardware in exchange for... making it slightly more possible to ban cheaters? Microsoft and other PC/Chromebook vendors probably don't care at all; if something wants to run their software, or pretend to run their software, well that's fine; they distribute the software in inspectable form so there's no way to hide keys in it anyhow. Intel chips do have an embedded key that works something like this; users routinely leave it disabled or even permanently wipe it, because for most users this is a net-negative-value "feature". If Intel attempted to make it impossible to disable, this would lead to a substantial backlash against them.
Phones already have at least one unique identifier (the IMEI), though it's not a private key. It lets operators identify the model of phone on their network, and maintain lists of stolen devices, but you can still use a banned-IMEI phone as a pocket computer. I suppose Apple might want to (and might even be able to) identify iPhones that they want to keep off their store or otherwise track in some way; this isn't a practical option for Android since the software is also distributed separately from the hardware.
It's worth noting that these unique values are generally not available to third-party software. Having a unique key baked into hardware but usable by software can make DRM much easier to implement, but that doesn't make the product more appealing to any end user (Intel briefly exposed full CPU serial numbers to software; this was unpopular and quickly canned). All modern smartphone OSes prevent access to any hardware secrets (like IMEI) and only enable access to a device-wide OS-based secret (usually called an "advertising ID" or similar) with user consent.


How to Determine Malware Outbound Traffic?

Malware uses many ways to communicate, including misusing twitter feeds, comments in forums or hacked sites with a higher reputation. Malware can also do their communication by hijacking browsers. Thus, it is impossible to simply block all malware communication simply by restricting access to specific IP addresses or by only allowing connections initiated by the browser or mail client.

AV products or perimeter firewalls might help to block a major part of malware traffic (but not all) by using curated blacklists and/or deeper analysis  of the traffic. And, depending on the role your system has in the network you might explicitly limit its connection to the specific hosts it should communicate with and deny everything else (i.e. use a white list of a few known good and trusted hosts/networks and not a black list).


Has there been any documented cases where hackers have hijacked the phone number to a business?

This sounds like what you were looking for:

http://www.theregister.co.uk/2009/02/11/fugitive_voip_hacker_arrested/

The work the Kevin Mitnick did was on older Plain old telephone system which was analog based. However, open source projects like Asterisk use protocols like VOIP, which is not analog but rather digital communication.


Yes, this is possible.

Kerberos runs on port 88 on macOS. Kerberos by default has no protections against brute forcing. Submitting an enormous volume of password authentication requests to Kerberos is possible, though to be honest such a thing is useless unless your password is incredibly poor. Kerberos does allow authentication against any user account on the machine so you should consider both the security of your account as well as all your users.

Kerberos is enabled on macOS when you enable File Sharing or VNC to facilitate automatic authentication using your Apple ID on other machines you own. It's a pretty nifty feature. That being said, you should not allow connections to Kerberos from outside your network


DGA (Domain Generation Algorithm) - malwares

I assume you are referencing this Wikipedia article for your info. Basically, the malware does not register the domain names, it just generates a list of possible domain names. The attacker registers domain names that are "possible" outputs of the DGA.

For example, if the DGA is something like:

  x = rand(10)

  domain = "xyz" + x + ".com"

  contact(domain)

Now the attacker registers xyz2.com, the bot has a 10% chance of generating the correct domain name to check in. Over the course of a few weeks, it is highly likely that, at some point, the infected machine will generate xyz2.com and contact the C2.

Point here is that the DGA just generates "potential" domain names, one of which will likley (at some point) connect to the attackers C2.


There are two fundamental facts to know about SSL/HTTPS:

HTTPS is HTTP-within-SSL. In particular, URL don't exist at the SSL level. From the outside, without decrypting the contents, one can see that "this is SSL" and also that "this is for host www.example.com", but not "this is for URL https://www.example.com/foobar/index.html". The "foobar/index.html" can be discovered only by the SSL end, where decryption occurs.

In your case, this means that any redirect will have to be all-or-nothing: the complete site hierarchy, not a subtree thereof.
The HTTPS client (the Web browser) insists on finding in the server certificate the server name it expects, i.e. the one from the URL.

In your case, since you want the client to see a URL starting with https://mypublicdomain.com then the server certificate will need to contain mypublicdomain.com. Since you want the decryption to occur on the private server, then this means that the private server must use a certificate with the name of the public server in it. And since you want the decryption to occur only on the private server, then the corresponding private key must not be known to the public server.

The bottom-line is that the private server owns and controls a certificate with the name of another server, and that other server does not control the corresponding private key. Usually, Certification Authority call that "fraud" and try real hard not to let that happen. So you should be able to do that only if you own and control both servers, and the separation you try to enforce is some security-related isolation, not an ownership difference.

So what you seek to do may happen only if you:

Accept that the proxying occurs for a complete site, and do the proxying down to the level of IP packets or TCP connections. In fact, when this occurs, we normally say that this is virtual hosting, not proxying (this can work with SSL, e.g. see this, provided that the client supports the Server Name Indication TLS extension).
Somehow find a way to have a certificate with the public name in it, but the private key is known only to the private server. If you own both, then that's easy and up to you. If the public server is some hosting provider of whom you are only a customer, then this may be difficult.


Securing Code Secrets - What is the relevance if the host gets compromised?

You mention the "host" being compromised, but the answer depends on just how the host is compromised.  If an attacker has gained access to a user account with restricted privileges, then the jig isn't up yet!  It will be, however, as soon as they find a privilege escalation vulnerability.  That's because:

In general, if your application has access to the secrets, and someone gains root/administrative access to your machine, then there is no way to stop them from gaining access to your secrets.

This is basically just the first law of the 10 immutable laws of security.  Now, additional steps may slow down an attacker.  For instance, it may take them time to figure out how to extract, reverse compile, and find your decryption key.  Or it may take them some time to make sense of a full memory dump though, or to figure out how to intercept traffic between the application and the hardware-decryption module.  Unfortunately, it is effectively impossible to secure an application against a rogue root account (see Law #6 in the link above).  As a result, if someone manages to take over root on host where your application is hosted, you should assume that all data the application has access to is compromised.


Is TPM ownership required for secure boot or measured boot?

From what I can tell in this guide, and I preface this that I'm not an expert in TPMs, taking ownership of a TPM does not affect the Secure Boot options for an operating system.

Taking ownership of a TPM means resetting the keys within the TPM with a new ownership password.  In Microsoft Windows at least this means that the TPM is consulted for any administrative privileges that are required.

Secure Boot/UEFI is a separate process that occurs during boot time.  It does use keys from the TPM, but they're different from the "ownership keys".  The TPM holds several different keys within its hardware to confirm the bootloader, or administrator privileges, etc.


Secure MacOS against malware and external threats?

Fix your attack vectors
You identified that your behavior opens you up to attacks. Instead of trying to counteract these attacks, make them impossible in the first place.
Instead of using an open access point, consider connecting your phone via USB and use your phone's internet access instead. Alternatively, consider investing in a SIM card adapter for your laptop so you can connect to the internet like that directly.
As for opening files, what nature are these files? Images, archives, executables, etc...?
Depending on their nature and their requirement for confidentiality, uploading them to VirusTotal before opening them may already be enough. If they're confidential executable files, consider creating a virtual machine environment to run them in.

Edit: You've mentioned that you primarily open images, PDFs and spreadsheets, so I will give a bit more information on each.
Images are usually harmless, since they don't execute any code. While there are indeed images designed to exploit vulnerabilities in the libraries that decode image data, such as Bannerbomb on the Wii and Stagefright on Android, these are usually very rare. With an up-to-date operating system, you should not be affected - or at least, just as affected as everyone else.
Spreadsheets are a bit more dangerous, since spreadsheets can contain macros. Excel and CSV files can contain malicious formulas, which lead to remote code execution. While this is indeed severe, spreadsheet software these days warns you several times that this is really dangerous and you should only allow that if you trust the document and its source. Spreadsheet software can also be configured to never allow DDE, which is used in these kinds of exploits.
Furthermore, since you mentioned you were on MacOS, Apple has its own spreadsheet software called "Numbers". I have to admit that I don't know anything about Numbers or the possible ways to exploit it. However, I would assume that the situation is similar to other spreadsheet software.
PDF files are even more dangerous, since they can embed all kinds of data. This question goes into detail about the dangers of PDF files. The mitigation is again to keep your reader software up-to-date and to check with VirusTotal if you are unsure about the file.


While it is within the realm of possibility that it was some sort of setup it is extremely unlikely, it's much more likely to be exactly as it appears to be. You offered to show the officer something which could help with an investigation, and he took you up on it. Your neighbor would have little to gain from trying to game the officer. As per your questions:

Should an officer directly plug an outside USB device? NO! There's no telling what malware is on a USB stick with the potential to expose confidential information. He should have taken it and given it to a tech to open in some sort of sandbox environment
There are 2 security concerns here. One is that the officer's computer could have been compromised, giving access to police records and databases. The other concern is you could have picked up malware that was on the officer's machine. That would enable criminals to access your data.
Do police officers receive training to prevent Social Engineering? Yes, extensive. Think about their job - a police officer will have daily contact with many people who have an interest engineering the police. Perps are desperate to get the police to think it wasn't them, and some people try to use the police as a tool by accusing others of crimes they may not have committed. Most police officers quickly develop a sensitivity to manipulation, and learn to not trust people's motives. As for whether they have specific training about IT it depends where it is, some PDs have training and some don't

As for what's the actual risk it's probably very low. It doesn't look like anyone has much to gain in this situation.

As an aside, it may be best checking your local laws for camera surveillance, in many places across the world it's illegal to have a camera without either a permit or some sort of posted notice. You don't want to expose yourself, even if it seems harmless, or even helpful.


Why not RSA-encrypt the entire document?

There is more than one reason:

1) Actually the RSA algorithm is slower.  For instance:

  By comparison, DES (see Section 3.2) and other block ciphers are much faster than the RSA algorithm. DES is generally at least 100 times as fast in software and between 1,000 and 10,000 times as fast in hardware, depending on the implementation. Implementations of the RSA algorithm will probably narrow the gap a bit in coming years, due to high demand, but block ciphers will get faster as well.

Then if you look here you can see that they list DES as taking 54.7 cycles per byte and SHA-1 taking 11.4 cycles per byte.

Therefore computing the SHA-1 hash of the document and signing that is a performance optimization vs. encrypting the entire document with your private key.

2) By splitting the document from the signature you have a more flexible system.  You can transmit them separately or store them in different places.  It might be a case where everyone already has a copy of the document, and you just want person A to verify to person B that they have the same document (or a hash of it).

3) Thinking about it, if someone encrypts the document with a fake private key, and you decrypt it with the real public key, your algorithm can't actually tell you the result (signed or not).  Unless your program can interpret the meaning of the resulting document (perhaps you know it's supposed to be XML, etc.) then you can't reliably say it was 'signed'.  You either got the right message, or the wrong message.  Presumably a human could tell, but not a machine. Using the hash method it assumes I already have the plain text and I just want to verify that person A signed it.

Say I have a program that launches nuclear weapons.  It gets a command file that's encrypted using your method, so I decrypt with the public key and send the result to my command processor.  You're then relying on the command processor to know if it's a valid command.  That's scary.  What if the protocol of the command is just the latitude and longitude of where to target the missile, encoded into binary?  You could easily just launch at the wrong target.

Using a hash, you get a command and a signed hash over a plain text channel.  You hash the command, check the signature, and if they don't match then you don't bother sending anything to the command processor.  If they match, you send the commands on.

If you want to hide the contents of the command, then you take the commands and the signature, zip them together and encrypt the whole thing with the public key of the receiving station before you send them.


Router Security Log Shows Many Blocked TCP Connections

You don't have to worry about this logs. Anything connected to the internet will receive lots and lots of connection attempts every day, from random scans, bots, and security researchers.

Just configure the router to deny WAN access and you will be protected from the vast majority of the attacks. And your router will generally rotate the logs when they grow past a defined threshold, so its storage will not fill up with logs.


SQLMap works by sending a lot of different requests to the server. It is pretty easy to see the scan if you look at your server logs manually.

If you want to do it programatically, just look for SQL verbs in your logs in the input fields where they don't make sense (select, from, where, order by).


Unencrypted proxy connection with encrypted backend connection

It depends on what you mean by 'secure'.

It would mean that the traffic to the proxy is not encrypted and thus the confidentiality of said traffic is not garantueed, nor is any integrity. Someone could be sitting as a man in the middle (MitM) and change requests.

Usually it is a good idea to make connections to proxies encrypted if you care about the confidentiality and integrity of the data being fed to your backend servers. If, for whatever reason, that is not important for your business case, then you could consider no encryption.

The connection to the backend servers also goes over a network (between the proxy and the backend server), but usually the idea behind not encrypting that traffic is that you control said network and the threat of a MitM is much less.


Self-signed vs. authority issued certificate for internal web services

A third option might be to consider using an internal CA that you trust.
Remember, signing a certificate is a method of vouching for the authenticity of the host using it. A Defense-in-depth approach would dictate that self-signing not be used, particularly for microservices that might be processing production information. Self-signed essentially means the only control that needs to be compromised is the host using it.
This is similar to the idea that 'if it's on my internal network its trustworthy'. The numerous APTs have demonstrated this to be an unwise strategy.


I'm not sure why you want to cut off bytes. So I'm not sure if this is a good answer to your question here goes anyway.
Here's what I found out from reading the RFCs/experimenting.
How can I adjust the size of the private to 32 Bytes and public key to 64 Bytes?

You don't have to. They are already in that form. It's just a bit confusing to read from the openssl printout.
Does the leading 00 change the value of the number?

The answer is "No" if you were going to parse it as an unsigned int anyway. (And "yes" if you were (erroneously) going to parse it as a signed int. In that case you need to keep the 0x00 prefix.)
TLDR: The leading 0x00 is a SIGN BYTE that openssl adds for the printout only. It is NOT encoded in the certificate itself. And I guess you can cut of the leading byte (one of 0x02, 0x03 or 0x04) of the pubkey because it just stores info on whether compressed or noncompressed encoding is used.
Sample key with leading nullbyte
Here's an example of a random key I generated:
$ cat leading-nullbyte.pem
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIN/37NFyCvL7brp4zljP83sNj1PvtFsp8dMR86EDwLZUoAoGCCqGSM49
AwEHoUQDQgAEK0acP7Ml6fgKy35YE7JGVP7AmNy7oJ6gl4QIqiwiSExbr4iDPfxT
81550HxXoiQiBJXBJxhgXYpIcJVmFGk20w==
-----END EC PRIVATE KEY-----

ec printout leading-nullbyte.pem
This key is shown with the "00:" prefix for the private key.
At least when using the openssl pretty printer...
$ openssl ec -noout -text -in leading-nullbyte.pem
read EC key
Private-Key: (256 bit)
priv:
    00:df:f7:ec:d1:72:0a:f2:fb:6e:ba:78:ce:58:cf:
    f3:7b:0d:8f:53:ef:b4:5b:29:f1:d3:11:f3:a1:03:
    c0:b6:54
pub:
    04:2b:46:9c:3f:b3:25:e9:f8:0a:cb:7e:58:13:b2:
    46:54:fe:c0:98:dc:bb:a0:9e:a0:97:84:08:aa:2c:
    22:48:4c:5b:af:88:83:3d:fc:53:f3:5e:79:d0:7c:
    57:a2:24:22:04:95:c1:27:18:60:5d:8a:48:70:95:
    66:14:69:36:d3
ASN1 OID: prime256v1
NIST CURVE: P-256

asn1parse leading-nullbyte.pem
...however when actually looking inside the ASN1 encoding there is no 00: prefix. It just starts with df: right away. And also: length is given as 32 (l=  32). Not 33.
    5:d=1  hl=2 l=  32 prim:  OCTET STRING
      0000 - df f7 ec d1 72 0a f2 fb-6e ba 78 ce 58 cf f3 7b   ....r...n.x.X..{

Here's those lines in context:
$ openssl asn1parse -i -dump -in leading-nullbyte.pem
    0:d=0  hl=2 l= 119 cons: SEQUENCE
    2:d=1  hl=2 l=   1 prim:  INTEGER           :01
    5:d=1  hl=2 l=  32 prim:  OCTET STRING
      0000 - df f7 ec d1 72 0a f2 fb-6e ba 78 ce 58 cf f3 7b   ....r...n.x.X..{
      0010 - 0d 8f 53 ef b4 5b 29 f1-d3 11 f3 a1 03 c0 b6 54   ..S..[)........T
   39:d=1  hl=2 l=  10 cons:  cont [ 0 ]
   41:d=2  hl=2 l=   8 prim:   OBJECT            :prime256v1
   51:d=1  hl=2 l=  68 cons:  cont [ 1 ]
   53:d=2  hl=2 l=  66 prim:   BIT STRING
      0000 - 00 04 2b 46 9c 3f b3 25-e9 f8 0a cb 7e 58 13 b2   ..+F.?.%....~X..
      0010 - 46 54 fe c0 98 dc bb a0-9e a0 97 84 08 aa 2c 22   FT............,"
      0020 - 48 4c 5b af 88 83 3d fc-53 f3 5e 79 d0 7c 57 a2   HL[...=.S.^y.|W.
      0030 - 24 22 04 95 c1 27 18 60-5d 8a 48 70 95 66 14 69   $"...'.`].Hp.f.i
      0040 - 36 d3                                             6.

So the leading 0x00 is not actually encoded in the certificate file. While I have not taken a look at the openssl source code in regards to that I'm leaning towards calling this a printout bug.
According to RFC5915 (I think) an EC key is an UNSIGNED integer.
ASN.1 Editor "leading-nullbyte.pem": no actual null byte
As an afterthought: Here's also an actual hexdump of the DER contents. And again: no actual 0x00 in the file.

Sample key WITHOUT leading nullbyte
Here's another random key I generated. It does NOT have the 0x00 prefix when using the openssl ec pretty printer.
So this tells me that that 0x00 prefix is not necessarily there for each EC privkey.
$ cat no-leading-nullbyte.pem
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIAGcFoPfqfFZ5TDv71ZBBCctapiVKwZikE8HfKf61V1DoAoGCCqGSM49
AwEHoUQDQgAENPjKv9vobJnz1FSlSu5cNPyPwCvcsMmIr5HH92C+mZdVtanHwlTm
29IwOE5lSE8KMywIJs8pLCvX79kJhZ/upg==
-----END EC PRIVATE KEY-----

ec printout no-leading-nullbyte.pem
$ openssl ec -noout -text -in no-leading-nullbyte.pem
read EC key
Private-Key: (256 bit)
priv:
    01:9c:16:83:df:a9:f1:59:e5:30:ef:ef:56:41:04:
    27:2d:6a:98:95:2b:06:62:90:4f:07:7c:a7:fa:d5:
    5d:43
pub:
    04:34:f8:ca:bf:db:e8:6c:99:f3:d4:54:a5:4a:ee:
    5c:34:fc:8f:c0:2b:dc:b0:c9:88:af:91:c7:f7:60:
    be:99:97:55:b5:a9:c7:c2:54:e6:db:d2:30:38:4e:
    65:48:4f:0a:33:2c:08:26:cf:29:2c:2b:d7:ef:d9:
    09:85:9f:ee:a6
ASN1 OID: prime256v1
NIST CURVE: P-256

asn1parse no-leading-nullbyte.pem
Here again length is given as 32:
    5:d=1  hl=2 l=  32 prim:  OCTET STRING
      0000 - 01 9c 16 83 df a9 f1 59-e5 30 ef ef 56 41 04 27   .......Y.0..VA.'

Full parse:
$ openssl asn1parse -i -dump -in no-leading-nullbyte.pem
    0:d=0  hl=2 l= 119 cons: SEQUENCE
    2:d=1  hl=2 l=   1 prim:  INTEGER           :01
    5:d=1  hl=2 l=  32 prim:  OCTET STRING
      0000 - 01 9c 16 83 df a9 f1 59-e5 30 ef ef 56 41 04 27   .......Y.0..VA.'
      0010 - 2d 6a 98 95 2b 06 62 90-4f 07 7c a7 fa d5 5d 43   -j..+.b.O.|...]C
   39:d=1  hl=2 l=  10 cons:  cont [ 0 ]
   41:d=2  hl=2 l=   8 prim:   OBJECT            :prime256v1
   51:d=1  hl=2 l=  68 cons:  cont [ 1 ]
   53:d=2  hl=2 l=  66 prim:   BIT STRING
      0000 - 00 04 34 f8 ca bf db e8-6c 99 f3 d4 54 a5 4a ee   ..4.....l...T.J.
      0010 - 5c 34 fc 8f c0 2b dc b0-c9 88 af 91 c7 f7 60 be   \4...+........`.
      0020 - 99 97 55 b5 a9 c7 c2 54-e6 db d2 30 38 4e 65 48   ..U....T...08NeH
      0030 - 4f 0a 33 2c 08 26 cf 29-2c 2b d7 ef d9 09 85 9f   O.3,.&.),+......
      0040 - ee a6                                             ..

ASN.1 Editor no-leading-nullbyte.pem

Extra: How do I know that the 0x00 is a sign byte?
... by experimentation:
I generated a thousand keys like so:
$ for i in $(seq -w 1000); do echo $i; openssl ecparam -name prime256v1 -genkey -noout > key.$i.pem; done

And then I sorted and counted them by first byte like so:
$ for i in $(seq -w 1000); do openssl ec -noout -text -in key.$i.pem 2>/dev/null | grep '^priv:' -A1 | tail -1; done | sed 's/ *//' | sed 's/\(..\).*/\1/' | sort | uniq -c

    496 00
      3 01
      3 02
      4 03
      5 04
      4 05
      5 06
      3 07
      1 08
      3 09
      1 0a
      3 0b
      2 0c
      2 0d
      3 0e
      4 0f
      4 11
      6 12
      1 14
      7 15
      3 16
      7 17
      4 18
      1 19
      6 1a
      3 1b
      3 1c
      3 1d
     11 1e
      3 1f
      6 20
      4 21
      2 22
      3 23
      8 24
      3 25
      2 26
      7 27
      3 28
      7 29
      4 2a
      4 2b
      9 2c
      2 2d
      5 2e
      2 2f
      5 30
      7 31
      6 32
      3 33
      6 34
      8 35
      5 36
      2 37
      2 38
      5 39
      2 3a
      1 3b
      4 3c
      3 3d
      2 3e
      2 3f
      2 40
      3 41
      5 42
      5 43
      3 44
      4 45
      5 46
      4 47
      5 48
      5 49
      5 4a
      5 4b
      8 4c
      6 4d
      3 4e
      5 4f
      4 50
      2 51
      4 52
      2 53
      2 54
      3 55
      7 56
      2 57
      5 58
      3 59
      3 5a
      5 5b
      2 5d
      1 5e
      9 5f
      3 60
      3 61
      3 62
      6 63
      3 64
      1 65
      7 66
      4 67
      3 68
      4 69
      4 6a
      3 6b
      6 6c
      4 6d
      3 6e
      3 6f
      7 70
      4 71
      2 72
      5 73
      2 74
      1 75
      5 76
      3 77
     10 78
      2 79
      7 7a
      5 7b
      6 7c
      6 7d
      5 7e
      5 7f

The highest byte is 0x7f. And that is the final byte that still has a 0 as the most significant bit. (I won't post all thousand of them here but all the privkeys that had 0x00 as their first byte then had their second byte >= 0x80. (There were no privkeys that started with 0x0000.) And all the privkeys did NOT have 0x00 as their first byte then had their second byte <= 0x7f.)


Bitdefender detected over a hundred port scans and still detects, what does that mean and what should I do?

People are scanning the whole IPv4 Internet all the time, in the vast majority of the cases this can be considered "background noise" and can be safely ignored.

Security software tend to alert about events like this so that they can magnify their own importance by showing you how many "threats" (= harmless scans) they detected/blocked. These notifications should be even more suspicious if you are not connecting to the Internet directly but through a SOHO router for example, as these would filter actual port scans from your internal network so Bitdefender at your endpoint can't see them (there may be some techniques that'd allow intranet scans, but again, these are highly unlikely to come by).

Don't panic.


Does PCI DSS 1.4 include tablets and smartphones?

Email servers can be considered an 'outside' company resource, depending on configuration. In that case, if the mobile device only connects to the email server, it is not connecting to the internal network and therefore would not apply to the 1.4 requirement.

But I can think of configurations where accessing the email server could be considered 'inside' access, so I can't make a blanket statement. That's why there are consultants to handle these questions for your specific instance.


What is the actual value of a certificate fingerprint?

The fingerprint, as displayed in the Fingerprints section when looking at a certificate with Firefox or the thumbprint in IE is the hash of the entire certificate in DER form.

If your certificate is in PEM format, convert it to DER with OpenSSL:

openssl x509 -in cert.crt -outform DER -out cert.cer

Then, perform a SHA-1 hash on it (e.g. with sha1sum1):

sha1sum cert.cer

This should produce the same result as what you see in the browser. These values are not part of the certificate, rather they are computed from the certificate.

One application of these fingerprints is to validate EV certificates. In this case, the SHA-1 fingerprint of the root EV CA certificate is hard-coded in the browser (note that (a) it's the fingerprint of the root cert and (b) it has to match exactly the trust anchors shipped with the version of the browser compiled with those values).

Apart from this, these fingerprints are mostly used for identifying the certificates (for organising them).

It's the actual public keys that are used for the verification of other certificates in the chain. The digest used for signing the certificate is actually not in the certificate (only the resulting signature). See certificate structure:

   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

   TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        ...

In this case, the signature value is computed from the DER encoded tbsCertificate (i.e. its content). When the signature algorithm is SHA1 with RSA (for example), a SHA-1 digest is computed and then signed using the RSA private key of the issuer. This SHA-1 digest has nothing to do with the fingerprint has shown by openssl x509 -fingerprint or within the browser, since it's that of the tbsCertificate section only.

There are also a couple of unrelated extensions that can make use of digests, of the public keys this time: the Subject Key Identifier and the Authority Key Identifier. These are optional (and within the TBS content of the certificate).


Would first encrypting a password make slow hashing algorithms unnecessary?

Yes this would make brute-forcing  more expensive, but as was pointed out by “kelalaka” it creates an additional key management problem.

The more classic way to make  brute-force more expensive is by iteration. A hash of a hash of a hash … of a hash a few hundred thousand times can be made arbitrarily slow without creating additional key management problems.

Fundamentally the expense to generate is what makes it expensive to brute-force, all other things being equal.

An unequal example would be a too small hash space. If I assume an arbitrarily complex hash-encryption-magic method that produces a 32-bit hash result, I only have to find a password among 4 billion, and it’s probably not even the one you used but it will still work because of the small collision space.


How likely it is that a (MySQL) client leaks credentials when VPN tunnel was not set previously?

To answer this question you must first understand the mysql-na handshake through to authentication.

If you are using default username & password authentication where the password is stored as sha1(sha1(password) hash in mysql.users then authentication works as follows (there's more steps but to keep this brief it's roughly the following):

Client connects to server
Server sends greeting, version and the supported capabilities of the server as well as a SALT to be used for the session
Client requests authentication to begin, then sends SHA1(password) XOR(SALT + sha1(sha1(passsword)))

So first off credentials are not sent in the clear using this method, they are however if you use mysql_pam plugin as these are passed to PAM for authentication completion.

However using mysql-na you must be aware that and if an adversary can sniff a successful client-server auth handshake, then they can use the mysql-unsha vulnerability (https://github.com/cyrus-and/mysql-unsha1) to gain access without knowing the actual password.

With this clarified let's address you questions specifically

Will any MySQL client software send cleartext credentials to the default route?

This depends entirely on your mysql configuration if you are using PAM to authenticate then it is likely you will see credentials "on the wire", to be 100% on this it's worth running a packet capture on the server and inspecting the resulting pcap with wireshark / tshark.

If the network exists in my routing table?

As per above, depends on your MySQL configuration by default you should not see credentials in cleartext but this does not prevent attackers gaining access via mysql-unsha.

If the IP I try to reach exists locally?

Please clarify are you speaking about your VPN client machine LAN ? this depends on your routes and whether the VPN allows split-tunneling.

If the IP I try to reach exists locally and runs a MySQL server?

Again this needs to be clarified it's far too vague.

If yes, how can I mitigate this scenario (hint: with a few resources, I work for a very small company)?

Your questions need to be made clear, first and foremost so that you can communicate them out to third parties clearly and consistently, the take aways here for you are.

Under default configuration MySQL will use Mysql-NA for authentication which is username + password, this is not in the clear as only hashes are exchanges HOWEVER this is vulnerable to the mysql-unsha attack as outlined above which could allow an attacker to authenticate as a user which they have observed authenticating without knowing the original password only the sha1(password) hash.


What are weak IVs? Can we somehow stop or slow down WEP cracking by avoiding usage of them?

The weak keys you are talking about are exploited by the FMS attack, as correctly pointed out by another user.

  It would be great if someone enlightened me about how they reveal secret WEP keys?

It's not easy. Keep in mind this is a (relatively complex) cryptographic attack, it's not a simple dictionary attack or something like that.

WEP is (should we say was?) based on a cryptographic algorithm called RC4. The way RC4 works is the following:

1) starting from a key - in our case,a shared key concatenated with an IV - it computes an "internal state" S[i], which is a pseudorandom array of 256 8-bit values, through a Key Scheduling Algorithm (KSA);

2) this internal state is the input of a block (PRGA - Pseudo-Random Generation Algorithm) that generates one pseudo-random byte k[i];

3) the internal state is changed and fed again into the PRGA, which produces another pseudo-random byte k[i]+1. The sequence of pseudo-random bytes is known as keystream;

4) the message (plaintext) is XOR'd with the keystream. Because of the properties of the XOR operator, this is like XORing each pseudo-random byte of keystream with a byte of message. Indeed, that's what happens.

One thing you have to know about the XOR: it is always true that A ⊕ B ⊕ B = A.

The FMS attack works as follows.

Because WEP is used in Wi-Fi, which (for technical reasons not related to security) uses a particular type of header, the first byte of any message "protected" by WEP is known and is 0xAA (AA in hexadecimal). Applying the XOR property, and considering that every byte of the ciphertext is derived separately, we can get the first byte of keystream. Let m1 = 0xAA be the first byte of plaintext and c1 the first byte of ciphertext, the first byte of keystream is m1 ⊕ c1.

Remember that the (fixed) shared key is concatenated with the IV, which changes at every packet but is always known to the attacker (since it's transmitted in clear). As the shared key is constant, a key is weak if the IV is weak.

Let's focus now on the first three bytes of keystream K[0], K[1], K[2].

As the keystream starts with the IV, K[0,1,2] are (the only) three bytes of the IV, and as such are known.  The attacker starts with these bytes and loads them into the KSA. If the IV is weak, the attacker can get a possible value of the fourth byte of the key. By repeating this procedure on several packets, the attacker can get a pretty good idea of the value of the 4th, 5th, bytes and so on.

  What are these weak IVs?

As we saw, weak IVs are IVs which allow to get hints about the key, one byte at a time. These hints get more and more concrete as the attacker collects more and more packets.

More specifically, an IV is weak (in the sense of the FMS attack) if it is of some particular kind such as, for example, A+3::ff:X, where A is the byte of the key to be found, ff is 255 in decimal and X is an arbitrary 8-bit value.

  Can we somehow stop or slow down WEP cracking by avoiding usage of weak IVs?

We can stop this attack by avoiding usage of weak IVs, but we cannot prevent WEP cracking at all. WEP is broken in many ways, most of which would work even if the underlying cryptographic algorithm wasn't broken (as RC4 is, for example through the FMS attack).

Do not use WEP, period. There's no reason to do that anymore.


Are there any known exploits targeting Google Authenticator on Android phones?

One thing I found in previous research. The database is a simple sqlite database which can be copied to extract keys and recreate the QR codes. If somebody were able to exploit your phone and root it they, in theory, could copy this database.

Disclaimer: I haven't personally done any of this, so no guarantees.

Extracting the database: https://gist.github.com/jbinto/8876658

Creating QR codes from the DB: https://gist.github.com/naftulikay/5702d57eb4cb6ef6e7e8


If you made your content malicious, and you have enticed a user to visit your blog then you have already succeeded with your attack.

This is just the same as hosting your own website containing malicious content and enticing a user to visit it. The only advantage may be if your target user is likely to trust a *.blogspot.com domain more than any other arbitrary one.

Discounting phishing (e.g. showing a username and password box and asking the user to log into their Google account), the type of attacks you could launch are:

Redirecting a user to another site with an reflected XSS flaw.
Hosting browser exploit code such as Microsoft Internet Explorer colspan Element Processing Arbitrary Code Execution .
Redirecting the user to a malware site or to a malware download.
Executing a CSRF attack.

Again, as the user has to go to your site first they must have some basic trust in it, so I agree with Google in that any malicious code can only compromise the sandbox domain, which does not have any concept of user sessions or sensitive data itself.


Does a client certificate identify the owner to unrelated websites?

Interesting question! I just so happen to have a browser full of test certs, and a number of test sites to connect to! Let's test this!

(Skip to the bottom for a summary)

Investigation

Testing on Firefox

Firefox loaded with certs, a test site that requires a TLS client cert, Wireshark.

I restarted Firefox to get a clean session. Then I entered the URL of a website that will ask for a TLS client cert, and stopped once I got the "Please choose a certificate" popup. This is the wireshark packet capture up to that point:

Things to note:

The client sends a generic ClientHello.

The server sends a ServerHello that includes the server cert, and a request for a client cert.

At this point Firefox presents the popup for me to select which cert I wish to send. If I hit Cancel, then there is no further network traffic, ie nothing is sent to the server beyond the generic ClientHello which contains no personally identifiable information. (apart from the list of supported cipher suites, which could be used to determine which version of which browser you're using)

Note1: I tried the same test with only one client cert in my browser, and I even clicked "Remember this decision" on the cert selection popup, and get the same result. So I am unable to reproduce your result of private data being sent to the server without me clicking "OK".

Note2: As pointed out by @JohnWu in comments, you can change Firefox's behaviour in settings in which case it behaves in the same insecure way as Chrome below. Default setting is:

Testing on Chrome

Exactly the same test scenario as above, but with Chrome. (Note that Chrome does not have its own cert store, but instead uses your Windows cert store, which is a bit trickier to manipulate than Firefox. Details for that not included here.)

BINGO!! Chrome immediately starts sending client certs up to the server without any user prompts. This cert got rejected by the server because that cert was for a different website. Yup, that's a privacy concern alright.

Note1: @JohnWu points out that it's possible to change this behaviour and have Chrome prompt, but it's not the default behaviour, and you have to go diving in Windows group policy (GPO) to do it.

Note2: the reproducibility of this may depend on how your Windows OS was configured since Chrome tends to inherit a lot of its security settings from IE.

Summary

In my testing with the two browsers that I have in my test environment (Firefox and Chrome), Chrome exhibited the behaviour you describe (spamming client certs at the server regardless of whether they are from a different site), while Firefox politely asked me to confirm which cert to send, even when I only had one cert installed.

Conclusion: If you care about privacy, then Chrome is not your friend. Use Firefox instead.


Why do we not trust an SSL certificate that expired recently?

When a certificate is expired, its revocation status is no longer published. That is, the certificate might have been revoked long ago, but it will no longer be included in the CRL. Certificate expiration date is the cut-off date for CRL inclusion. That's the official reason why certificates expire: to keep CRL size bounded.

(The unofficial reason is to make certificate owners pay an annual fee.)

So you cannot trust an expired certificate because you cannot check its revocation status. It might have been revoked months ago, and you would not know it.


Why do we need IPSec when we can encrypt data at Application layer?

TLS was designed to secure only the Application Layer data only.  You can use TLS to create a VPN tunnel, but it is not in this way as often.

IPSec/ISAKMP was designed to secure the IP, TCP, and Application Layer data.  When using IPSec the IPs are encapsulated with an extra layer of the two endpoints for the IPSec tunnel (VPN), and everything at the Transport Layer and above are encrypted.

Because of the way IPSec encapsulates and secures data it is ideal for large routers.  You can route specific network traffic to use the IPSec tunnel across multiple subnets if you wanted to.  It also doesn't require special knowledge or a key exchange since the decision to encrypt traffic is made at the IP level of the stack.  It does require your network to have already established an IPSec tunnel to reach the services in the remote network.  This is ideal for connecting different company campuses' networks together through single points of access.


Can a session be hijacked if the user is redirected from HTTPS to HTTP after login?

Whenever you are requesting a page with HTTP, everything is sent plaintext, that means the session cookie containing the id is sent plaintext as well (even for image requests). That makes it an easy target for MITM attacks. You can configure the cookie to be sent to HTTPS pages only, but of course you will loose the session then on HTTP pages.

The best way to deal with this problem is, to make the whole site HTTPS only, you can avoid a lot of troubles this way. As long as your site doesn't have very high traffic, it should be no problem for todays servers.

If you really have to switch between HTTP and HTTPS pages, you could separate the two concerns of maintaining the session and authentication. You can add a second cookie only for authentication and restrict it to HTTPS pages only. The session cookie can then be used for both HTTP and HTTPS requests. I wrote an example of how this could be implemented (it's written in PHP, but the idea can be implemented in other environments as well).


Some companies are very concerned about information leaking onto social media sites. Because of this, they will put in proxies that inspect the content of data sent to social media. When they do this, they issue their own certificate, and it behaves in the way that you describe.

Is it normal? Not for the average user, but increasingly normal in corporate environments

Is it deceptive? Sort of, but you might have been notified of this kind of thing in a corporate policy

Is it illegal? That really depends on your jurisdiction. But, as I said, it is becoming increasingly common, and in many jurisdictions is legal (with or without notification).

The other question you need to ask is, "what is my risk?" And here it is: Because they are interested in the content of what you post, it is likely that they store, inspect, and alert on that content. That means that everything you post goes to your company. All communication (to those sites) is no longer private to you and your intended audience, but is exposed to those who are authorized to view such information in your company.


Sign in a user or not after they verify email address?

I think it depends on the application. I have been involved in the development of many (web)applications and how you deal with login, logout, activate and password reset is revised per application. If you to make the signup as easy as possible, then create a session on activation. Then you might want to show a message confirming account activation.

On the other hand, some mail clients (Outlook for Android) , proxies and firewalls follow the links in an mail. If you let the user login directly the activation and login could be triggered without the users knowledge. At some later moment when the users decides to activate the account, the link is not valid anymore. You can fix this in many ways.

Personally I prefer the first option, activation and login at once.

From a security perspective, I am not sure it it matters much. Of course anyone with the link can access the account, but at that point the account it's still empty. It all depends on the use case.


Why don't servers vulnerable to NTP and DNS reflection attacks get blacklisted immediately?

I expect any decent DDoS protection service (Prolexic, CloudFlare, etc.) will do exactly what you suggest.

If you consider a basic web presence, where the site has limit bandwidth to the Internet, an on-site blacklist doesn't help. All that NTP traffic will saturate the link, so it doesn't matter that the on-site firewall immediately drops the traffic - it still interferes with legitimate users. This is why you need upstream filtering to mitigate a DDoS attack.


The best way to solve this, is to use LVM Snapshots, to create a "virtual" drive, that is then snapshotted incrementally with regular intervals. This virtual drive is then "shared" through Samba, iSCSI or similar tool to each Windows computer.

Of course, every client can use the same virtual drive.

IF a ransomware then encrypts the files on this "virtual drive", causing all files on the shared Samba/iSCSI disk to be encrypted, you simply delete the snapshot images (which are "diff"s of a drive) until the files are accessible again.

Of course, a good idea is to have the server secured by a firewall such as so it can only be accessed through its Samba/iSCSI ports over the network.

Any console access is to made physically, at the local console.

No other solution is better, as if you mount the drive readonly you must still enforce some sort of versioning on server side, else you will overwrite a perfectly good backup with encrypted rubbish if a ransomware happens to attack.

If you use rdiff, you must still make sure the diff versioning is enforced on server-side and not client-side, else the ransomware can bypass this and overwrite all the diff's.

The best way to enforce versioning on the server side, is to use LVM Snapshots and then just share a "flat iSCSI drive" or a "Samba share" to the client computer. The advantage, is that malware, cannot know that the drive in question is versioned on the server side.

The only disadvantage with a server-side versioned drive, is that you transfer all data over the wire, even unchanged data, but that shouldn't be a problem since you transfer regularly instead of transferring all at once.


On a quite fundamental level, a VPN emulates a "private network" whose purpose is to be isolated from the Internet at large. The "V" means that such isolation is performed cryptographically rather than physically; however, the model is still "separate cables". If your machine is part of two VPN simultaneously, then the private networks are not isolated anymore. This tends to contradict the very reason why the private networks were set up in the first place.

A VPN implementation is called such because applications need not be aware of it. Applications use standard Internet-related protocols (DNS for name resolution, TCP and UDP sockets...) and the VPN picks up traffic and does its magic transparently. A typical VPN implementation hooks itself in the system routing tables, to receive packets which are meant for a given class of addresses. Two VPN can work in parallel only if the addresses used in the two private networks do not overlap -- and that's not easy to achieve, since private networks, being private, do not use a global address allocation scheme. Private networks usually strive on the "private classes" such as 10.*.*.* and 192.168.*.*.

The DNS is a good illustration of the problem of accessing two private networks simultaneously. When an application wants to access a machine named "example", it does not know on which network it is. That's the point of private networks: applications need not be aware of the existence of the private network. The private network hosts its own name server, which can resolve names for the machines it hosts. If you link to two VPN, then, for each name resolution, you will have to talk to both name servers. Hence, the name server from private network 1 will also receive name resolution requests for names which are in private network 2. This is fishy. And if the same name is used in both networks, then all Hell breaks loose. This is the same problem than overlapping IP addresses, translated to the space of names.

Also, if your machine acts as a router, it will happily route packets from one VPN to the other. On a Linux system, this is as simple as:

echo 1 > /proc/sys/net/ipv4/ip_foward

which some Linux distributions will do for you if you asked for it at installation time. Depending on the user not doing something like that looks risky.

To sum up, the normal model for a VPN is that:

a given user system is part of the VPN, only the VPN (and thus only one VPN);
if the system must be able to talk to the "outer world", it may do so only through a dedicated gateway which, from the user system point of view, is part of the VPN.

In particular, a system linked to a VPN shall not be linked simultaneously to another network, be it the VPN or the Internet at large. A proper VPN software will hijack the default route and make sure that it sees all ingoing and outgoing traffic for the whole system. By nature, this does not tolerate the simultaneous presence of another VPN.


Are there any academic articles on how people handle their passwords?

Microsoft Research: A large scale study on password habits

http://research.microsoft.com/apps/pubs/?id=74164

Or google "password user habits" for examples.


(How) should I re-sign keys after transitioning to a new key?

Are there any advantages or disadvantages to using the new key to re-sign the third-party keys I previously signed with the old key? These third-party keys are still reachable from mine in the Web of Trust, by virtue of my having signed my old key with my new key, but wouldn't re-signing them make them slightly more reachable by others, by decreasing the overall path length?

If you revoke your old key (after some time), you will lose a lot of connections into the web of trust if not signing other keys again.

Whether you want to sign them again or not in the end depends on your own policy. There is no ruling on this, the OpenPGP specification does not even mention specific rules on issuing certifications.

  If I do re-sign the keys, is it important to manually verify the fingerprints all over again, just in case the key has been lost or compromised? Or is it acceptable to re-sign by default?

By looking on the fingerprints, you will not be able to decide whether a key has been lost of compromised: you'd have to get in touch with the key holder again. Whether you want to do this additional effort is up to you. GnuPG will restrain from signing revoked keys, anyway (be sure to update them before signing). On the other hand, issuing a new certification might be considered a new statement "I am sure about the keyholder's identity" and is connected with a timestamp: are you still sure about how you verified the identity, which user IDs you selected for signing (you can look this up) and why (this will get more difficult)?

I would not care about verifying fingerprints, but instead using the fingerprints to reference other's keys directly. Such a list can be derived by a simple script and can be directly used to sign keys, caff might provide an easier interface for this.

Personally, I'd only care about signing people I know well and care about.


Handling "forgot password" functionality with encrypted data without security questions

I agree with you on the security questions issue.

How about having the users give you their mobile number as a backup so that you can then text them a one time code, which they will then enter to prove they are who they say they are? It is actually how Yahoo does this now. You can create a free account there (or probably already have one) and test this feature.

The only issue is that it requires your users to have mobile phones. Though, you have already mentioned mobile phones in your Key Escrow solution so I am guessing your users will be expected to have them.


For things like e-banking Chrome devices are secure by default. You don't need to do anything special. There is a good overview about the security here, and a hardening guide here. But you should be aware that your Google account is in fact a part of the system so you should protect the account by things like using a strong password and two factor authentication to maximize security.


How to stop other programs from reading passwords stored in my browser?

Different browsers do this differently, but in general: If you want to make your passwords unreadable for other software on your computer, you'll need to set a master password that you have to enter before you can access your ordinary passwords.

Without a master password, the browser has no secret to derive an encryption key from. Sure, it could just pick one at random, but then it would have to store it somewhere and other programs could just read it from wherever it is stored.

As for "any web application", note that web sites generally can't read from disk, so they can't read your passwords no matter if they are encrypted or not. This is an issue with desktop applications, not web applications.


What is the best way to screen potentially compromised USB or flash devices?

Start with an optically isolated USB Hub: http://www.sealevel.com/store/hub7i-optically-isolated-7-port-usb-hub.html to protect against USB Killer.

Then you want a machine that malware is unlikely to target: Maybe a Sparc box running NetBSD? If the attacker is truly targeting you, this won't help, but if they are limited in their knowledge or effort it might protect you against driver/OS/firmware attacks.

Then you need to sanitise the data - hopefully plain text is sufficient - convert the data into plain .txt (stripping all the formatting).

Then write the plain text to a different USB stick/CD and it should be safe to use on your normal machines.

The only further risk is that the information is crafted to be convincing but false. (An attack on the wetware :-) )


Reuse an email address with a leaked password

You can take your email back if you can pass the "lost password" methods provided, after that you must verify if some unintended user has changed the recovery methods in such a way that he could have it back at any time. After that the only real problem is that it's likely that your email address leaked and you'll be receiving lots of spam email, much more than before. Maybe also he registered in some site (porn/games sites for example) using your email so the spamming goes to you.


Are there any specific advantages of using a blockchain tech in the data tier of an organization from a information security perspective?

It's now 2018 and blockchain doesn't seem to have slowed down.  One idea that is potentially gaining traction is using major blockchains as a distributed timestamping service: if you insert an assertion into the blockchain (e.g., the SHA-256 of a file), you can prove that you were in possession of the file at the time that block was mined into the blockchain.  (Assuming you do not have compute resources >= 50% of the relevant blockchain.)


Should one worry about using an outdated version of Firefox?

It does matter that much via the amount of vulnerabilities and exploits available that affect that particular version. For example, that version had 8 vulnerabilities, 3 of which were critical. From the current release, to that version, there were 53 CRITICAL vulnerabilities discovered. Developers won't go back and say: "Well the exploit on version 28 didn't affect version 23," - it will never be known unless you're a researcher, and your disclosure states something like: "Affects ALL versions prior too..."

So unless you're willing analyze all bugs for all versions prior to current, there is a strong possibility that newer bugs, can affect older versions. Bottom line, you're allowing N amount of critical vulnerabilities in your experience. A workaround would be to use the portable edition of Firefox if you don't have installation permissions.


If you think the database engine you're planning to use isn't secure enough, then I wouldn't advise using it for anything. If it is secure enough, then the added complexity of two different database APIs will make your life harder, and not really affect an attacker (they'll just dump it to a file anyway).

If you want the data physically separate, you could put the password database on a separate machine from your other data.

If you correctly hash your passwords (PBKDF2, bcrypt or scrypt; high cost/iteration count), then your password database shouldn't be very useful to attackers anyway, except in the case of stupidly weak passwords.

Regarding ACID compliance: MongoDB does have atomic operations, it just doesn't have multi-document transactions, which presumably you don't need in a database that only has one collection.


Generate a password dictionary from simple information

There is already an open source tool out there that does this. It's called CeWL. It comes with Kali Linux or available on GitHub.

You can also use Crunch.

A third option: Transmute.py


Is it noticeable when you take a copy of a website?

Is it noticeable?  Very much so: hundreds or thousands of rapid-fire requests from a single address will stick out in the logs, and may trigger anti-DoS or anti-crawler measures.

Is it bad?  Depends on the site, the rate of copying, and many other factors.  Rapidly crawling a website hosted on someone's home server could easily overload their connection and make the site unavailable for other people; if it's  dynamically-generated site on shared hosting, the same could happen due to CPU overload.

On the legal side, it depends on the site's terms of service and what you intend to do with your copy.  If you are simply copying the site for personal offline use and the ToS doesn't explicitly forbid this, it's unlikely that there will be any problems.