ECDSA: Why do ssh-keygen and Java generated public keys have different sizes?

Sizes are different because the formats are different. The strings you show are both binary values encoded in Base64. In all this message I talk about the binary values, i.e. I suppose that you first decoded the Base64 strings into binary.

Mathematically, an ECDSA public key is a point on an elliptic curve. A point has two coordinates, called X and Y, which are bound to each other through the curve equation (in that case, Y2 = X3 + aX + b for two constants a and b that define the specific curve). Here, you use the NIST P-256 curve, which has been specified to work in a 256-bit field, i.e. X and Y are two 256-bit integers. The ANSI X9.62 standard defines a 65-byte format for representing such X and Y; basically, a first byte of value 0x04, followed by X over exactly 32 bytes (in big-endian notation), then Y over another 32 bytes.

So far so good. Then both Java and SSH wrap that 65-byte value into a structure that also identifies explicitly the curve itself through some symbolic identifiers. They do so differently.

Java follows the ASN.1-based encoding also specified in ANSI X9.62. There are several options, but, in your case, you got a SEQUENCE whose contents are a nested sub-SEQUENCE, then a BIT STRING. The nested sub-SEQUENCE contains two OBJECT IDENTIFIER values, the first one being 1.2.840.10045.2.1 (which means "this is an elliptic curve public key"), and the second is 1.2.840.10045.3.1.7, which designates the NIST P-256 curve. The BIT STRING contents are, exactly, the 65-byte encoding of the curve point. To make the story short: the Java value, when Base64-decoded, yields a value of length 91 bytes, the last 65 bytes of which being the encoding of X and Y.

OpenSSH, on the other hand, is well-known for a chronic allergy to standards, and of course they invented their own format. It has been then documented in RFC 5656, section 3.1. Basically, the encoded key consists in three "strings", one after the other. Each string consists in a 32-bit header (4 bytes, big-endian notation) followed by the string value; the header contains the value length, in bytes. The first string is the ASCII encoding of "ecdsa-sha2-nistp256" (this is identifies the signature algorithm). The second string is the ASCII encoding of "nistp256" (this identifies the curve, redundantly with the first string). The third string has a 65-byte value, and, you guessed it, that's the 65-byte encoding of X and Y. The total length is 104 bytes, and the X and Y encoding uses the last 65 of these 104 bytes.

So basically, in both formats, the interesting part is exactly the last 65 bytes; the rest is just an identifier for the involved curve, in two distinct dialects. If you generate many keys with ssh-keygen, you will notice that they will differ only in their last 65 bytes (there again, after Base64 decoding). Similarly with producing many keys in Java.

Therefore, converting from a Java-produced public key to a SSH-compatible public key is as simply as taking the last 65 bytes of that key (after Base64 decoding, where applicable), and concatenating these after the 39-byte header of a SSH key.


How to chose a port to run an application on localhost?

Check this list of unassigned ports
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
Better choose something after 49k
If you are using socket for IPC, use PF_INET family


How to safely store infected PDF file that I have created?

In your case (pdf file) you can safely store that file wherever you want as long as it is not read by any program affected by the bug your pdf file explotes. If instead of a pdf file it is an executable one then you can also store it wherever you want as long as you (or any other automated mechanism) don't execute it.


This largely depends on the used scan, and the nmap scan types page explains the status of the port and the reasons per scan.

Some examples:

TCP SYN Scan (-sS)

 - Sends a TCP packet with SYN flag set
 - If a SYN/ACK (or SYN) is received --> Port is Open, TCP initiation accepted
 - If a RST is received --> Port is closed
 - If no response is received --> Port is considered filtered
 - If a ICMP Unreachable is received --> Port is considered filtered

UDP Scans (-sU)

 - Nmap sends a UDP Packet to the specified ports
 - If an ICMP Port Unreachable comes back --> Port is closed
 - Other ICMP Unreachable errors --> Port is filtered
 - Server responds with UDP packet --> Port is opened
 - No response after retransmission --> Port is Open|Filtered

And a "contrast" example that could produce different results than -sS:

TCP ACK Scan (-sA)

This scan nevers determines OPEN or OPEN|Filtered:

 - A packet is sent with only the ACK flag
 - If a System is unfiltered, both Open and Closed ports will both return RST flagged packets
 - Ports that don't respond, or send ICMP Errors are labeled Filtered.

Basically, your results will be influenced by the scan types and extra options you add. It is important to understand how the different NMAP scan types work at a higher level in order to perform a good and conclusive scan.

Multiple options might be required to get a proper view of your firewall rules.

Also, the --reason flag might give you more insights as to why a port is being shown differently than you expect.


My answer assumes that your attacker is "skilled in the art" of doing this sort of work.

  getting the apk

It would take less time than it took you to write the question.

  decompiling

It depends a bit on the speed of the computer, but it should be on the order of a few minutes.

  finding the function to hook

If you go way out of your way to try to make this non-obvious... perhaps a day? It is a bit difficult to say in the abstract, as it depends a lot on the size and complexity of the app, whether this is just a single "function" or if the work is substantially more involved, etc.

Suffice it to say that anyone who wants to take the time will be able to find what needs to be changed.

  compiling

It depends a bit on the speed of the computer and the size of the code base, but again it should be measured in minutes.

  installing

It would take less time than it took you to write the question.

  In this scenario how much more security could code obfuscation give?

A few years back, I was told by one security researcher that using simple ProGuard obfuscation actually made it easier to do this sort of attack.

There are more powerful obfuscators out there, including ProGuard's "big brother" DexGuard. Similarly, there are people who create de-obfuscators, tools that knock DexGuard-level obfuscation down to something more akin to ProGuard. For example, DexGuard tries to encrypt as much of your app as it can; de-obfuscators would generate a decrypted edition of the code.

Hence, the benefit of high-level obfuscators varies, based upon the current state of the arms race between obfuscator developers and de-obfuscator developers. I can't say with any certainty where the arms race stands now, let alone when somebody else reads this answer years from now.

I liken obfuscators to the old tale of two hunters in the woods being chased by a bear. If you were one of the hunters, you don't have to run faster than the bear to escape. You just have to run faster than the other hunter. In the case of obfuscators, the objective is to make fussing with your app unappealing, causing attackers to move onto other potentially easier targets. The problem with this approach is that it assumes that the attacker does not care about your app specifically, that your app is merely one target among many. Attackers who care about attacking your app for specific reasons will not behave that way, and they will spend the time to crack it. In other words, running faster than the other hunter assumes that the bear is not pissed off at you specifically.


Why is it so hard to trace origins of DDOS attacks?

Those DDOS attacks were performed using a botnet. A botnet is a network of consumer PCs infected with malware. Such botnets are routinely used for a lot of activities, most of them illegal or at least ethically questionable. For that reason the people who control a botnet do their best not to get found. They usually control their botnets using obscure methods of anonymous communication which are very hard to track back to them.

You might wonder "considering the publications lately about the internet spying capabilities of the US government, how couldn't they get found?". Maybe the US government is aware who did it, and when they aren't they could easily find out. But the truth is that even though the US government collects bulk data about everyone in the world, the current legal situation does not allow them to prosecute anyone based on that data. All that data collection is illegal wiretapping, so it may not be used as evidence in court.

The only thing the US government can do against people they only have evidence against through their surveillance programs are illegal extrajudical actions like kidnapping them and deporting them to a secret prison or killing them through a drone strike. Such drastic actions are currently only performed against people who are deemed a danger to national security (or live near the Afghan/Pakistan border).

And contrary to what some "Hacktivists" believe, making a public website of a government agency unreachable for a few hours, is not an attack on national security. Such an attack is about on the same danger-level as drawing an defamatory graffiti on their wall.


Is adding encryption before hashing more secure?

The general idea is that any secure process must be able to remain secure even if the process is known. In this scheme, you've just added a step: encryption.
But you have to accept that people will know that you've added encryption and what type. This means that you've only made the process of checking passwords just one step more difficult because there is that extra step.
This means that you've only made it a little more difficult to test passwords: hash(encrypt(password||salt))
Your better bet is to do what is suggested for best practice: multiple rounds of hashing.


If windows already has all admin rights, wouldn't a malicious program just need to pretend to be windows?

Acting as Windows is called running as SYSTEM. SYSTEM is the user account that has the lowest level access and can do anything on, well, the system. Windows uses the SYSTEM account to run key services that keeps the system in order.

If you can run as SYSTEM then yes you can pretty much do anything you want on that machine. The problem is that it's really difficult (relatively speaking) to get a program to run as SYSTEM, as you need administrative permissions to do so.


What is the recommended procedure to migrate to a new OpenPGP master key?

There is no way to change your primary OpenPGP key without losing incoming certifications. When you create a new one, and you will loose your reputation in the web of trust.

What you can do to keep as much of it:

Sign your new key with the old one, so others could follow the signatures. They can still do (manually) when you revoked your old key, at least it is an indication on what was going on if somebody really cares.
Sending a key transition statement to those that signed your old key; some of them might also sign your new one.
Getting your new key signed, ie. go to key signing parties.
Do not revoke the old key immediately, but only after some time when you already received a bunch of new certifications.

Given you do not expect your key to be compromised, you could also consider just watching it (which you should be doing anyway). Especially if your primary key has only certification capability, not a lot of "invisible" damage could be done -- no messages are encrypted for this key, no signatures on documents and messages can be issued.


Using Window Servers 2003 after security updates are discontinued

Will my system be secure?

Maybe. While you say you do not browse from the system nor does it communicate with the internet, there are a number of other possible scenarios to contend with:

That the system is already compromised, making this discussion moot. Unlikely, but still possible.
That the system can be attacked from compromised hosts on your internal network.
The type of attacker you are defending against; e.g. a determined targeted attack ("advanced persistent threat") or a scattergun approach.

Whether the second point holds really depends on your configuration and whether any holes exist in the OS once it reaches end of life. If there are, these will not be fixed.

Whether these holes can be exploited really depends on the type of attack. An automated scattergun-type malware might optionally attempt to scan for known vulnerable systems and try to compromise those too. Or it may miss them, on the basis of no longer considering them viable due to dwindling install numbers.

A targeted attack is likely to be different. If I was looking at how to attack your system, and I had knowledge of this box running beyond-the-grave-software, I'd be cackling like Borris from goldeneye (pleased, basically). The reason for this is simple: if I can find a hole on this box, I know it won't be patched. I no longer have to deliver an exploit within a certain Window - I can simply compromise at will. Got any other systems on the same platform? Great, I can attack those too. Even if you re-install, I can re-infect - because plugging the hole will not happen.

As such, I'd tend to err on the side of saying no, it's not secure. There's a lot of 'if's in that assumption, and a lot of adjustment depending on the risks you believe you face, but given the machine is a fairly critical one, I'd update.


How could a shared password database be implemented?


Indicator of Compromise effective periods

Malware analysts are often asked to correlate IoCs retroactively. Recently  correlated IoCs that went back to Chinese code from 2002 in 2016. Just a few months ago, we found meaningful IoCs that tied a threat commnunity to its predecessors from 2006. Without the ability to track all of these IoCs across the years, there would not have been a correlation.

There are also ways to grade IoCs:

Level 1 : SHA2 hashes, BGP ASNs, hostnames
Level 2 : MD5+SHA1 hashes, IPv4/IPv6 Prefixes
Level 3 : Mutex names, Imphashes
Level 4 : Yara rules
Level 5 : File, class, or block similarities (e.g., Icewater, GCluster.py, TLSH or ssdeep fuzzy hashes)
Level 6 : Apiscout and master-level malware analyst techniques

Malware tends to bypass all of the above in different manners. Some malware can even lie to or bypass all of the above, simultaneously. You definitely want to scale your IoCs when working against that threat space. However, you’ll also want to take into account factors that computers cannot scale —- the human element, surprise, and indications.

Perhaps you mean, how long should you monitor IoCs on the network? Or do you mean in sweeps across a fleet?

If you are looking for a way to manage IoCs on the network, check out the Bro Intelligence Framework. For fleet management of IoCs there are a few tools, such as Viper to database and view classic IoCs, YaraGuardian for organizing and searching Yara rules, Timesketch to play with the data, as well as ways of gathering artifacts and mining/monitoring log data.

There are many ways to approach artifact and log collection, in addition to monitoring, analysis, and synthesis. I like how these professionals outline 3 approaches —- https://posts.specterops.io/thoughts-on-host-based-detection-techniques-21d9c97082ce —- especially through their toolsets such as Automated Containment and Enrichment (ACE Server), Hunting ELK (HELK), and UpRoot. You’ll see the techniques from these toolsets in commercial platforms, such as Infocyte, Splunk Enterprise Security, and Carbon Black Cb Response, respectively. If you really want to scale fleet sweeps of IoCs, then the ACE Server, InfoCyte, and maybe even the PowerForensics or PowerShell Kansa tools are my first-round suggestions.


Android assigns different user IDs for each installed application as a privilege separation mechanism.  This can be influenced by the certificate that is used to sign an application (https://source.android.com/security/overview/app-security.html#application-signing) in conjunction with the android:sharedUserId attribute in the application's AndroidManifest.xml file:

  When an application (APK file) is installed onto an Android device, the Package Manager verifies that the APK has been properly signed with the certificate included in that APK. If the certificate (or, more accurately, the public key in the certificate) matches the key used to sign any other APK on the device, the new APK has the option to specify in the manifest that it will share a UID with the other similarly-signed APKs.

Android applications launched by end users are all spawned from the Zygote process (this is to help speed application launch, since the Zygote can fork and load the application code and not have to reload a bunch of system libraries).  At the time of writing this, the Zygote service configuration looks like this:

  service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
    class main
    socket zygote stream 660 root system
    onrestart write /sys/android_power/request_state wake
    onrestart write /sys/power/state on
    onrestart restart media
    onrestart restart netd
    writepid /dev/cpuset/foreground/tasks

The syntax of this file is outlined here: https://android.googlesource.com/platform/system/core/+/master/init/readme.txt, which has this to say about the privilege levels assigned to services by default (so you can see that by default, Zygote runs as root):

user <username>
  Change to username before exec'ing this service.
  Currently defaults to root.  (??? probably should default to nobody)
  Currently, if your process requires linux capabilities then you cannot use
  this command. You must instead request the capabilities in-process while
  still root, and then drop to your desired uid.

Zygote uses a JNI method named forkAndSpecialize (search for "com_android_internal_os_Zygote.cpp") to handle the platform specific task of calling setuid() to the UID that the Package Manager has assigned based on the manifest and installed applications.  Failing to properly exit if that setuid call failed has been the source of Android privilege escalation vulnerabilities in the past (read up on the RageAgainstTheCage exploit if you are interested, although that was not Zygote related).

This is the main reason that you need a separate privileged/setuid binary to launch applications using root level privileges.  If you built your own custom system image, you could conceivably modify the PackageManager / Zygote to retain the root privileges, but doing so basically breaks the Android security model.


How are PSKs agreed upon by the TLS server and client?

How is the PSK shared?
A pre-shared key is, by definition, pre-shared. The term for this is that it is distributed out-of-band. In other words, the protocol does not prescribe a mechanism for sharing the key. It could be done using a logically-separate key agreement protocol, or by being generated from a shared secret hardcoded in both devices, or over a wireless NFC connection, or even by being directly typed in through a keyboard by a human. The point is that the PSK is shared exclusively out-of-band.
The definition of out-of-band, according to Wikipedia:

[...] an agreement or understanding between the communicating parties that is not included in any message sent over the channel but which is relevant for the interpretation of such messages.

How is the PSK used?
There are three main suites in TLS-PSK. The first, PSK, uses this shared-secret directly to derive all symmetric key material for the protocol. The latter two, RSA_PSK and DHE_PSK, only use the PSK in place of a standard digital certificate. TLS-PSK is used to refer to any of these three suites:

PSK directly uses the pre-shared secret to derive the premaster secret, which itself is used to generate all other symmetric keys used by the protocol. If the PSK is stolen, confidentiality and authenticity are completely lost. That is, an attacker can passively decrypt stored sessions.

RSA_PSK uses the pre-shared secret only for authentication in place of a standard certificate. The actual premaster secret is exchanged using RSA. If an attacker manages to steal the PSK, they will be able to perform a MITM attack, but a passive attacker will be thwarted.

DHE_PSK is like RSA_PSK, but using Diffie-Hellman (DH) rather than RSA. DH provides forward secrecy. It is stronger than RSA in that the private key is ephemeral and never stored. There is less risk that the private key will be stolen, to allow passive decryption of recorded sessions.


Ads appearing in our application when they should not be

While I also believe the most likely explanation is definitely that the users system is infected with adware, I would like to present some alternative explanations.

There is still a small possibility that your website is indeed serving advertisement. It isn't unheard of that criminals hack into insecure web applications and modify them to deliver ads or malware. When they do, they might take precautions to conceal this from the administrator, like serving unmodified output to certain IP ranges. When you receive similar reports from many other users, you might want to check if any source files on the server got modified somehow.

Your server could also serve advertisement because of an unlicensed 3rd party library you are using. There are, for example, DotNetNuke modules which inject advertisement into the website when they aren't properly licensed (thanks to Jasmine for the comment).

Another possible explanation could be that the advertisement isn't injected by you or by adware on the users machine but by a man-in-the-middle. The user might use an anonymous proxy server to improve their privacy. Some of these proxy servers generate revenue by injecting their own advertisement into the websites they relay.


The role of preshared key (or certificate) is to authenticate the other peer. Even if connection is encrypted, you need to know that the peer you are establishing connection with is the one it should be. Encryption provides confidentiality in the connection and preshared key that only you and the other party knows provides the authentication.


why don't we store passwords in a database using encryption instead of hashing?

Because if a user can get their password out of the database, then so can:

The system/database administrator.
The school/employer/government who's proxying the user's Internet access.
The hacker who pwned the WiFi at the coffee shop.
The hacker who pwned the user's e-mail account.
The hacker who pwned the server.

In some of these cases, ease of access is dependent upon whether or not the system is vulnerable to other exploits. In others, the damage can be exacerbated or reduced depending on the user's password hygiene.

However, all cases represent scenarios where hashing would mostly - if not completely - block people who shouldn't have access to other people's passwords. Encryption cannot help here.

It's also worth noting that a user does not ever, for the purposes intended by any website, need to get their actual login credentials from the system. In the case that a user forgets their password, the system should provide a mechanism by which they can securely reset or change it to a new, known value.

Will switching to password hashing and implementing a reset (instead of recovery) process absolutely prevent an attacker from accessing a user's account in all the scenarios above? No. But it certainly raises the bar, and ensures that the damage for the user is isolated to just that one account - not every account the user used the same password on.


Does an application purely for intranet use by employees need secure software design or to follow OWASP guidelines?

While Kyle Fennell's answer is very good, I would like to offer a reason as to why it is recommended for internal applications to be designed securely.

A large number of attacks involve internal actors

There are many different versions of this factoid. "50% of all successful attacks begin internally", "Two thirds of all data breaches involve internal actors", etc.

One statistic I could find was Verizon's 2019 DBIR, in which they claim:

  34% [of the analyzed data breaches] involved internal actors

Whatever the exact number may be, a significant amount of attacks involve internal actors. Therefore, basing your threat model on "it's internal, therefore it's safe" is a bad idea.

Secure Software Development does not just prevent abuse, but also misuse

Abuse: The user does something malicious for their own gain
Misuse: The user does something malicious because they don't know any better

The reason why I bring up misuse is because not everything that damages the company is done intentionally. Sometimes people make mistakes, and if people make mistakes, it's good if machines prevent those mistakes from having widespread consequences.

Imagine an application where all users are allowed to do everything (because setting up permissions takes a long time, wasn't thought of during development, etc.). One user makes a mistake and deletes everything. This brings the entire department to a grinding halt, while the IT gets a heart attack and sprints to the server room with last week's backup.

Now imagine the same application, but with a well-defined permission system. The user accidentally attempts to delete everything, but only deletes their own assigned tasks. Their own work comes to a halt, and IT merges the data from last week's backup with the current data. Two employees could not do any productive work today, instead of 30. That's a win for you.

"Internal" does not mean free from malicious actors

Some companies are technically one company with multiple teams, but they are fractured in a way that teams compete with each other, rather than working together. You may think this does not happen, but Microsoft was like this for a long time.

Imagine writing an application to be used internally by all teams. Can you imagine what would happen once an employee figures out you could lock out other employees for 30 minutes by running a script that he made? Employees from "that other team" would constantly be locked out of the application. The help desk would be busy for the 5th time this week trying to figure out why sometimes people would be locked out of the application.

You may think this is far-fetched, but you would be surprised how far some people would go to get that sweet sweet bonus at the end of the year for performing better than "the other team".

"Internal" does not stay "Internal"

Now, in 2020, your application will only be used by a small group of people. In 2029, the application will be used by some people internally, and some vendors, and some contractors as well. What if one of your vendors discovered a flaw in your application? What if they could see that one of their competitors gets much better conditions?

This is a situation you do not want to be in, and a situation that you could have prevented.

Re-Using Code from your "internal" application

You write an internal application that does some database access stuff. It works fine for years, and nobody ever complained. Now you have to write an application that accesses the same data, but externally. "Easy!", thinks the novice coder. "I'll just re-use the code that already exists."

And now you're stuck with an external application in which you can perform SQL injections. Because all of a sudden, the code that was created "for internal use only", no pun intended, is used externally. Avoid this by making the internal code fine in the first place.

Will it be enough to follow OWASP?

The answer to this question is another question "Enough for what?". This may sound nitpicky at first, but it illustrates the problem. What exactly do you want to protect?

Define a threat model for your application, which includes who you think could possibly be a threat for your application in what way, then find solutions for these individual threats. OWASP Top 10 may be enough for you, or it might not be.


Is non-malicious unauthorised usage likely to suggest a security compromise?

Can the lack of malicious actions taken during the breach be taken as any indication that it was not a deliberate hacking attempt?

Someone was able to enter your account. Activities that followed don't matter. You never know what all changes were made to your account. Maybe, the free additions were made to mask the other evil intentions. Or, maybe, it was not a deliberate hacking attempt.

But the fact remains that someone else was able to enter your account, and that in itself is a reason enough to cause worries.

  ...and that I did the right thing to change my password.

Yes, and apart from this, you should contact the website's support to inform them of such activity. They should rectify it if the problem is on their end.

Also, you should change passwords on all other websites, which are still using the hacked password.


Can I trust the SSL certificate on the client side?

TL,DR: Yes, you can trust the certificate.

Long version:

You browser have a list of trustworthy entities, named Certificate Authorities (or CA, for short). They have the task of signing SSL certificates along the way. They must comply to a lot of rules, and if they mess up, they can be axed from this list, and all certificates they emitted got invalid overnight.

(That happened with DigiNotar)

When anyone wants a SSL certificate( e.g John Doe), he goes to one of those companies, and ask for one. Usually the issuer have some kind of verification to determine if you owns the certificate you are asking a certificate for. If so, you get the certificate (it's just a text file) and put it on your webserver.

The certificate can be changed if you are under a corporate proxy that performs SSL traffic inspection (an intercepting proxy). They intercept the connection, decrypts the traffic, analyses, creates another certificate, and sends back. In this case, a certificate appearing to be from Google.com was not issued for Google, but instead issued from your proxy.

Sometimes, people can get a certificate for a domain they don't own. That usually happens when those people intend to perform a phishing attack against the users of the legitimate domain.

If someone issued a certificate without using the services of the CA, your browser will complain. Depending on how the certificate was created, it will say the certificate is self-signed, or the certificate chain is invalid. In this cases, you obviously cannot trust it.

So, except in almost negligible situations, you can trust the certificate.


Passwords: Symbols and length > 20 disallowed

Disallowing symbols is usually a sign that someone in the development process heard about SQL injection, code injection, or cross-site scripting and decided to take a brute-force approach to preventing it rather than going to the effort of understanding what the real risks and prevention techniques are.

Length limits are either a sign that someone didn't think carefully when defining input limitations, or a sign that your password is stored directly rather than hashed and the database field only allows a certain amount of space for the password.

In the specific case that passwords are limited to 8 characters of printable ASCII, it is usually a sign that either the passwords are hashed using the obsolete DES crypt() function, or the software was developed by someone whose mind is stuck in the DES crypt() era.


Is there a way to change the format of the output from snort?

Actually, I figured it out. I can output my alerts as a .csv file by adding a line to my snort.conf file:

output alert_csv: stdout proto,tcpflags,src,srcport,dst,dstport,msg

and then running snort like this:

snort -c /etc/snort/snort.conf -r my_PCAPFILE.pcap > snort-output.log > alerts.csv

As far as determining duplicates I'm sure I can run a little script inside of my .csv editor to filter them out. If anyone else has any better ideas please comment or add your own answer.


Is it safer to use Qubes with Whonix from Virtualbox than directly on the host computer?

Your security posture is likely somewhat weaker when running it in a VM. I recommend that you read the Qubes-Whonix security page, as it has some useful advice here.

Running it in a VM means you increase your attack surface. Qubes-Whonix itself is designed to offer increased security, so running it inside a VM in a regular OS doesn't make much sense. You're basically running a hardened OS and then giving an OS with a weaker security posture complete control over it. You also shouldn't use a multi-boot environment for exactly this reason.

Additionally, from a forensics perspective, you can't make as many safety guarantees about memory volatility when using a VM. The virtualisation solution may flush some guest pages to disk, and the host OS itself may swap out guest pages too. Data written to the virtual disk may remain in slack space in the virtual disk file even if you overwrite blocks from within the guest, because virtualisation solutions don't always use simplistic block storage models for virtual media.

If your threat model is such that all of your sensitive work is isolated within the Qubes VM, and you're not concerned about someone targeting you personally (as opposed to a drive-by malware campaign), then Qubes in a VM is fine for convenience. Otherwise I'd run it bare-metal.


what are potential security risks of a python script outside public_html folder

Whether they can access it remotely depends on many things, such as your server's configuration details, and any security holes in your CGI scripts.  The python script does not create any security risks merely by existing (if a remote user could execute it, they could use the same techniques to execute something like cat /etc/passwd or rm -rf /), but may present risks if a remote user can influence its operation.

You haven't provided enough information to give a definite "yes" or "no" to any of your questions, and for some of them, it requires a detailed analysis of the computer's configuration.


Securely saving credentials for later plain-text authentication

Perhaps the app should use Kerberos to authenticate to the server, as well? E.g. using constrained delegation.

Alternatively it could have a SSH key of its own, one that works for all accounts but only from the webapp server's address.


First, you shouldn't be hashing passwords with only a single SHA256 round.

When you switch to a real password hashing algorithm, some common implementations of them (at least in the past, I'm not sure where this is still true) will not correctly handle zero (NUL) bytes, truncating the input to the hash, greatly decreasing the security. So storing the salt in binary may be a bad idea. Additionally it makes your system less flexible to increase the length of the salt, etc., in the future. I think normally the salt is stored along with the hashed password in a single field, both base64 encoded. But I may be wrong, I don't do database stuff for a living. :-)

On that note, I can't really answer the question about using a select query to find the salt for a user for the same reason. But I don't know what else you would do, just be sure not to simply use the user-supplied username directly in the query, that's wrong in all sorts of ways.


Is it a bad idea for an information holder to e-mail a user their password?

They are either storing it in plain text (likely) or they are using a reversible encryption. So in case of a compromise the password is at risk.
Yes, and it is even worse: Some email providers such as Hotmail delete inactive email accounts and allow other people to register it. The upper management of Twitter was successfully attacked by re-registering an old Hotmail account.
Yes, correct. A reused password, that was revealed in one of those mails, played an important role in the mentioned twitter attack.


Delivery Failure Notification spam protection?

What you're getting is called backscatter, and it's annoying. Because email need not be authenticated, spammers will send email using a forged return address. When the spam delivery fails, the recipient will sometimes send a falure report back to the forged return address. The (real) recipient of that failure notification message can get understandably very angry about this, since he was never actually involved in this mess to begin with until the hapless spam recipient sent the failure notice to an innocent bystander.

The solution is for everybody to quit sending these failure notifications unless you can conclusively prove that it's going to someone who actually sent you the message you're notifying about.

If you're part or the problem then for the sake of everyone's sanity, quit it.


Generating x509 PEM files for testing PEM parser

A few attempts I made at making bad X.509 certs using phpseclib, a pure PHP X.509 parser.

Adding random characters at the end of a SEQUENCE:

http://pastebin.com/5Jcy0d90

Replace the RSA / DSA part of an X509 cert with another X509 cert:

http://pastebin.com/570bR2jz

A cert with the same extension multiple times:

http://pastebin.com/acmcXbAg

Invalid OID:

http://pastebin.com/3svVQyP3

A bazillion nested SEQUENCEs:

http://pastebin.com/fKw6XAEp

Non-constructed sequences:

http://pastebin.com/kpajfQyD

Having a signature that doesn't match the signature algorithm:

http://pastebin.com/GAED5xQe

To get that last one working you'll need to do http://pastebin.com/Dq2XAAGG to get it working.


How is the iCloud keychain protected from unauthorized access?

You're right to have doubts about the security of a four-digit pin code - whatever Apple does to protect your Keychain data, at least somebody within Apple would always be able to perform a brute-force attack for all 10000 possible digits with very little effort. It's simply not possible to protect against a parallel brute-force with such a low-entropy input, no matter what KDF you use.

Since the implementation is proprietary and closed-source, everything about the actual workings is speculation, so please take the following speculations with more than a grain of salt. That being said, here is how a service like iCloud Keychain could be implemented in a way that is consistent with Apple's public statements.

The Keychain contents really seem to be encrypted with a client-side symmetric key; probably only an encrypted version will be uploaded to Apple's servers.
Adding new devices probably happens via public-key cryptography (granting a "new device" requests could encrypt the symmetric key with that device's public), but unfortunately allows no fingerprint verification (which makes man-in-the-middle attacks possible, just like with iMessage).
The recovery password will likely be used to encrypt the symmetric key using a key hardening function using a salt and many iterations before it is uploaded to Apple; when using that recovery code, Apple probably uses a hash based on that code to rate-limit recovery attempts before handing out the wrapped symmetric key together with the encrypted Keychain data.

Ars Technica has an interesting article on the subject, and they come to the conclusion that using the suggested four-digit recovery code makes a brute-force attack very feasible - but only for Apple (or somebody who manages to break into their server-side infrastructure).

I've also written about this in a blog post myself, where I come to very similar conclusions.

To sum it up: If you're worried about Apple (or somebody who is able to gain access to their systems, whether hacker or law enforcement authorities) getting access to your Keychain data, use at least a strong alpha-numeric password for recovery or don't use the recovery code at all.


Stateful vs Stateless *host* firewall - is there any advantage?

Let me take a stab at this question...

The term Stateful is often associated with both "Deep Packet Inspection" and "Stateful Packet Inspection":

Deep Packet Inspection: The ability to look into a packet and see what command is being
used.  So, for example, I'll allow incoming FTP request, but not
allow the PUT and DELETE commands from FTP.  This would make my FTP
essentially read only.
Stateful Packet Inspection: The ability to remember a connection.  Many protocols (like HTTP)
have a well-known port (like port 80) for the outgoing "request", but use a
"public" port (>1024) for the incoming reply.  SPI can remember the
return port number and specifically allow it.  Without the ability
to remember the connection, you'd have to allow all incoming IP addresses on
all port number >1024 in order to get the reply

So, as Marcus has pointed out... these are very common features of most "personal firewalls".  Although Microsoft's personal firewall does SPI a little differently than a perimeter-based firewall would.  That's because at the host, you can include the application or service that the connection is associated with (something that a perimeter firewall wouldn't know about).  So, for example, I wouldn't have to allow for all incoming IPs and ports >1024 for all packets... just only those packets associated with IE.  Yeah, that's not quite as good as the more formal approach, but it's something.

So, yes... the Microsoft software-based "personal" firewall that appears in modern versions of Windows is (just barely) a Stateful firewall.


Does FIDO2 token works as two-factor on password-less authentication?

Fido2 can be single factor or multi-factor. From WebAuthn (a component of FIDO) Wikipedia page:

"A FIDO2 authenticator may be used in either single-factor mode or multi-factor mode. In single-factor mode, the authenticator is activated by a test of user presence (TUP), which usually consists of a simple button push. In multi-factor mode, the authenticator is activated by either a PIN (something you know) or a biometric (something you are)."

The reason is that Fido2 works by sending a challenge from the server to the client, and the client authenticates by signing that challenge and sending to the server.

Fido2 certified devices require the key to be protected at hardware level. So when a particular key signs the challenge, it proves that it comes from user's device.

A PIN or biometric then acts as the second factor used in authentication.

Both combined make it multi-factor authentication.


Anniversary Update with Bitlocker Reboot without Encryption Key

I know you've already got an answer elsewhere.

However, just in case someone else stumbles upon your question, I'll try to provide a short explanation:

In Windows 10, the Anniversary Update (1607), as well as the other "Feature updates" (November Update [1511], Creators Update [1703], ...) are in fact major updates, in some ways similar to an upgrade from Windows 7/8 to Windows 10 (you end up with a Windows.old folder, for instance).

During these major system upgrades, Bitlocker is not disabled: the drive is not decrypted before the upgrade and then re-encrypted after the upgrade, as you correctly inferred.

Instead, Bitlocker is suspended.

The difference between suspending and decrypting is explained in the Bitlocker FAQ:

  Decrypt completely removes BitLocker protection and fully decrypts the drive.

  Suspend keeps the data encrypted but encrypts the BitLocker volume master key with a clear key. The clear key is a cryptographic key stored unencrypted and unprotected on the disk drive. By storing this key unencrypted, the Suspend option allows for changes or upgrades to the computer without the time and cost of decrypting and re-encrypting the entire drive. After the changes are made and BitLocker is again enabled, BitLocker will reseal the encryption key to the new values of the measured components that changed as a part of the upgrade, the volume master key is changed, the protectors are updated to match and the clear key is erased.


Does SSL/TLS provide non-repudiation service?

Update 2017-11-05: "TLS-N" and others
I only recently learned of the existence of a new project. Some guys from the university of Zürich are working on something called "TLS-N" which is dedicated to bringing non-repudiation to TLS. There is no RFC that I know of yet. But they have a white paper. I'm not sure when/if we'll ever see this in the wild. But it's an interesting idea. See: https://tls-n.org
Also mentioned in their paper are some earlier attempts at bringing non-repudiation to TLS called TLS sign and TLS Evidence. Both attempts seem to have died a long time ago.
Your book is right. There is no non-repudiation for regular TLS packets.
When Alice tells Bob "Let's kill the president!" and Bob goes to tell the police, then Alice can always say: "I never said that." So Alice just repudiated the previous statement.
And in regular TLS there is no way for Bob to prove by himself that Alice has in fact repudiated her earlier statement.
So no, regular TLS does NOT provide non-repudiation. So your book was right.
Signatures can provide non-repudiation...
Now why is that? Asymmetric crypto allows you to provide proof of authorship by using Cryptographic Signatures. This WOULD in fact give non-repudiation. Then it would be straight forward to verify Yep, that really WAS signed with Alice's private key. And there is no getting out of that mathematic fact. (Of course then Alice could say: "But my key was stolen!" but there's no denying that her key was used to sign that particular message.)
So if in fact crypto signatures were used for regular TLS packets then they would be non-repudiatable. But signatures are NOT used for the regular TLS packet, so we don't have non-repudiation either.
...but TLS packets are MACed instead
Instead what is used to prove to the other side, My message has NOT been changed along the way is something called a MAC, a Message Authentication Code. MAC-functions work like this: You drop in two inputs and you get one output. One input is a secret MAC-key, the other input is the message that you want to protect. And what falls out is like a two-dozen byte hex-string, called a MAC Value. That string is sent along with the encrypted message. The recipient then feeds the same to inputs into the MAC function again and only accepts the decoded message if the MAC Value matches.
But since Alice and Bob both know the secret-MAC-key either one of them can generate MAC-values for whatever message they like. A MACed message says NOTHING about authorship of either Alice or Bob.
So if Bob goes and tells Charlie: Here's something evil Alice said!, then Alice can rightfully say: You could have written that your self!.
And thus: No non-repuditiation.
Alice beware
But: If there is a trusted third party (Alice's employer Charlie maybe) that has a network dump of the entire conversation between Alice and Bob then Alice will be in trouble. Regardless of any non-repudiation properties of TLS. Because Charlie vouches for the authenticity of the original network dump and Bob provides the key to decrypt the conversation. Of course Alice could still say Charlie is in on this! I'm being framed! but she's basically lost then.


How to design an Access Control system that is quick to implement and understand, yet maintainable and flexible enough?

Background

The other comments and answers as well as your post point you in the right direction. You need a framework that is flexible enough to address your current authorization needs as well as future ones. That framework (or model) is indeed Attribute Based Access Control (abac). It's also known as dynamic authorization management and policy-based access control. Gartner, Kuppinger Cole, and Axiomatics (where I work) all have written extensively on the topic:

Why we need Dynamic Authorization Management (2013|Kuppinger Cole)
Technology Overview for Externalized Authorization Management (2013|Gartner)
Attribute-Based Access Control (2018|Axiomatics)
Attribute Based Access Control (2016|NIST)

That said, given your requirements, ABAC only solves half the equation: the authorization policies and logic. It does not solve the attribute management. You still need to think about metadata or attributes of your users or resources (the projects in your case) that will drive the authorization policies you have.

Your use cases

  Read-only users (i.e. some users may only log in and view items)

You would need to define a persona or role that you can assign to users to denote they are read-only. Maybe it's the baseline role in your system. Maybe it's the absence of the role but the fact you successfully authenticated.

  Only a few users may change global settings (like managing
  integrations, billing information etc.)

What makes these users special? A role e.g. "administrator" or "superuser"? You need to define that and you need a process to assign that role to users.

  Only a few users may change settings for one of our three product modules

Same story as above.

  For each created resource (e.g. a project, a team, ...), only the project members / team members may change the resource.

Like you said yourself, this is spot-on ABAC. You would need to write a simple policy (or rule - the words are interchangeable) that states (pseudocode - you could use ALFA too):

A user with role=="..." can do action=="edit" on object of type=="record" if record.assignedProject == user.assignedProject.

  By default, all users may view all projects, but it should be possible to "hide" projects so that only the project members may view the hidden project.

See below for an example in ALFA

Enforcing ABAC

Thinking policies and use cases is great but you also need to think about the enforcement of the decisions. ABAC has a notion of a Policy Enforcement Point (PEP) and Policy Decision Point (PDP). The PEP is where the rubber hits the road: what are you protecting? A web portal? A business process? An API? Either way you need to have a PEP or interceptor in place capable of applying the right authorization. Here's what the architecture looks like from a high-level:

Sample ALFA Code

ALFA, the abbreviated language for authorization is one of the two main standards for authorization along with XACML. ALFA is a simplified notation of the same model XACML follows (policy set, policy, rule). I wrote some samples based on your use case:

namespace com.axiomatics.examples{
    /**
     * Projects
     */
     policyset projects{
         target clause objectType == "project"
         apply firstApplicable
         /**
          * View Projects
          */
         policy viewProjects{
             target clause action == "view"
             apply firstApplicable
             /** Anyone can view a project */
             rule viewVisibleProjects{
                 target clause project.hidden == false
                 permit
             }
             /**
              * Only members can view hidden projects - it should be possible to "hide" projects so that only the project members may view the hidden project.
              */
              rule viewHiddenProjects{
                  target clause project.hidden == true
                  permit
                  condition stringAtLeastOneMemberOf(user.name, project.members)
              }
         }
     }

     /**
      * For each created resource (e.g. a project, a team, ...), only the project members / team members may change the resource.
      */
      policyset records{
         target clause objectType == "record"
         apply firstApplicable
         /**
          * Edit records
          */
         policy editRecord{
             target clause action == "edit"
             apply firstApplicable
             /** Project members can edit a record in their project */
             rule viewVisibleProjects{
                 permit
                 condition record.project == user.assignedProject
             }
         }
      }

     /**
      * Global settings - Only a few users may change global settings (like managing integrations, billing information etc.)
      */
     policy globalSettings{
         target clause objectType == "global settings"
         apply firstApplicable
         /**
          * Administrators can view and change global settings
          */
         rule administrators{
             target clause user.role=="administrator"
                     clause action=="view" or action=="edit"
             permit
         }
     }
}

Implementations

There are several good implementations of ABAC out there:

Open-source

AuthZForce provides you with a XACML-conformant authorization engine
Open Policy Agent (OPA) provides you with a REGO-conformant authorization engine. OPA focuses on infrastructure (Kubernetes, Istio...)

Commercial

Axiomatics (where I work) is possibly the oldest company in the list. We've been implementing ABAC since 2006. Everything's based on XACML and ALFA and we can apply authorization to portals, APIs, and databases.
Oracle, IBM, and other large vendors also have their own solutions.


Are there free online penetration testing labs that I can safely hack with my computer?

Here are my favorites for practice:

GhostSec's pentest labs - Only VMs all hosted online.
VulnHub VMs (only downloadable VMs)
root-me.org is pretty awesome - it's got both web challenges as well as hosted VMs that you can deploy and attack.
hackthissite - name says it all, we app pentesting.
CTF365 - As you've probably figured, they have year long CTFs. It's been some time since I last used them, so I'm not sure if they've started charging for even usage.
hacking-lab
Enigma Group
Hack The Box - A competitive platform.
OverTheWire


What are the security issues with "eval()" in JavaScript?

eval() executes a string of characters as code. You use eval() precisely because the string contents are not known in advance, or even generated server-side; basically, you need eval() because the JavaScript itself will generate the string from data which is available only dynamically, in the client.

Thus, eval() makes sense in situations where the JavaScript code will generate code. This is not intrinsically evil, but it is hard to do securely. Programming languages are designed to allow a human being to write instructions that a computer understands; to that effect, any language is full of small quirks and special behaviours that are supposed to help the human programmer (e.g. the automatic adding of ';' at the end of some statements in JavaScript). This is all nice and dandy for "normal" programming; but when you generate code from another program, based on data which may be potentially hostile (e.g. string excerpt from other site users), then you have to, as the developer for the code generator, know about all these quirks, and prevent hostile data to exploit them in damaging ways.

In that sense, code generators (and thus eval()) incur the same conceptual issues as raw SQL and its consequence, SQL injection attacks. Assembling at runtime an SQL request from externally provided parameters can be done securely, but this requires minding an awful lot of details, so the usual advice is not to do that. This relates to the usual conundrum of security, i.e. that it is not testable: you can test whether some piece of code works properly on correct data, but not that it never works improperly on incorrect data. Similarly, using eval() securely is possible, but it is so hard in practice that it is discouraged.

All of this is said in all generality. In your specific context, eval() might be safe. However, it takes some effort to have a context safe for use of eval(), that actually needs eval().


See communication in WiFi with known password

You need the handshake packages captured. You can force a client to re-authenticate again with a lot of tools so you will instantly get this.

Then you just need a tool that can decrypt WPA and give the key to this tool.

Wireshark is an example for such a tool:


TL,DR: Don't worry, your VM's MAC/Hostname/IP are safe from your ISP.

Your ISP knows the MAC of the modem/router connected to their network, the WAN IP of this router, and nothing else. Anything from your internal network is hidden from them.

Who can see the MAC and hostname and IP from your virtual machines? It depends on your virtual machine network settings. If the virtual network card is defined as bridge, anyone on your local network can see it. If you define as anything else (NAT, host-only, internal network), nobody can see anything but your host.

No matter what, MAC addresses are visible only on the local network. Local MAC addresses don't travel outside of your network. This question have a lot of info on MAC addresses, so you can get a lot of useful knowledge.

Hostnames are only a matter of convenience. You don't want to call your computers by IP address, so you give them any name you want. And outside your network, they don't make any sense either. If your desktop is called darkbox, nobody outside of the LAN can know anything about it, like IP or MAC. Even if MAC and IP addresses on the local network means nothing elsewhere. Probably your computer have an IP from the 192.168.1.0/24 network, like almost everyone else.


If I enter a password on the wrong site, should I consider it compromised?

Just to play the devil advocate...

You are as likely to be compromised as if you were using the same password on both site*.

As most people have pointed, you probably don't have to worry. Not so much because a website cannot make the difference between a good or wrong password but rather because most websites that you will visit will likely not log your password. The reason is simply that it provides no value to them. Most websites are there to do legitimate business and hence see no value in being malicious by recording every password entered.

Still, if I had evil intention and wanted to gather many possible passwords, hosting a service online to gather passwords would probably be a better alternative than trying to brute force every possible combinations. Catching all passwords, even bad ones, is not a bad idea if you are hosting that kind of "service". Users that have multiple passwords are very likely to enter the wrong passwords on the wrong site, hence logging bad attempts as well as good attempt is a good attack plan.

For example consider this quote from https://howsecureismypassword.net/

  This site could be stealing your password… it's not, but it easily could be.
  Be careful where you type your password.

It put things in perspective. Also, is such evil "service" so unlikely? It's hard to say but for sure it's nothing new: https://xkcd.com/792/

Note*: Well, I did say "as likely" but it's not exactly true. By using the same password on many sites you are not only vulnerable to malicious sites but also to the incompetence of site owners. Many websites still store your password in plaintext in their database or use weak hashing, which means that if an attacker is able to steal their database your password is compromised.


Is signature based malware detection a thing of the past?

Signature Based Malware is still the dominant mechanism used.

Heuristic mechanisms do exist and are very useful in limited circumstances, but are subject to too many false positives for more general use.

What has happened in the AV industry across the board is an application of "Big Data". It's no longer a case of just checking against a database of known bad signatures. Most AV vendors, including Microsoft, will check the hash of all executables. That hash check can have three main results:

Known Bad (Isolate,  Done!)
Know Good (continue, Done!)
Unknown  (Scan for virus signatures)

A. Signature Found (Isolate,  Done!)

B. Send a copy to the AV Vendor for Analysis

The immediate enhancement over your example test AV is the incorporation of Known Good hashes.

The less obvious but very powerful enhancement is the Big Data factor. When the AV company is doing this all over the world against billions of files, the chances of any given individual encountering a new 0-day drops dramatically, although it does still happen.

If you make your own executable, malicious or not, the third case will kick in. Microsoft, or most other large AV Vendors, will pull a copy of your executable and send it to their analysis teams. Here they will use heuristics during analysis and depending upon complexity, it will be fairly quickly entered into the worldwide database of executables.


Vulnerability Assessments - Vulnerability Taxonomies?

MITRE has a few systems for this. CVE for things that need patching; CWE for bugs that need to be avoided/fixed, CAPEC describing attacks to your infrastructure; CCE for configuration needs; CPE for a proper naming scheme; and CEE for event exchange information.

http://makingsecuritymeasurable.mitre.org

You'll find links to other resources that work along with MITRE's standards or are similar in nature to them.


Securely erasing USB flash drives from a bootable media

That will do the trick just fine if you just want the data unreadable by connecting the drive to a computer (an alternative to your command is to use shred : shred -n 1 -v /dev/sdX).

What's more problematic is that data may still be readable by extracting the flash chips, dumping them and then reconstructing the partition layout (not the partition table your PC sees, but the raw table the drive's controller uses for wear leveling).

On a flash disk simply overwriting the data multiple times doesn't have any effect because the internal wear leveling mechanics don't guarantee that the data you overwrite it with will end up on the same physical block of the flash device.

One solution would be to use the secure erase command supported by some SSDs (sadly I don't think it's supported for USB flash drives) and even then, nothing guarantees that the manufacturer correctly implemented the command.

Another solution I thought about would be to overwrite the drive a lot of times (write 10x its capacity), so that even if wear leveling mechanics come into play each block of the flash device will be overwritten at least one time; but that would wear out the device quite a lot and may even kill it.

Until the secure erase command is guaranteed to be reliable, the best solution for secure data destruction is this.


What are the pros and cons of using a password safe instead of writing passwords on paper?

The biggest advantage of a software password vault over writing it down on paper is that the data is encrypted with a secret that you store in your head. If the secret (password) is strong enough, it should be next to impossible for an attacker to break into it through bruteforce. The other benefits you list such as easy to search, organize, backup and distribute are just secondary benefits IMO.

Writing down the passwords on paper offer no such benefit. For it to be remotely usable, the paper has to be in your desk or wallet where it is relatively easy to get to. Sure, you can stick the paper in a physical safe and make it difficult to steal, but it's a hassle from a usability perspective.

Another major benefit of using a software password vault is that it almost entirely removes the risk of falling prey to a phishing attack. Most password vaults come with features that allow you to fill in the credentials automatically when you visit the correct website. This removes the possibility of a user being duped into entering the credentials into a phishing website by accident.


A new programming paradigm (e.g., Rust) to reduce or end all zero-day vulnerabilities/exploits?

0-days are gonna be a thing as long as humans are making software.
A single exec/eval is often enough for an exploit. Using memory-safe languages like Rust or high-level languages mostly remove memory issues but introduce entire categories of attack vectors, e.g. Code Injection for interpreted languages like Python. There's also logic errors, such as TOCTOU errors, off-by-1 errors, and forgetting to check certain parameters.
Putting malicious code in your software because you copy-pasted some code from a stranger on the internet without checking the code or accepting a pull request made by a malicious or newbie programmer is another way you can introduce bugs to your code without knowing.
Humans are prone to mistakes and will continue making dumb mistakes, whether you like it or not. 0-days aren't just memory issues, they're often logic bugs that can't be caught by software and need to be checked by people.


A FIDO U2F Device relies on public/private keys. Do they expire like in regular x509 certificates?

No, they do not expire.  Probably mainly because x509 relies usually relies on external authority, whereas in FIDO U2F you issue your own pair.


How much is ASLR effectiveness impacted by different ABIs?

May be this will give you more information :

Wikipedia

  Address space layout randomization

  Effectiveness

  Address space layout randomization is based upon the low chance of an
  attacker guessing the locations of randomly placed areas. Security is
  increased by increasing the search space. Thus, address space
  randomization is more effective when more entropy is present in the
  random offsets. Entropy is increased by either raising the amount of
  virtual memory area space over which the randomization occurs or
  reducing the period over which the randomization occurs. The period is
  typically implemented as small as possible, so most systems must
  increase VMA space randomization.

  To defeat the randomization, attackers must successfully guess the
  positions of all areas they wish to attack. For data areas such as
  stack and heap, where custom code or useful data can be loaded, more
  than one state can be attacked by using NOP slides for code or
  repeated copies of data. This allows an attack to succeed if the area
  is randomized to one of a handful of values. In contrast, code areas
  such as library base and main executable need to be discovered
  exactly. Often these areas are mixed, for example stack frames are
  injected onto the stack and a library is returned into.

ASLR makes the job of exploitation much more difficult but not impossible. I don't think the number of register increases the effectiveness of ASLR. If you practice vulnerability exploitation you will see that jumping/finding to the right address in memory to your shellcode is very difficult with ASLR even with NOPs. If the stack is not executable (DEP) its even more difficult and return to libc technique is used.

Another similar topic

Additional information also here


How can I distribute highly confidential keys for a symmetric cipher?

For your problem, the easy way coming to my mind is PGP: both the sender and the receiver exchange asymmetric keys and can then send each other private messages. You can validate each other pulic key other the phone to make sure no one messed with it (see MitM).

For all I know, using WhatsApp or Telegram might also be secure enough as they use end-to-end encryption (the message decryption keys are on your phones only).


Can I use the RSA algorithm so that the receiver does not know how to decrypt it?

You could embed the identifying data in the image, and then encrypt it with a private key (whether RSA or another asymmetric cryptosystem).

Then, everybody can use your public key to decrypt the information that you hid in the image... once you've told people it's there. This would prove that you had hidden some information in the image before it was leaked.


How to encrypt an entire portable HDD, so that it cannot be read/written without the password for it?

Edit TrueCrypt is now defunct. So this answer requires work...

TrueCrypt is what you're looking for.

Other (paid) solutions include PGP Desktop, and Jetico BestCrypt.


What is a reasonable approach for deidentifying data?

I genuinely don't think we have enough information - and it sounds like you don't either - on what exactly your client wants. Part of your problem is not just deidentification, but deidentification that maintains the data's usefulness. The second part is as tricky as the first.

  Ok, assuming the answer is no, what if I then choose a random birthdate and adjust the admission and discharge dates so that age at admission and length of stay are still the same? For example, if the patient was born on 1/1/1930 and was admitted on 1/1/2011 and discharged on 1/10/2011 the birthdate could be randomly chosen as 5/5/1920 and the other dates would be 5/5/2001 and 5/14/2001. The age at admission and length of stay would be the same. Would this be reasonably deidentified?

For example, this solution, while it might technically have changed the PHI so it cannot be tracked back to a particular individual, has ruined any and all time related usefulness of the data that isn't just the difference between the admission and discharge date. An analysis of the data could not, for example, adjust for what season of the year the admission was in (important for many diseases) or even what year the admission was in (important for all kinds of things).

  Also, one other question. If the client has a list of patients with their birthdates in an excel spreadsheet (no other information), would that data be considered PHI? My client says yes, but that doesn't make sense because no medical information is tied to those names.

We don't know who your client is, but considering the site you're asking this on, the answer is absolutely yes. The existence of these records implies certain medical information. Consider three circumstances, of varying risk to the patient if exposed:

Patent X is on Clinic Y's list. They must have gone there.
Patient X is on Clinic Y's list. That clinic does STI screening. I wonder what they were up to?
Patient X is on Clinic Y's list. That clinic is helping administer an HIV prevalence study among high-risk sex workers in the area. Isn't that interesting...

All of those could be assembled with nothing more than a name and birthdate, and the existence of the list itself. "Shows up on in a healthcare provider's records" is medical information.


I was using this PC for development and didn't tell or use it for any communication purpose so it's not possible that someone knew about it

The entire Internet is regularly port scanned, both by malware, attackers and researchers such as shodan.io. You can not expect any service accessible to the Internet to be unidentified for more than seconds after connecting it.

If you make anything available, secure it. Keep it patched. Disable unneeded features, and so on. Protocols that have a high impact and poor security record, such as RDP, should probably not be exposed directly, but shielded via for instance a VPN, or a SSH tunnel, so that the service is not externally accessible.

Your question is like asking why anyone broke into your house, when you didn't advertise the address in the newspaper or phone book: someone saw it there, and decided to break in.


POST is more secure than GET for a couple of reasons.

GET parameters are passed via URL. This means that parameters are stored in server logs, and browser history. When using GET, it makes it very easy to alter the data being submitted the the server as well, as it is right there in the address bar to play with.

The problem when comparing security between the two is that POST may deter the casual user, but will do nothing to stop someone with malicious intent. It is very easy to fake POST requests, and shouldn't be trusted outright.

The biggest security issue with GET is not malicious intent of the end-user, but by a third party sending a link to the end-user. I cannot email you a link that will force a POST request, but I most certainly can send you a link with a malicious GET request. I.E:

Click Here for the best free movies!

Edit:

I just wanted to mention that you should probably use POST for most of your data. You would only want to use GET for parameters that should be shared with others, i.e: /viewprofile.php?id=1234, /googlemaps.php?lat=xxxxxxx&lon=xxxxxxx


What is "cardholder data" in PCI-DSS SAQ A context?

From the comments it appears that your question is essentially this: Why is paper documentation of a transaction treated differently than electronic replies or documentation from a transaction, at least in terms of those documents containing full, unencrypted PANs? (Meaning full, unmasked credit and debit card numbers.)

Well, my first response is simply this: ideally merchants shouldn't keep materials with full PANs on/in them, even in paper form . Although the PCI Requirements that apply to SAQ-A merchants do not prohibit having cleartext card numbers visible on paper documentation, they do impose requirements that you need to pay attention to in terms or the creation, storage, handling, use, and destruction of such paper documents. For more complete information on those requirements see "Can we print cardholder data under the PCI DSS Compliance framework and stay compliant?" But the bottom line is that creating, storing, or even just receiving printed materials with full PAN data in them at best creates more compliance and security headaches for you, and at worst, of course, increases the risk that card data will be compromised.  Thus, unless you really, really have a special, unavoidable need to receive and temporarily store card numbers on paper from your processor (and frankly my mind is blanking on thinking up any scenario where that would be true) the best way forward is simply not to receive or store them at all.  And frankly if you're dealing with a payment processor who is sending you paper material with full PANs in it without an exceptionally good reason I would firmly advise that you to take another good look at whether you want to stick with that processor.

Secondly, if we're pondering the question of why you might be allowed to store clear-text card numbers on paper at all when you are forbidden from doing so electronically, well the answer to that is straight-forward enough: the Internet is a dangerous place, and any machine connected to it is exposed to that danger. Any machine or network that psyically has an electronic connection is exposed, in (in theory) to electronic attack from any of the more that two billion people who now have some kind of access to it, from every corner of the world. Tireless automated scanning tools or human attackers checking the security of every merchant that they're aware of the existence of can check the router that ties your small network to the Internet for security configuration problems. Problems that can allow and attacker to access everything on your network as if he or she was physically in your building/s and plugging in with an Ethernet cable or connecting to your wifi.  Automated phishing campaigns bombard hundreds of thousands or millions of users with emails containing links that lead to websites serving malware or come with attached files that are infected with it.  In either case, an attacker again gains access to your internal network or, worse, is able to get a copy of any card numbers that are entered in to an infected machine or even any card numbers that ever come into its memory, even for a few seconds.

By contrast, paper documents are simply not as exposed to bad guys to the same degree and in the same way. Only people who know that you keep the data and where can deliberately try to steal it, a far different situation--though still a concerning one-- than a situation where PANs are kept as electronic information on a device that can interact with a network that two billion people. (And lots of electronic scans running on it from bad actors, hunting for weakly defended systems and improperly-secured financial data on them.) That being said, as discussed above the better practice, by far, is not to store any unencrypted card numbers anywhere in your operations, whether in electronic or paper form.


It sounds like you are worried that your users enter their credentials on another page than your real login page. In your case this is because the web application is hacked, but this is more commonly achieved by phishing attacks, so you may want to look into solutions against phishing.

There are a couple of ways to ensure users only authenticate on the correct domain:

U2F hardware tokens. This is a USB dongle with a cryptographic key on it.
Using a password manager that only autofills credentials when on the correct domain.
Training users to recognize phishing pages, such as checking the URL.

Edit: Using two-factor authentication such as TOTP or SMS tokens don't prevent phishing, since the phishing page can also ask for these. It makes it a little bit harder since the attacker can only log in once with the captured credentials.

U2F is different in this respect, because of crypto. The token creates a signature of the domain name. The captured credentials only work on the phishing page and not on the real login page, so the attacker can't log in.


How to convert this .NET cryptography code to openssl command?

The following should perform the same effect for you, where rsa_cert_private.key is the private key in your keypair, and sign.txt is the message you wish to sign.  The result will be a new file sign.txt.sha256 that is the signature based upon the sha256 digest of the original message.

  openssl dgst -sha256 -sign rsa_cert_private.key" -out sign.txt.sha256
  sign.txt

but at this point the signature is in binary form, to get that over to base64 you'll then want to

  base64 sign.txt.sha256 > sign.txt.sha256.txt

which will create a 2nd new file (sign.txt.sha256.txt) that is the exact same signature content but in b64.

To verify the signature you would first need to get it back into a binary sig

  base64 -d sign.txt.sha256.txt > sign.txt.sha256

but it is easier just to leave it in binary the whole time instead of taking the extra steps and (admittedly minuscule) extra space to store it in base64.


You can refer to this document http://dl3.checkpoint.com/paid/a6/CP_R75_IdentityAwareness_AdminGuide.pdf?HashKey=1406609615_673007d65df939c943ee67df223fe99e&xtn=.pdf.

It is checkpoint's feature to do what you want.

The basic idea is simple.
Monitor DC's windows event log for user's logon message. There are specifc event types for user logon event. There is IP and user binding info you need in the log message.

For multiple domains, you need monitor all DCs of the domains.


How does Nautilus store passwords on Ubuntu?

Under the default configuration in Ubuntu, passwords are stored in the GNOME keyring. This applies to all passwords stored by Nautilus, as well as most other applications including web browsers.

(Let me reiterate: default configuration, most. This can be changed and there are applications that don't support the Gnome keyring.)

You can use the Seahorse GUI program or the secret-tool command line utility to view and modify the contents of the keyring.

There is some official documentation about Gnome Keyring, including a “security philosophy” and a more concrete security architecture.

Data in memory (“Remember password until you logout”) is present in the memory of the gnome-keyring-daemon process, which allows any process running as your user to query it. Gnome-keyring avoids swapping if possible; however, if you have any encrypted storage, you should have encrypted swap, because the programs that manipulate the confidential data could themselves be swapped out.

Data on disk (“Remember forever”) is stored in the file ~/.gnome2/keyrings/login.keyring. It is encrypted with a key that's derived from a password; normally, that's your login password, and Ubuntu is set up to unlock the keyring with your login password. The key is derived from the password with a salted, slow hash but I don't know exactly what the derivation function is.


Encryption - should I be using RSA or AES?

Neither, unless it's both. You're asking the wrong question. You should not be thinking about a cryptographic algorithm at this stage, but about a cryptographic protocol.

Cryptographic protocols are hard to design, and a frequent source of security bugs. You don't fully understand public-key cryptography, so you aren't ready to use it in your own cryptographic protocol.

At a high level, your model is amenable to public-key cryptography (e.g. RSA). Let every client have its own private key and publish its public key to the other client. A client's private key does not change over time, unless the client has been compromised. Symmetric cryptography (e.g. AES) would not scale well here because each pair of clients would need to have its own secret key.

Use existing software whenever possible. Implementing cryptographic protocols is almost as tricky as designing them. For a model where clients occasionally send messages to one another, email-style, a tool that would work well is GnuPG. (For bidirectional communications, use SSL/TLS.)

So: for day-to-day operation, to send a message, call gpg, encrypt with the public key of the recipient, and while you're at it sign with the private key of the sender. When receiving a message, check the signature against the purported sender's public key, and decrypt with the private key of the receiver. In other words, send with gpg --sign --encrypt -r NAME_OF_RECIPIENT  and receive with gpg --verify followed by gpg --decrypt.

The remaining problem is that of key distribution. After a client has generated its key pair, it needs to inform the other clients about it and distribute it without allowing the public key to be intercepted and replaced in transit by an attacker. How to do this depends a lot of your precise scenario. Don't neglect the security of this part.

If, and only if, invoking GnuPG proves to be too slow, then consider using a lighter-weight, perhaps home-made implementation of a similar protocol (going from e-mail range overhead to SMS range overhead). Under the hood, GnuPG generates a symmetric key for each message, because public-key cryptography is expensive for large messages; the public key algorithm is only used to encrypt the symmetric key and to sign a digest of the file. You should follow this model. Using AES for symmetric encryption, SHA-256 as the digest algorithm and RSA as the public key algorithm is a good choice.


You can use Azure Key Vault in conjunction with Azure Blob Storage enabled with customer-managed key to meet this requirement.  When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Customer-managed keys offer greater flexibility to manage access controls.

The following list explains the numbered steps in the diagram:

An Azure Key Vault admin grants permissions to encryption keys to the managed identity that's associated with the storage account.
An Azure Storage admin configures encryption with a customer-managed key for the storage account.
Azure Storage uses the managed identity that's associated with the storage account to authenticate access to Azure Key Vault via Azure Active Directory.
Azure Storage wraps the account encryption key with the customer key in Azure Key Vault.
For read/write operations, Azure Storage sends requests to Azure Key Vault to unwrap the account encryption key to perform encryption and decryption operations.

https://docs.microsoft.com/en-us/azure/storage/common/customer-managed-keys-overview


How worried should I be about getting hacked with PoisonTap?

First the attacker needs to have physical access to the machine in order to plug the device into the USB port. This means any kind of full remote exploit is not possible. It does work though if the computer screen is locked with a password or similar. Note that the physical access does not need to be direct, i.e. it can also be some gullible user plugging a donated USB stick into the system.

Then the device announces itself as a USB ethernet device. This means that the computer will try to add PoisonTap as a network device to the system and get an IP address from it using DHCP. The DHCP response will return an IP address with a /1 subnet so that most IPv4 traffic is sent to the device. From then on the attacker has the same access to the device like a router: in fact the device works as a router for the attacked computer. This means that any traffic can be easily sniffed and modified but that encrypted connections are still protected against decryption and modifications get detected. This means for example that access of gmail over https (the usual way) will not be compromised.

At the end it is just another way for a local attacker. The impact of the attack is comparable to redirecting someone's traffic via ARP or DHCP spoofing, hijacking the local router or a rogue access point. Not more can be done as with these attacks but also nothing less. It looks like that the software comes with some nice attacks which modify unencrypted HTTP connections to access different sites in order to poison the browsers cache with heavily used scripts (like a poisoned google analytics etc). Since many sites include such third party code and such code gets access to the full page a poisoned code can extract lots of useful information. But again, this works only for HTTP not HTTPS.

  Is the general population at risk, or only a very specific subset (os,browser?)

Most current systems are at risk but the attacker needs physical access.

  What exactly is at risk, your data, your gmail account ...?

Sniffing and modification of unencrypted connections. Gmail usually is encrypted and thus not affected.

  Is it something that most people can pull off, or does it depend on specific hardware and a high level of skill?

It needs special hardware and software but the hardware is cheap and the software released. It needs about the same level of experience as attacks like ARP or DHCP spoofing, i.e. script kiddies could do it.

  Is there something that one can do easily, without closing all browsers or turning off the pc each time when you walk to a different room to ask a short question. (Is locking it sufficient?)

The usual protections against other USB based attacks still work, i.e. disable USB or restrict the kind of devices. But note that if the device has an ethernet port you could mount a similar attack through this since any kind of wired connections is preferred to wireless by most systems.


Encrypt DB Fields preserving search functionality

I would actually not advise encrypting something like a user id. There should be practically no risk to anyone seeing it and you're really making a lot more work for yourself than necessary. An id identifying a user is not what I imagine a lot of people are going to call "sensitive information".

I'm actually having a hard time trying to think of a case of sensitive information that you would like to use a WHERE clause on in SELECT. I wouldn't never want to search against SSNs, for example.

If you wanted to compare user input against something like an SSN there's generally other information such as name and DOB that's entered alongside the SSN. I would pull all records out into an array with that match that information (name, dob) and then check any resultant entries with the SSN provided and the SSN from the entry, decrypted.


Should I use SSL in a secured file sharing service?

Yes, please use SSL to secure the transport channel you're delivering the files over.  Crypto is hard, and you should never try to implement your own.  For more information on exactly what SSL is, please see: How does SSL/TLS work?


Does using VPN improve security when connecting to a HTTP website?

Let me split up your questions and hopefully it will make sense...

When I use my VPN (ExpressVPN) connecting to a site that use only http, is that something i need to worry about?

A VPN is an encrypted tunnel between your computer and the VPN end point, in this case the ExpressVPN servers in the country you connect to. Any internet traffic is therefore encrypted (people could intercept it but wouldn't be able to understand it) until it exits at the ExpressVPN server.
One advantage here is that even if people (governments, etc.) are monitoring what comes out of the ExpressVPN server you connected to, they won't be able to tell that it was you that sent it. Just that some traffic has emerged.

Quick edit: As noted by someone in the comments (thanks!) - any traffic to http sites will be visible to someone monitoring. So while the source of the traffic will look like the VPN server, the traffic itself could contain info to tie it back to you (e.g. names, ip addresses,...).

One obvious use of VPNs is to access region locked content in other countries as the content provider thinks that your computer is actually in the same country as the ExpressVPN server you connected to.

Lets say i talk to someone on a site that only use http, will the messages be easily traced back to the sender?

What is the difference in privacy/security when connecting to a website that use http vs https when I am already connected to a VPN server?

Let's take https connections first... if you are connecting to a https site via a VPN then communication is still 'further encrypted' between the ExpressVPN server and the https site. i.e. effectively encrypted the whole way from your computer to the https site but going via the ExpressVPN server.
If you are communicating with an http site then someone could be intercepting and reading the connect of the traffic but would only really be able to tell that it was coming from the ExpressVPN server and not from you or your computer. So you are probably okay.
However, if that http site requires a login and it is poorly designed it could link your message back to you if you have previously logged in without using the VPN.

The explanations above are quite simplified and there is a lot that could be discussed about the various encryption technologies.

Another important consideration is whether your VPN logs what you do. Most good ones don't. There are various VPN ratings pages you can find including this one from the EFF in 2013 (couldn't find a newer version but I only looked briefly) which will tell you more about what your VPN does and doesn't keep track of. If your VPN logs your activity then they could be passing it on to others or selling it.
General rule of thumb is that if you are using a free or very cheap VPN then the price you are paying is your privacy - they are likely making money from selling on activity details. A lot of people don't care about this as they just care about accessing region locked content.

P.S. For what it's worth, I'm in the UK and with the passing of the 'snoopers charter' I won't be doing anything without a good VPN going forward as our ISPs will be required to log all activity metadata which will be searchable by ANY law enforcement official (including my neighbourhood policeman) without a warrant!


Which host key algorithm is best to use for SSH?

Currently,

RSA is still recommended as a gold standard (strong, wide compatible)
ed25519 is good (independent of NIST, but not compatible with all old clients).

Server is usually providing more different host key types, so you are targeting for compatibility. The order of priority in the client config is from the stronger to more compatible ones.

Frankly, for you, as an end user, it should not matter. Some of the keys might have some security concerns, but none of them is considered completely broken with reasonable lengths, which could possibly cause man-in-the-middle attack or something similar.

The article mentions "severe vulnerabilites", but not saying anything specific. If it had such serve vulnerability, nobody would use it, support it, nor recommend it. Without any reference, it is pretty hard to comment on your concerns.


How does Burpsuite sitemap (find) this PHP file from a PortSwigger lab?

Yes, Burp Suite looks at comments to locate potential directories and pages, even if they do not exist.
I installed Burp Suite fresh, default config, and a fresh XAMPP on my machine and added the comment:
<!-- TODO: Refactor once /questions/237693/fake.php is updated -->

to the default index.hmtl page and browsed to the main page to trigger Burp's passive crawling. Nothing else. I did not create the path or the file nor did I try to navigate to that location.
This was what was added to the Burp Suite sitemap:


Is it reasonable to allow Google sign-in for people who signed up "normally"?

Yes, many websites do allow this by allowing you to link a local account with the Google Account. You should send email to the old account's email address, requiring a confirmation click/code from that email, rather than requiring/assuming the same email. Security wise, this is no different than a password reset via email.

Next is that you can allow user to optionally disable local authentication and just use Google Account authentication. Give the user the option, as some users may want to sign in to your site using shared/public machines without having to authenticate to their email account so local authentication can still be useful in this case.

When a user is signing up for a new account, you can notify the user that that there is already an account with the same email with a different authentication method. You can then prompt them to sign in or reset the password on the old account to link the account to the new authentication method. For new users, they should also be allowed to create an account with just Google Account authentication, without creating local authentication.


Which algorithm works well for encryption of large datasets?

Depends on what you're trying to secure it from. I would say that, generally speaking, AES-128 is a good compromise between fast and strong, and there's a lot of hardware support for AES available, which helps to speed it up.

I assume you're not trying to protect it from a state actor or someone with similar resources who want to gain access to your data? If so, you might want to consider longer key sizes and/or chaining other encryption algorithms.


Android app is the only party authorized to decrypt

Whenever you write software that runs on hardware you do not control (e.g. an app installed on a user's phone), you can assume that everything related to the app could be visible to the user, if the user is knowledgeable. This includes code/functionality, which can typically be decompiled, or any data received/transmitted/processed by the app, which could be dumped from memory or captured over the network.

You can certainly make it more challenging by using obfuscation, anti-RE/anti-debugging techniques, and plenty of crypto. This may be enough to foil a casual user with some basic skills, but a determined adversary will eventually bypass these measures.


These things are normally done programmatically. The command-line apps from OpenSSL are restricted in many ways, and don't give access to the full power of the underlying library. If you look at the source code, you will find the implementation of the req command in apps/req.c. For subject name parsing, that command relies on the parse_name() function (defined in apps/apps.c). That function internally builds the name elements as so many null-terminated C strings, which, by definition, cannot contain a null byte. Therefore, no possible way to achieve what you seek with that tool alone.

So one option is to simply download OpenSSL's source code, patch apps/req.c to include a null byte where you want it, compile it and run it. This will require a bit of knowledge of C. You will want to use the X509_NAME_add_entry_by_txt() function (or one of its acolytes), with an explicit len parameter (not -1) to use as "string" a sequence of bytes which includes your null byte. If you look at parse_name() in apps/apps.c, you will see that it invokes X509_NAME_add_entry_by_NID() with len set to -1: that's the exact point that you'll want to change.

Another option is to generate a "normal" certificate request, with another letter where you would like to have your null byte (e.g. a 'Z'). Then, make sure to convert your request to binary ("DER") format; then use a binary file editor to replace the 'Z' with a byte of value 0; then recompute the signature so that it matches the new request contents. This last step can be done with basic Linux command-line tools (dd for file surgery, sha1sum to get a new hash, dc to do the big integer arithmetics) but you have to master both ASN.1/DER and PKCS#1, and if you did then you would not have asked the question you asked.