A list of the various tests used are provided in the mmap documentation at http://nmap.org/book/osdetect-methods.html#osdetect-probes-seq. For more specific details you'll have to read the source code.

Essentially various different probe packets are sent and the results analysed. Slight differences between TCP/IP software mean there are sometimes slight differences in the response to certain probe packets. With enough tests you can put together a fingerprint that identifies the OS very accurately.

An example might help. If you receive a TCP packet from a host, it contains a number of header options. The definition of the TCP protocol in RFC793 doesn't specify what order these options should be put in. So if the person who wrote the networking code for BeOS put those options in a particular order, and you receive a packet with the options in that order, then you can deduce that the packet might have come from a BeOS host.  That may not enough on it's own to be sure it is BeOs; perhaps the TCP stack in Haiku puts the options in the same order. So you have to find some other test that gives different results for a packet from BeOS than it does from Haiku.


How to encrypt data with a one time password?

OTP is not made for that. OTP is used as a second factor authentication to avoid a leaked password compromising the whole account, and is usually rate-limited, and usually locks itself during a small interval if mismatched (I've seen one minute lock after 3 errors). That is the main usage for OTP.

Encrypting with OTP does not make sense. As the token you enter is usually 4-8 digits long, bruteforcing it will be trivial. You cannot rate-limit a decryption routine, so nothing stops an attacker to try every possible digit very, very fast.

Even if you create a system that protects the key somehow, an attacker can tamper with the clock and send all possible combinations.


Security concerns about purchased PHP script (web app)

Unless the company tells you that they have been audited by some security company (and depending on the company that assessed it), you will never know until you take a look for yourself.

Trust is a complicate thing... It is hard to gain and very easy to be left along the way.

One think that you may do is talk to Agriya and tell them that you're interested in their products, but wary about the secure development practices employed by them. Ask them if they have made a thorough security assessment in the softwares and if the answer is "No", ask them what would they do if anyone finds bugs in it.

@jeroen-it-nerdbox raised an important issue. These things might cripple your business and a strong AND fast correction process is of vital importance for you and their customers.

About the price of a security assessment in the code, it depends on the company doing the audit. My department does not have ties with the commercial area of the company, so i cannot help you with that.


How To Stop A Mobile Verification Attack

Something that you might consider is a cool down period for an IP after it requested the SMS verification. This would not solve a distributed attack as indicated in the question but would to a large extent limit the effect of a single origin attack. The effectiveness of a  distributed attack would also be reduced to some extent.

Although this might not be the best or final solution to your problem it is something to consider as an additional layer of your security.


How to protect against viruses that takes files as hostages by encrypting them?

To protect against this, you need some sort of versioned online backup. Where all Changes are saved as a difference over the old backup, and you can Always rollback to any date/time.

Basically, your versioned backup should work that regardless of what you do on the backup, its copy-on-write and you will Always be able to revert.

This can either be as a incremential file-based backup on a backup server or NAS, but you can also do this on block level with LVM/snapshots on a backup server, such as you store differential snapshots over the filesystem so you can Always recover any of these snapshots prior in time.

The important thing to consider, is that the incremential versioning system MUST be implemented on server-side. Eg, present a shared drive to the client computer. Anytime a file is written to this shared drive, the SERVER (that is inaccessible to the virus) checks if that file already exists, and writes a incremental diff file on the server drive for this file if it already exist.

Thus anything the virus does to the shared drive will Always be saved as a incremential diff.

Only allowing "trusted" software to execute is basically impossible on both Windows and Linux, since a OS has LOTS of executeable code that is executed part of the operating system. In all these executeable code, theres Always entry Points where modules can be connected and executed, and closing off all these entry Points are basically impossible. One example of entry Point is registrering a executeable DLL from regsvr32.exe . Only way you can do is restricting executeable software from modifying certain files, but that also means you have to prevent yourself from modifying that file too, since anything you can do, the virus can do too.
The only way you can completly lock out untrusted code is by using a microcontroller, and thats EXACTLY why smart cards exist!


How to prepare a used computer to handle sensitive information

For a “normal” computer (eg. may be infected but has no extra malice), booting from CD/usb, wiping the disk and performing a complete reinstall should be enough.

Now, if the CIA is (knowingly) selling you the hardware where you will be storing the location of Russian submarines, you better throw that hardware away. It could do anything from sinply giving you an infected BIOS to modified hardware that sends every single computation performed by your cpu to the team that is performing a TEMPEST attack behind your window.

This reminds me the (probably wrong) information reporting that Russia gave infected usbs to G20 leaders. You can't really be sure you completely cleaned an infected hardware. http://www.telegraph.co.uk/news/worldnews/europe/russia/10411473/Russia-spied-on-G20-leaders-with-USB-sticks.html


This is a bit of a load question with a few different parts, but I think it is answerable overall.

Is there a Hacker Ethos

Yes and no. The main problem is the wide diversity of hacker groups that differ by targets and thus ethical code. Just to name a few: white hats usually follow the "do no harm"-type of ethics and try to close security-leaks. Regarding red- and black-hats things become quite a lot more complex, a short summary will show that: Of course (what a surprise) there's the "there's money in it? I'm in."-type of hacker, which doesn't care about ethics. On the other hand, there are as well politically active groups - e.g. Anonymous declared war on IS (opinion on results differs) - that of course follow a kind of ethical code. Or the classical cracker that's trying to break copy protection and follows the communistic principle of "everything should be available to everyone". Some groups add loyalty to the group to their ethical code. In short: some follow a ethical code, some don't. The diversity of ethical codes is gigantic, so expanding further on this topic doesn't make much sense.

Disclosure

When disclosing a discovered vulnerability to a company, there are three main disclosure policies that the community has.

Full disclosure: Release the details of the vulnerability along with a PoC. Some prefer this method because companies are not always friendly to being told they have data-exposing security holes and throw lawyers at people rather than fixing the vulnerability. Some companies pretend the problem isn't there or fix the problem without properly crediting the person who did the work.
Responsible disclosure: Work with the company to identify the root cause, own validation of the fix, and then release the information after a patch has been written. Rain Forest Puppy is one of the original people who released an accepted policy on when to consider responsible disclosure a lost cause and release the details. It's a hard balance to strike.
Fully silent: This means having NDAs and lawyers, and sometimes court orders, gag the person from saying anything at all.

The balance is hard. If I find a security vulnerability, I want the company to fix it. But there are companies who are on a personal blacklist, that I have dealt with before and are extremely disrespectful to researchers. Those companies will get a full disclosure. What about the ethos? Researchers are balancing getting a fix out before the criminals exploit it, and letting it go unfixed and the criminals finding it and exploiting it. It's a judgement call, and one that isn't easy.

Selling vulnerabilities and exploits

There is a lot of discussion in the community and outside of the community on the ethics of selling exploits. My intention is not to start a war, but to provide as independent viewpoint as I can provide without letting my personal opinions influence anybody.

When we talk about ethics, there are two main viewpoints:

Sell, and get money for your hard work: If I spend hours and hours and hours of work finding a vulnerability, I want to get paid for my hard work. It's something the vendor should fix, and an independent can broker that communication for me, influencing the responsible disclosure without me having to worry with lawyers.
Don't sell, because I don't know who may get the exploit. Increasingly, nation states are attacking each other, influencing trade, nation secrets, and more. I don't want my exploit falling in to the hands of a nation state.

Okay, really, is there an ethos?

Personally, I think no. There's the Hacker Manifesto which you can find on the internet and read. It's a good read. But at the end of the day, my security skills and how I use them are a reflection of who I am and not the other way around. I don't put people at risk intentionally. There are unspoken rules, and I've mentioned some of them above with the disclosure policies. The biggest one in the community, and you will get called out for it because the community is awesome like that, is don't be a jerk. If you are a jerk, you'll get tossed out. We don't like people who are jerks. If that's your takeaway, then I've communicated what I wanted to.

Certified hackers?

Who can do that? Well, in the community, there are several recognized bodies that teach and provide certificates for various subjects in the community. Up to now, I've been speaking about offensive security as that's my background. But there's also incident response, for example. Here's some recognized bodies in the industry:

https://www.sans.org/ - GXPEN, GPEN, and other certs.
https://www.eccouncil.org/ -  C|EH, CNDA, and other certs.
https://www.offensive-security.com/ - OSCP*, OSCE, OSEE, and other certs.

*I have the OSCP.

These are recognized bodies for a few reasons, but one thing they all have in common is if you do anything contrary to the ethics they set forth, they'll strip your certification.

Who says they can do this?

Nobody, really. I can create a company, offer a certificate and training, and that's it. But pretty soon the industry will know if you are a paper mill, or actually offering substance. The three I mentioned above are recognized because they offer substance, albeit in different areas and in different skill levels.

Recommended Reading

This is a broad question, so I attempted to offer an answer that is not skewed by own experiences. But there's plenty of reading out there. I've given a few links, so search away. You'll see that there are very valid but almost contrary viewpoints on the ethics of hackers. My suggestion at the end though is don't be a jerk. Nobody likes a jerk.


From a description of bcrypt at Wikipedia:

  ... The rest of the hash string includes the cost parameter, a 128-bit salt (Radix-64 encoded as 22 characters), and 184 bits of the resulting hash value (Radix-64 encoded as 31 characters)

Thus, the salt is automatically included in the output string which means there is no need to add it by yourself.


Can a business with a single employee gain ISO27001 certification?

The short answer is that, yes, an individual can get ISO 27001 certification. As the old joke goes, you can ISO 27001 certify a chair...
All the details you wish to know you really need to ask an assessor.
You might find, however, that the costs of obtaining certification are far greater than the potential benefits because you are an individual. Writing policies, establishing processes, auditing those processes, etc. all take time and resources, which you will not be spending working or bidding for contracts.
But your assessor will have all your relevant details.


Why are buffer overflows executed in the direction they are?

Crash Course in Computer Architecture

In an Intel x86 and x64 architectures there is something called the stack.  This is essentially where everything to determine the execution path is stored.  Parameters to functions, local variables, and return addresses are all stored on the stack.  CPU registers keep track of where in the stack the program is executing.  You can push values and memory addresses onto the stack up to the architecture's bit-size.

What do I mean by that?  If you're on a 32-bit system, then each value you push onto the stack will essentially be an unsigned int 32-bits in size (4 bytes).  If you're on a 64-bit system it will be 64-bits in size (8 bytes).  Below is an example[1] of what the stack looks like for a function:

uint32_t function(int a, int b, int c, int d, int e, int f, int g, int h);

The example above is for x64.  CPU registers RDI, RSI, RDX, RCX, R8 and R9 store the first 6 parameters, and the rest are pushed on the the stack.  The return address, g, and h will be 8-byte values.  g might only equal 0x10, but when you push it on the stack it will look like 0x0000000000000010.

After the parameters are pushed onto the stack the call instruction is executed.  This will push the return address onto the stack, and jump to the function for execution.  Because the stack grows towards low address space each time you push something onto the stack it moves closer to zero.  In the picture above you'll also see the local variables xx, yy, and zz.  Each of these are also moving down the stack towards lower memory.  Of course, realize that the program is always manipulating the top of the stack.

Stack Overflow

Lets say you create a local variable that is a buffer with a maximum of 12 bytes.  Something like this, unsigned char buffer[12];.  The stack makes space for 12 bytes of data.  Lets say we fill this buffer with "012345678912"  it's going to look like this on the stack1:

High
...
32313938
37363534
33323130
...
Low

Because the beginning of the buffer will always be towards lower memory[2].  So when you begin writing into a buffer you're always writing from Low to High.  If you don't allocate enough space and you write more data than you have allocated you have a buffer overflow.

Endianess

Now you want to overwrite the return address on the stack.  You put it at the end of your string so that as the copy writes over higher memory it overwrites your return address with the address you want there instead2.  Intel throws another curve ball at you.   x86 and x64 systems are Little Endian.  Which means that the least significant byte is in the smallest address.

So you'll want the least significant byte of the address (0x32) written to lower memory.  So you'll write the address into memory backwards because you're writing from low to high memory.  When viewing the address from high to low (as the example above shows) the memory address will look correct.  However, when viewing from low to high it will be backwards.  The important aspect to remember is that the architecture requires the LSB to be written to lower memory.

1 - I'm using a 32-bit system here because a 4-byte width is easier to draw out.
2 - Saved EBP, I'm ignoring this because it's not important to the discussion.  It's very important to remember, but just kind of ignore its existence for now.


Why is Parallels Plesk running on port 8443 > 1023?

While Linux has a file security model similar to that of early Unix, I think there has been a change in how the computers are used. In the 70's and 80's, Unix was run on large computers hosting many concurrent users. For example, a single computer could be used by all students in a computer science program. With that type of usage, protecting machine resources from other users was paramount.

Now Linux is frequently run as a single-user OS or in server situations where usage is heavily regulated. As such, protecting resources from malicious users isn't really much of a concern. Personally, I can't recall the last time I was on a Linux machine and didn't have full sudo privileges.

I think that as Linux/Unix's usage model changed, worrying about root-only accessible sockets has become less of a concern. This doesn't mean that it shouldn't be thought about as, while many machines effectively have one user or a small group of cooperating users (eg: for server maintenance), processes should be be run with least privilege. Still, fewer actual users has led to a loosening of security processes.

None of this means that Plesk running on an unprotected port is safe given your deployment model. If you are on a shared host, this deployment of Plesk would make me somewhat concerned. That said, shared hosts have lots of security concerns and maybe this isn't the worst one. You'll have to make the decision as to whether this deployment model is too great a risk for you or not.


Laravel | Why create a public_html folder and link/move it?

The only reason that some people changed/directed this folder to something else is because of older versions of the app cause problems some users say.
So that said, relax and don't be paranoid. Using the /public_html or just /public has the same security as if someone changes or redirect to another.
If you still want to make the change to be 'just sure'.
laravel by itself is already good in its security, BUT you can always take extra security measurements to make it extra secure.
What you can add by yourself as security extras:

SSL certificate installation
the app installed on a cloud-based platform for data losing security - (if out of nothing the security may go unwanted down or whatever)

And that's it actually, laravel with its version 7.x is so far the best build that is published from all other versions and is furthermore really secure.
Additional to add laravel's dev its Git of the latest published version. Click here
If there are security changes (and the system update fails in laravel) you can find and git them from there.


How to deliver an application to several clients with a single trusted SSL certificate?

You should allow the client to add their own certificate to your solution. They can get that from wherever they want.

Alternatively, if the domain is reachable from the internet, you could automatically fetch a new certificate from Let's Encrypt


Server negotiated HTTP/2 with blacklisted suite

These suits included in the list of ciphersuites prohibited by HTTP/2 defined in RFC 7540.

Since AES-GCM and RSA still enjoy a good reputation, the remaining weakness of the second suite is that it doesn't offer forward-secrecy.

The specification confirms this:

  This list includes those cipher suites that do not offer an ephemeral key exchange [this rules out both of your suites] and those that are based on the TLS null, stream, or block cipher type [this rules out TLS_RSA_WITH_AES_256_CBC_SHA]

In your config string I see !DH and more importantly !ECDH which disables all kinds of Diffie-Hellman suites, including ephemeral Diffie-Hellman, which are the way SSL achieves forward secrecy.

  ECDH

  cipher suites using ECDH key exchange, including anonymous, ephemeral and fixed ECDH.

Thus the fix is to allow ephemeral elliptic curve Diffie-Hellman (ECDHE)


How can I promote good password practices in an organization that doesn't currently care about that?

I recently came across this article written by Ross Anderson. Apart from pointing out to your colleagues how quickly bad passwords can be broken, it is worth noting that their research showed some benefits in just reminding people some good rules for passwords and having a basic induction into password choice.

http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-500.pdf

If possible, look for why people are choosing default passwords or sharing accounts and see if there is a way around this. Consider the example of ssh-ing into multiple servers  and allowing some of the support staff to do the same. Rather than having a single password that everyone knows, you can use keys here so that they don't need to remember anything. They just log in with the key. If you need to revoke the key, remove it from the server (this is obviously just an example).

Education is the key as well as ensuring people can still easily get on with their jobs. Just demanding everyone chooses a length 16+ password, with multiple cases & special chars which they then have to type in 25+ times a day is not an acceptable solution. They simply won't do it and will fall back to using a 6 character password they use everywhere else as it is easier.


Is there an other place than the changelogs to see if a debian package is corrected or not?

Debian provides a feed for its security advisories: http://www.debian.org/security/dsa. There is a link to each advisory which lists the CVE addressed by that fix. The debian-security-announce@debian.org mailing list provides the same information. These advisories have been declared CVE-compatible. The email and RSS feeds are the most timely way to retrieve advisories. See the section on security advisories in the manual for more context.

Additionally, Debian publishes an advisory cross-reference which lists all the advisories with the CVE that they address (as well as Bugtraq IDs, CERT advisories and US-CERT vulnerability notes). MITRE also publishes a CVE reference map listing CVEs addressed by each DSA.

I don't know of any “official” place where you can retrieve the CVE-to-package-version map in a single go. From the Debian cross-reference, you need to follow the DSA links to know what package version brought the fix.


Is it possible to detect if a proxy is intercepting and sniffing or modifying data

The moment you decide on using a proxy outside of your control, the is always going to be the risk your data may be monitored. This should be no surprise as you are forgetting what a proxy is, and what it does. A proxy relays data from your system, to another, and vice versa. The questions become the following:

1) Q) Can my data be intercepted?

A) This shouldn't be a question. Your data is already going through the proxy

2) Q) Is my data encrypted?

A) This depends. Consider the following. I create a company called PrivacyProxies123.com and charge a fee. I pay for a certificate (SSL), and the cert is authenticated, and published to all browsers, etc.

1) You --> "I need to get to Facebook" --> PrivateProxies123.com

2) PrivateProxies123.com --> alright but accept my cert for this session --> You

3) You <--> transparent connection your browser acknowledge/accepted cert <--> PrivateProxies123.com

4) You <--> open FaceBook <--> Private Proxies decrypts (using their cert) <--> passes data to FB

The likelihood of this happening is low, not because it cannot be done, but the amount of disk space needed to store data, then the computing power necessary to parse data out of packets is a huge undertaking. So using the same concept above picture the following:

CriminalMaintainedProxy:

You --> I need to get to FB --> publicProxy

publicProxy (with a stolen cert) <--> absolutely I will send data to FB for you <--> You

You --> here is my user/pass <--> publicProxy (MiTM + ngrep "user\|pass")

When you use public proxies, or any proxy outside of your control, you run the risk of losing your data. The LIKELIHOOD however of this happening is altogether different. You need look solely at the history of Wikileaks (it started via TOR proxy sniffing) to understand this.


How do data breaches of account login information end up in plaintext?

Passwords should not be encrypted, they should be hashed. Encryption can be easily reversed if you have the key - and an attacker who has managed to steal the whole database probably has stolen the key as well. A hash can not be easily reversed.

When someone attempts to login, the server does not decrypt the stored password. Instead it hashes the provided password and see if it matches the stored hash of the password.

So if a hash function is designed to be hard to reverse, why does the passwords end up in plaintext? Because of brute force attacks.

If you have a hash, you can simply try to hash all possible passwords and see if you get a match. You might have to try a couple of millions before you find a match, but sooner or later you will. If you use a list of common passwords and try those first, it will be quick to break common passwords such as 123456.

To keep your passwords safe, you need to make "sooner or later" mean "so late it is not worth the effort". That is done by using hash functions deliberately designed to be slow even on modern hardware, so that trying millions and millions of passwords would take years or even millenia.

However, a lot of sites either use bad hash functions (that are fast, and therefore easy to brute force) or even worse - they just store the passwords in plain text or just encrypted. Therefore, a lot of passwords ends up in plaintext in the hands of hackers.

For more information on hashing, I recommend this question.


Secure HTTP Headers - where should be implemented, WAF or code level?

From the perspective of the client, it does not matter where these headers are implemented; only whether they are implemented at all.

But, from the perspective of deployment, a WAF should be treated only as an additional line of defense and not as the single line of defense. This means that proper input checking should be done in the web application itself and proper setting of security headers too, at least for most of the headers: HPKP can of course only be set on the TLS endpoint owning the certificates which might be the WAF (if it should be set at all since it is deprecated).

Setting the security headers in the web application itself is also better from a development perspective. As much as developers should know what the expected type of specific inputs is and how they should be checked, the developers also know about how the application works and what for example the tightest Content-Security-Policy can be. A WAF is instead often deployed by a different team which does not have deep knowledge of the application and therefore cannot easily set the security headers to the tightest values acceptable by the application.

Therefore it should only be set in the WAF if it cannot be set in the application itself, which might be the case with third-party applications. As an additional line of defense, though, a WAF may still be used to ensure that the headers are there and sufficiently strict, since it might be that the developers forgot to set them.


Trying to do an SQL injection into a login field

Since this is an assignment, you need to learn more of the underlying function. You have a big helper in that the server is returning detailed error information, in the security world this is a big no-no.
There are numerous SQL sub dialects, but in general what you need to do is:

Break the standard processing

You've already done this with the insert of the ' (quote) which the server is failing to sanitize.

Insert you own SQL command

It looks like you already did this as well.

Close your SQL command out

Often with a ; (semicolon). You may have missed this part, I can't tell.

Terminate any remaining portion of the server command

Often with a --' (double dash quote). It looks like you already have this as well.
The exact syntax may vary. Watch the error message!
A classic PHP based example is:

Normal: SELECT * FROM customers WHERE username = 'timmy'
Injection: SELECT * FROM customers WHERE username = '' OR 1''

In this extremely simple case, you don't need any additional breakouts.
Whether you need the semicolon and/or double dashes will vary with the implementation. Watch the error message!


Is it insecure to use an IV based on the key?

In short, yes. Using an initialization vector derived from the key is a security risk no matter what hashing algorithm you use. You should always use a cryptographically secure random number generator to create IV's.

A big problem with deriving an IV using a hashing algorithm is that the hash will always be the same for any given key.

An IV must never be used multiple times with same key. The point of an IV is to provide uniqueness to a message and prevent it from being encrypted into the same cyphertext multiple times. Here is a post which gives a nice example of how an attacker could take advantage of this.

IV's are sent along side the encrypted message in the clear. This is fine, because they are not supposed to be a secret. The receiver needs the IV to properly decrypt the message. Sending the hashed key as the IV means that anyone who receives your message will see the hashed key. It is thus very possible for an attacker to discover the key via a rainbow table or even brute force.


Demystifying Web Authentication (Stateless Session Cookies)

"Replay attacks" don't really apply to cookies, because a cookie is by definition something which is meant to be replayed: the user's browser sends back the same cookie value, and that is how your server knows that it is the same user.

What you want to avoid is someone spying on the line, observing the cookie value, and then sending the same cookie on his own connections. The only known practical solution for that is to run the whole protocol inside a tunnel which ensures confidentiality and integrity of data in transit, and that's known as "SSL" (aka HTTPS).

Then there are two ways for generating and verifying the cookie values on the server:

You can just generate a random value of sufficient size (i.e. 16 bytes or so), so that it would be highly improbable for an attacker to guess the value out of sheer luck. The server remembers for each user his current "session token", as an extra column in the "users" database.
You produce the token as an unforgeable value deterministically computed from the user identifier. That's what you do, and that's a reasonable concept. Basically, instead of storing some extra state on the server, you offload it on the client, and you use a MAC with a server-side key so that clients cannot forge "valid" cookie values.

Your code describes two nested HMAC calls, which is weird and unwarranted. One call is sufficient. The generic construction is that a cookie contains a value v and a MAC m such that v encodes the state you wanted to store in the client, and m is computed over v. The state you want to store, in your case, is: "this client has user ID i and logged on at time t". You can use whatever encoding you wish provided that you can decode it unambiguously.

To sum things up: producing cookie values with a MAC is a valid way of doing session management, and HMAC/SHA-256 is good for that. But you must think of it as an optimization: you store values in the client to avoid storing them on the server. This has the unfortunate consequence that the client can forget data out of your control (the client may destroy the cookie) or can do time warps (the client may change the value stored in its browser to an older cookie value -- an issue which is mitigated by including dates in the cookies, under control of the MAC).

If you can keep state server side and just use random cookie values, then do it: it is simpler and gives more control to the server.


Is the site wrong about an ethical hacking question or am I?

You're right and the website is wrong.

I know it's frustrating but I think that anyone who went through a certification also went through the same frustration ;).

Sometimes, the issue is not even in the training program but in the certification organism itself who do not check his own questions enough (question quality varies greatly from one organism to another). Training programs then only reflect this situation by using older official questions and answers.

Instead, take the fact that you have now enough knowledge and confidence to challenge such answers as a good sign of your level. At the end, you don't need 100% good answers. As long as you have enough knowledge, you should be able to pass despite odd, malformed and wrong questions.


What are the Standard Practices for Securely Storing Encryption Keys in Databases

When you are facing such a (pain in the ass) problem, please, consider first using an existing solution for key management, I am sure you will be able to combine this solution with the software you are developing, if you really want to go on, then continue reading.

Don't overkill. Consider if the environment you are in is safe enough for the purpose of the key. Although it is not a good practice, storing the key as plain text may be reasonably ok for you.
If this is a high security environment don't DIY, buy a solution.
If you want to go on =), you have to consider not only the secure storage of the key, you have to ensure also its transmission and its format.
If the key is used by an script of unattended software, eventually they will need the key as plain text, so consider again if it is worth.
If the keys are used by users (using a software), you can always store them encrypted with an user password, but consider that it will be the user the one who decypher it, so you will need to send him the encrypted-key.
There are a lot of implications with key management, be sure you fully understand whats behind in this topic.

You can have a look also to these NIST guides:

http://csrc.nist.gov/groups/ST/toolkit/key_management.html


SSL Certificate MITM Attack for Expired Domains

PKI Infrastructure provides the means to do this via revocation lists.  If you purchase a domain from someone else, or snatch one up that has lapsed, part of that responsibility lies with the purchasing party.  They should do their due diligence and contact the CA issuing authority to invalidate any other certificates that are out there.  I'm sure there is some sort of proof required by the CA before they just randomly invalidate a Domain's certificate, but I've never done it before.  Between OCSP and standard revocation lists, this shouldn't be a hard problem to overcome if your web/sys admins are doing their jobs right.


how to associate a public key with a user of a website

To map an entity (a user in your case) to a public key, you can use a digital certificate. For example an X.509 certificate. The user details should typically reside in the Subject part of the certificate, while the public key resides in the Subject Public Key Info part.

Otherwise, you can simply store the public key in the database and link with a user id.

  Where to store a user's private key?

With the user. They can store it anywhere on their computer. However the private key should be protected with strictest file permissions (that is how ssh keys are stored typically). Other alternatives include a keystore (see Java KeyStore), or even a password manager (e.g. 1password), or a hardware security module depending on how precious the private key is.

  How do I ensure that the public key received by the server is actually from the user that claims to send it and there has been no man in the middle attack ?

To prevent man in the middle attack, you should be using TLS. To make sure that the public key is actually from the user who claims it, the server must make sure that the user is authenticated before accepting the public key.


Is preventing XSS/HTML Injection really this simple?

I think your example describes exactly why it isn't that simple.  There are many forms of XSS, and quite a few of them don't rely on attackers injecting entire tags at all.

What Rook was getting at in his comment is that you should generally rely on a good existing XSS filter to deal with the threat rather than trying to piece one together your own, as your colleague seems to suggest.


How to do server side validations in Java to prevent XSS?

The OWASP cheat sheet has a number of suggestions for mitigating XSS attacks.
If you already have a framework you are using (e.g., Spring or Struts), they might have some protection mechanisms that can be configured.
If you are looking for an add-on framework, consider OWASP ESAPI or the OWASP Java Encoder Project.


What (besides not complying, and reporting) should I do with blackmail emails?

The only important takeaway to this particular scam is: change the password.

This scam has been around since approximately July 2018 and so far there are have been no videos published (that are linked to this type of extortion) but a lot of money has changed hands. One source claimed that "So far, 30 victims have paid more than $50,000 in total". One thing that we do know, that the password that is sent is indeed real. The scammers probably did not get this by penetrating your machine, but by copying it from a database of leaked credentials that are found in shady forums.

TL;DR:

Change your password. Don't reuse passwords. You can also check haveibeenpwned.com to see where and when your credentials were leaked.


Could one create a vulnerable website on purpose to attack a server of a hosting provider?

You wouldn't need the vulnerable website if you have an account on the shared hosting already. What you need is code execution on the host. A remote code execution vulnerability in one of the hosted websites gives you that, sure. But if you have your own account already, why not just upload whatever code you want to run?

I guess installing a vulnerable application could be a way to try to avoid being held responsible for the attack ("it wasn't me, I was hacked"). But it is not strictly needed.

Companies that offer shared hosting has to try to segregate the different accounts as much as possible. This is not always an easy thing to do. Vulnerabilities in the operative system or server misconfigurations can be exploited to gain access to other accounts. A good hosting provider could make such attacks hard by keeping software up to date and configuring things properly. But cheap is seldom good, and shared hosting is often cheap.


How to find the source of business email account compromise

While there are technical measures to protect your email account, the biggest issue is that your lawyer accepted a change in payment processes without verification. It should not have happened regardless of who was hacked or when.

In Business Email Compromise (BEC), the most effective defense is to have processes in place that will block this type of problem before it happens. No changes to payments, billing or invoicing should be made without confirmation.

What has happened is a crime worthy of reporting to both the bank and to law enforcement, which I encourage you to do.


Why do major sites(Facebook, Google, etc) still send passwords unhashed?

We have to distinguish between following two scenarios:

1) A determined hacker tries to get the passwords

In this situation SSL usually provides enough protection, well implemented SSL is very hard to break. As soon as the attacker could successfully start a ManInTheMiddle attack, the client side hash would not get more protection anyway, because the attacker could easily remove the (JS) script, which is calculating the hash.

2) An automated attack is started

Should there be an organisation which is capable of reading SSL traffic, calculating a client side hash would increase their costs, because in an automated attack they would only see the hash of the password. As soon as their interest for a site is big enough though, they could write code to automatically remove the script of this site.

If they have the hash only, they could still try to brute-force this hash. Since you will probably use a fast hash client side (SHA*), brute-forcing should be relatively easy. Using a slow hash (PBKDF2 or BCrypt) is difficult to implement, with a slow client side language like JS. Even if you would calculate a slow hash client side, you had to reduce the time on the server-side, because you don't want let the user waiting too long. Trading server-side hashing with client-side hashing would decrease security, because server-side hashing can be done faster (more rounds) than client-side hashing.

➽ This means you could make their life harder, but you could not stop them if their interest is big enough. If the user is security aware and chooses a very strong password, a client side hash could help, but this user would propably not reuse the password.


How to configure Kismet to redetect same BSSIDs in a loop?

There really isn't a command for this. Your best bet is to script a scan every few minutes, or find an app which functions more like a spectrum analyzer.


In the diagram above, the encryption exists between you and the VPN server. Past the VPN server it is no longer encrypted. A VPN is a way to send traffic over a public connection and still have a reasonable expectation of privacy. The typical use case for them is either protecting your privacy or thwarting geoIP based filtering.

However, like with any encryption you must negotiate the encryption scheme and keys. Thinking about it that way, for the VPN traffic to be encrypted further would require the website to be running VPN software and configuring it to connect with this VPN provider.


If I install Burp certificate in my system and try to access HSTS certified site and site will work and is it safe?

It will depend on the fact whether you have installed the BurpSuite(portswigger) certificate as a trusted authority in the browser. Once you do that, you can intercept any website with burpsuite. But if you do not install the above mentioned certificate in your browser, you will not be able to intercept website which has HSTS enabled.
The website being safe or not is not related to whether the site can be intercepted or not using burpsuite.


Can JavaScript be used to install malware?

Even with just Html,CSS, and javascript an attacker or malicious site could still attempt to exploit bugs in the browser that would allow them to exploit a machine. Or create dialogs and attempt to trick a user into allowing permission to install malware. This was one example I found by googling javascript and malware install. If anything plugins create a wider attack surface, but without them that doesn't eliminate the attack surface relative to the browser that you use. For example if there is a browser vulnerability that allows remote code execution a malicious website could potentially use javascript to exploit the vulnerability. Hope that helps some.


Of course no one wants to report, they are "turning in" their peers. Also, the time and complexity it takes to go through the reporting process you described is another negative reinforcement. You are only going to get low compliance if everything is a negative.

And ... YOU CANNOT FORCE PEOPLE TO DO ANYTHING!!

You are approaching the problem backwards. You need to:

use technical controls so that people do not have to think (set an auto-lockout time on idle workstations)
reward people for doing the right thing (and no, reporting their peers is not the right thing)

Instead of punishing non-locked stations, reward people who locked their stations! Praise them publicly, offer them a chocolate. Whatever works for that office/local culture.

Your focus, at the moment, is to collect metrics for your incident reports. I suggest that this is also backwards. Locking a station is a behaviour. Not locking a station is not an incident (it's an event, at best). You are never going to get accurate metrics, so I'm not sure why this would be a focus.

I know that it is a huge mental shift, but there is a big difference between an intentional act of omission or commision (to not do or to do something) to violate policy (an incident) and inattention and inertia that results in non-compliance. You cannot confuse the two. Non-compliance is a behaviour issue, which needs to be handled (and tracked) differently.

To answer your question directly, in order to get people to do things, you need to address 3 factors:

motivation
ability
trigger

They have to want to do it, it needs to be easy to do, and the trigger for when they are supposed to do it needs to be clear (the Fogg Model).

Scratching an itchy nose has high motivation, it's easy to do, and the itch is its own trigger. So, everyone does it reliably.

Reporting your peer for not locking a workstation has low motivation (even if you rewarded them for reporting), the process is complex, and the trigger is also not that clear. When does one deem that there is non-compliance? Does one have to be watching all the time? What if the other user stepped away and was within view of their workstation? What if the user is "looking out" for the workstation to ensure there is no unauthorised access?

You simply are on the wrong side of the Fogg Model. Address these 3 factors, and you can experience high compliance.


Would it be a good idea to develop your own multi-factor authentication?

The answer is more or less the same for all type of development work:

Start with your requirements. What are they really and specifically ? Think usability requirement, security requirements, compatibility, etc. Everything counts.
Once you have the requirements, have someone perform some research to see if there is an existing protocol (or better, an existing implementation) that will fit your needs (regarding requirements, tooling, skills and budget).
Only then, start implementation (which might or might not require coding).

Based on your question there is nothing in the announced requirements ("we need to implement multi-factor authentication") that cannot be solved easily and cheaply by using TOTP and one of the many soft clients that supports it. Form more complex solutions, there are plenty of commercial offering.


If you're hacker, you can create "evil twin access point" or called "Rogue access point" by aircrack-ng suite or Reaver, and Pixiewps or
wifiphiser. After do follow instruction and wait maybe you can capture password what user login


Is using Gmail App over Web Gmail more safe?

It depends on what you mean by security... As soon an you use a dedicated mail application, you keep a copy of the messages on the local client. Said differently, you add an element on the chain and the global security of a chain is the one of its weakest element.

That being said, the security server side is just a username+password. So having a local copy does not really add weakeness, except for the physical security question. If you have a desktop in a correctly protected building, the question of a physical theft of mail is likely to be less important than the question of a physical intrusion. If you use a phone or a desktop that you carry with you, the risk of a physical theft is much higher, and you should considere using full disk encryption.

For the more general question, the response could vary. But anyway a multi tier application should have at least a presentation layer (web or app), a business layer and persistence layer. The business  and persistence layer should be server side, and the kernel of the authorization rules should be implemented server side on the service layer. The authentication should be the same, and the protocol between client and server should use same level of protection (TLS or SSL) with server certificate and client authentication, so as for the mail, the main question will be the security of local data.

An do not forget, the weakest element on a security chain is often the user itself: the strongest password will not be able to protect your account if is is written on a postit at the bottom of the screen. The password container of most browser can be a major risk if it is not itself password protected, and the same rule applies to rich client applications.


How to reuse a rewritable DVD from an unknown source?

Best practices
For best practices, rather than for defending against a highly sophisticated adversary, it should be enough to just disable autoplay/automount. This will prevent any malicious content on the DVD from being processed by the operating system, but will still allow you to write a new image to it.
There is some informational data that is read unconditionally whenever a new disc is inserted into a reader/burner. This data identifies, among other things, the make and model of the disc, its capacity, and various burner features that it is compatible with. This data could, in theory, be maliciously designed to trigger a security bug in either the drive firmware itself or an operating system driver. Utilizing this as an attack vector is, however, quite difficult and would only be a risk to a high-priority target due to the level of sophistication required to pull it off.
But to answer the heart of your question... You work in a highly competitive field and have access to corporate and government data, as well as sensitive new research. You have found a disc just lying around in your new office. These are all red flags: Don't insert the disc!
This should be sufficient as an answer, but if you want to know the details, read on...
Risk of reading the disc
If the disc is malicious and is designed to compromise your system, it will most likely try to do so through contents on the disc itself rather than metadata. This relies on the assumption that you'll be curious about what was written to it. Possible attack vectors include:

Corrupt filesystems - The filesystems for discs is typically UDF, a simple filesystem with only basic feature support. However, mounting a device causes your operating system to process the filesystem, which comes from an untrusted source. I have actually seen this used as an attack vector in the wild against a Linux system, where a malicious disc filesystem was used to attempt code execution in the kernel via an iso9660 0day (which may or may not be fixed).

Icons or previews - Many operating systems will display previews of files that it finds in a new mount point. The decoders that read the icon information embedded in the file, or which read the file contents itself to generate a preview, may contain security bugs. Exploiting these bugs can result in code execution with the privileges of the previewing software.

Autoplay and autorun - While this is not a common issue for modern systems, older versions of Windows would automatically open a disc and execute the file specified in autorun.ini. However, although new systems are not going to do this, they still may be configured to open the disc and play video or audio data if present. Video and audio decoders parse complex data formats in unsafe languages, making them a prime target for exploitation.

All of these exploitation vectors are mitigated by disabling autoplay and automount. This will prevent your computer from viewing anything contained in the disc's filesystem or the filesystem itself. It will not, however, prevent the drive firmware from checking the disc metadata and related information and sending that information to the operating system, which could still be exploitable.
Risk of reusing the disc
The metadata information is automatically read by the drive and delivered to the operating system. Typically, it is burned in by the manufacturer and cannot be changed by an end-user (though a sophisticated attacker could still provide you with a disc with customized metadata). An example of what the data looks like as reported by wodim when burning a disc:

Device type    : Removable CD-ROM
Vendor_info    : 'MATSHITA'
Identification : 'DVD+-RW UJ8C7'
Revision       : '1.00'
Drive id       : 'WQ36  064543'
Driver flags   : BURNFREE
Supported modes: TAO SAO

All this information is read unconditionally as soon as the disc is inserted into the drive. This is also the reason why the disc spins up the second you insert it, even if you do not read or write to it immediately. It's a result of the drive trying to understand what has just been put in it. I am not aware of any specific vulnerabilities that could be exploited this way, but that does not mean they do not exist.
Analyzing your situation
Regarding your recent comments answering whether or not you work in a competitive industry:

I work in academia as a research math. So probably not competitive in the sense you are thinking. I found it in my office among a the random stuff left by the previous office user.

Research can be extremely competitive, and the fact that you saw this disc left over in your own office could be a red flag. If someone wanted to compromise your computer to obtain valuable information, one of the easiest and most common techniques is to leave media "lying around", since chances are, the target will take the device and use it. This is most commonly done with flash drives, since no one can resist plugging in a random flash drive (or inserting a random disc) just lying around.

I have access to the data of a large corporation, which is the most sensitive data available to me. Also some official-use-only data from the government, so it is conceivable that someone would want it.
As for ideas, there are one or two hot ideas that are developed in some of my files that I am keeping quiet about until I publish.

This makes you a prime target. You say you just want best practices and do not need to defend against an NSA-level adversary, but the kind of information you possess could be extremely valuable. You may have to defend against highly sophisticated adversaries near the level of a nation-state. You should always be weary of tempting devices lying around, as this could very possibly be an attack.


Is it safe to insert a USB drive of unknown origin?

Besides Hardware attacks that can destroy your computer like USB Killer
There are also attacks that just use the USB device (like badUSB)

and thats all before you have seen any possible file. The files themselves could be infected. There is simply no way to know if its safe from a distance.


Patch Advisory Board - feasibility of implementation

We have a similar problem.  Thousands of servers, tens of thousands of users, thousands of applications.  No one knows anything.  We don't have thousands of mirrored dev and test servers: most of our servers are primaries.

Change Advisory Boards are great good practice and a great way to spend hours of effort.  They reduce your risk, specifically reduces the risk of "oh dear we didn't expect that I will resign".

What we found was that 99% of security patches just worked.  There were some MS ones that borked the OS, but as we typically wait two weeks after release before deploying the patches that's sufficient time for news to leak about a broken patch.

Now our approach is: just apply the security patches.  Some high status operational systems get a test first and we do a test on a small sample of servers just to be sure, but our goal and our policy is "everything gets patched".

This is similar to vulnerability management. Rather than employ a team of vulnerability researchers to determine if a vulnerability should be remediated, we just remediate everything except the major categories we have decided to accept: weak SSL cyphers on internal systems springs to mind.

There is a chance that a patch breaks a system but we found we could not completely mitigate that so we patch and be damned and then restore from snapshot. That means our engineers can do productive and useful work and only have to deal with the occasional exception. We can't test all patches on all systems on all possible paths of execution, so even if we do test it's only "does the patch install, is the light still green".


If Yahoo can get hacked , how can we secure our small websites?

Being big does not equal being better secured

Don't assume that becuase they are big and famous, everything they do is better than what you can do.

Nothing has changed - you can secure your small websites the same way you did before, perhaps better since you can learn from Yahoo's mistakes. Continually updating your password hashing, instead of using md5, would be a good start.

Sometimes, being big also means it takes a long time to update security measures, it wouldn't surprise me if "update password hashes" has been in somebodies to-do list for many years.


Can a Vulnerability Management tool highlight BIOS and driver-level vulnerabilities?

Nessus does not have a plugin for that CVE. You can check this using the Nessus plugin search. I don't know about the other tools.

In theory it is possible to detect these issues on an authenticated scan, as you can do a WMI query for the BIOS version. It may turn out that there are particular difficulties that prevent this; perhaps the BIOS version doesn't update when you apply the new firmware. Or it may just be that Tenable haven't yet developed such a plugin.

Nessus does have checks for some driver vulnerabilities (e.g. Nvidia flaw) They are generally local checks only, although a few remote ones exist (Etherleak is one that springs to mind).


How can we factor Moore's law into password cracking estimates?

It will be significantly less.  I would just set up a recurrence relation for this like so:

A(n) = A(n-1) - C * 2 ^ (N-1) and A(0) = size of keyspace, say 62^12

lets set C = 3.0*10^12 for hashes computed the first year and assume computing power doubles every year.

Plugging this into wolfram alpha yields this function solution for the recurrence relation:

recurrence relation...

f(x) ~= 3.22627x10^21 - 3.0x10^12 * 2^x

Solve f(x) = 0 for x:

x = lg (3.22627x10^21 / 3.0x10^12) where lg is log base 2

x ~= 30.00226 years

Cracked in 30 years, but that's a lot of silicon, no wasted work, and you would need a method to seemlessly integrate new hardware into the running program without stopping it.

Explanation:

So we have the original key space size: 62^12 and a hypothetical machine capable of incorporating Moore's Law, somehow.

My original math was off a bit.  For some reason I did 3.0 x 10^9 * 1000 = 3.0 x 10^12 for calculations in a year, but it should be 3.0 x 10^9 * 3600 (seconds / hour) * 24 (hours / day) * 365 ( days / year).  Anyways, that's our initial speed, which according to Moore's law will double every year.  I'm going to keep the original mistake for consistency in explanation.

So in the first year, we perform 3.0x10^12 hashes of the 1.0x62^12 maximum hashes needed (assuming worst case scenario).  In the second year, Moore's law applies and now we do 6.0x10^12 hashes in the second year, which gives us cumulatively 9.0x10^12 hashes calculated so far.  The hashes we have left to do are found via subtraction from the whole number of hashes.  We'll run the program until there are no more hashes to find.

A(N) = A(N-1) - C * 2^(N-1)

A(N) is the number of hashes remaining after this year

A(N-1) was the number of hashes previously remaining before this year

C is the initial speed

N is the number of the year (first, second, third, etc).

So every year the speed doubles, which is the 2^(N-1) part of the equation.  C is the initial speed for the first year, so we have C * 2 ^ 0 = C * 1 = C.  In the second year, the speed has doubled once, so we have 2 * C.  In the third year, speed has the doubled from initial twice, so we have 2 * 2 * C = 2^2 * C = 2^(N-1) * C since N is 3.  This forms a recurrence relation for the number of hashes left to compute.

Using a combinatorics book, you can transform a recurrence relation into a generating function.  Or wolfram alpha can do it for you, if you're like me and remember generating functions can be found but have forgotten how to find them since that math class seven years ago.

Anyways, you get a function of x where x is still the year being iterated.  f(x) is how many hashes are left to compute.  We're done when there are 0 left.  So we solve f(x) for x when f(x) = 0.  The last part is algebra.

I might be off base here, but it makes sense to me :)


Why store a salt along side the hashed password?

I can see where you're coming from, but the answer is basically "that's not what the salt is for".  If I'm trying to discover a particular user's password, the salt doesn't help much if it's right beside the hash.  However, it's not expected to be useful in that situation - cracking an individual user's password is difficult enough already.

The point of the salt is that it's something to add to each password before hashing such that each password is unique - if two users both have hunter2 as their password, the hashes need to be different.

Say an attacker is fishing through a database (or a whole range of databases) to find everyone whose password is letmein123.  Without a salt, they can do the hash once and search for the hash.

Without a salt if an attacker spots two or more identical hashes in the database, it indicates that this is a weak password (since multiple users have chosen the same one) and can concentrate on cracking this first.

But the salt is a user-specific prefix/suffix that is added to the password before hashing, so (even with a "public" salt) an attacker has to re-calculate the hash for every user - so checking one password against 10000 users isn't any more efficient than checking 10000 passwords against one user, which is the point.


International bank transfer, what is safe to share?

All these fields are needed to transfer Euros internationally.

Both the UK and Latvia are part of SEPA; WP says:

  SEPA clearance is based on the IBAN bank-account identification and the SWIFT-BIC bank identifier.

The bank name and account number can be derived from the IBAN; they are not strictly needed, but it does not hurt to give them.


ISO27000 implementation - Where do you get the standardization material?

The official route for documentation is through ISO:IEC - and papers cost 134 Swiss Francs each.

Various bodies have guidance papers, for example ISACA provide a range of ISO27001 material on topics such as implementing ISMS, aligning Cobit, ITIL and ISO27001 - but you have to be an ISACA member (if you need to, ask me how :-)

Alternatively, you can engage consultants to go through your needs and gain an understanding of what you might need to do. As an example, I have helped many large organisations align their security function with ISO27001:2005 - not to gain accreditation, as that can often be expensive overkill, but to gain the advantages a governance and security framework based on ISO27001 gives you.

You can, however, get a lot of good information from some free sources:

http://www.itgovernance.co.uk/iso27001.aspx has a good ISMS guide and both the briefing paper and ISO27001 explained are worth a read.
http://informationsecuritymanagement.co.uk/iso-27001-guide.php?gclid=COu59YiXgLECFZA24Qod4HK_6w also provides a free guide to achieving certification


Can Google Docs be used to “sanitize” a Word or Excel document?

The strategy you propose might indeed break malicious code, but with 0 day exploits there is no way to be sure.

If it is just the flat text that you want, the safest way to go might be to open the raw file with a different program. .docx can be opened as a zipped file (using unzip, 7zip or similar) and then you can open word/document.xml with your favorite text editor.


Why aren't anomaly-based intrusion detection schemes implemented in Snort?

There are two reasons:

First, anomaly-based network intrusion detection is harder to translate from research into practice than it might at first seem.  It tends to raise many false alarms.
Second, those are research papers.  Researchers often build a research prototype that's just good enough to test the idea (as a proof of concept).  There's a great deal of additional work to build something practically deployable, so only a small fraction of research papers go that far.  This is true across pretty much all of computer science research -- not just anomaly-based intrusion detection.

For your question about whether anomaly detection is useless in practice, see Neural networks & anomaly detection on this site.  (The search bar is your friend; give it a try!)


Secure way to store Userdata without encrypting the Database

The use case is still a little merky, but here are some thoughts I have reading through the above so far.

Is it a requirement that the application does the decoding, or is the requirement that encryption not be performed in the database? You can have a intermediary server encrypt/decrypt or use a hardware security module, etc.
Assuming that its not a requirement that the web application owner needs read access, you may be able to do a private-key encryption of the sensitive data (obviously not on child-parent table references and such). It's a pain, but its possible to assign end-users certificates for login and authentication and I believe you may be able to leverage that for encryption.
If you just want data encrypted in storage and have reasonable trust of your developers (you shouldn't) you can have the application use its own private key for encryption in the application of the sensitive data and encrypt it before storing it in the database. You would also need to figure out how to protect the private key. You may be able to use a hardware module here as well.

Also, even if the organization doesn't think they have HIPAA requirements, it sure does sound like that. They might be a  "business associate", which could still have some HIPAA implications. I would also wonder about the business model where they have a boat-load of data but don't want the ability to aggregate or data-mine; you can use all sorts of pseudonym referneces to tie things together at the individual level for a per-person processing (e.g., query all my blood test rows and do the aggregation when I load the page). Has the organization considered the impact of doing encryption at the application level, or perhaps this is only for a few key pieces of data?


Safely downloading user submitted content

IMHO, your key problem is that you are not validating the content being uploaded. Since we are only talking about JSON and CSV here, its trivial to write code to validate these. It won't catch all the issues, but it will get most of them. And at least you can tell the uploading user they've made a mistake at the time they are uploading - rather than telling a content consumer sometime later that they can't have the content.

As a minimum I would suggest validating the character set and the structure of the file - and checking it matches the submitted mimetype. However there is a complication in that not all the things which are thought of as CSV comply to RFC 4180, and RFC 4180 actually describes a lot of variants of the CSV file format (particularly how the symbols used for meta-data are represented when they occur within data).

I would strongly advise against allowing anyone to download content which has not been checked via their browser. Since it should be possible to represent the content using UTF-8 or UTF-16, its trivial to create a representation of the content with the non-compliant characters replaced and displayed in a PRE.../PRE block within an html page (with the htmlentities translated too).


Can anyone give me more info on this sketchy url I recently visited, is it an attack site?

So long as you did not download and run the freesystemscan.exe it tries to give you, you should be fine.

I image it would have been more interesting if you were using IE but FF is usually safe enough.  I visited the site in the latest version of chrome and not much interesting happened besides the download.

EDIT:
Looking at the source code.. it looks like it would try to do something interesting if you visited in IE6.
Then there is a bunch of obfuscated JavaScript I don't feel like peeking around in.


Trust linux images burned from untrusted systems

It is highly, highly unlikely that the malware that has compromised your system would be able to somehow intercept the ISO, modify it, and change the website's file checksum to match. It would also be extremely unlikely that it would be able to modify the ISO while it is burned to a DVD so it will compromise your new OS version.

It would be slightly more believable that the malware would corrupt your browser to direct you to a compromised ISO in the first place for you to download, however that is also pretty unlikely.

In all likelihood you're safe using an ISO you downloaded on your compromised system, however it's unlikely that you're on a desert island with only one computer and a satellite dish for company, so why not research, download, and burn an ISO from a friend's computer? That will eliminate the very slight risk.


Why do popular two factor authenticators use shared keys

The currently known methods of using "a public/private key pair" require too much communication; i.e.,

both ends would need Bluetooth or the token would need a computer-screen-reader or the process

could get tedious.  "a shared secret key" minimizes the amount of communication that is required.


Security concerns with malicious NFC tags?

There are a few details about how NFC works that you are missing that prevent this from being a serious issue.

First, you can easily configure your device to only process tags with your approval and it is clear what the behavior of the tag is when you are asked for approval (the URL can be displayed for example).

Second, the complex actions that the article is talking about are only possible because the NFC tag stores a unique ID which corresponds to a macro on the phone.  Without the user programing the macro ahead of time, the behaviors would not occur, so it is not a viable means of hacking the phone.

Third, many NFC tags can be rendered read-only.  This prevents re-write and would prevent someone from reprogramming an existing tag in place.  They could still remove the tag completely and add a new one, but doing so in someone's home could be tricky and wouldn't accomplish much for the prior mentioned reasons.

It still would be unwise to setup your phone to automatically go to URLs pulled from NFC without confirmation, but other than that, the amount of damage that can be done by a tag is relatively limited since the capabilities of tags in general is fairly limited.

What isn't covered would be what a maliciously formed content could do as far as unchecked input.  This isn't really much different from any other kind of activity with a phone though.  You still have to be in fairly close proximity and approve the action unless they find an overflow in the actual protocol itself (which would be no different from if they found a similar problem in the wifi stack).


How to securely provide data to a web server using a data warehouse?

Given that your warehouse contains additional data that you don't want to expose a new attack vector to it sounds like your best option is to implement some kind of basic caching layer for this data on the web server that the warehouse can push to.

You'd have some kind of service running in your secure warehouse environment pushing a serialized representation of your needed data to a key-value store or similar (redis, memcached, whatever) running on your web server. This should be more straightforward and potentially more secure than having to deal with a CSV file. It's just a question of the service on the data warehouse's side knowing when and how to bust the cache.

As you mention there's no reason you can't connect to your web server with a secure HTTPS connection to do the push. Alternatively/additionally you could implement some basic encryption to protect the data while in transit, though it sounds like the data your web server needs isn't actually sensitive data so this step may be overkill.

Again, because your data warehouse has sensitive data in it I'd advise against trying to build some kind of API that the web server can query. There's nothing intrinsically wrong with doing so, but it certainly opens up attack vectors and makes the project much more complicated that it seems like it needs to be as it doesn't sound like you need to do different types of querying, you just need one particular chunk of data. Which really makes this a "one way conversation" where the burden is on the warehouse to make sure its "public" data is pushed out.

If in the future there's a need to query, update, or otherwise have a "two way conversation" with the warehouse from the web server it would be wise to silo that data away from the sensitive data before deploying essentially "open" API endpoint(s).

Good luck!


Is this implementation of PBKDF2 correct?

Your loop is wrong in two aspects.

The length of the DK is also important
The password is reused

According to the wiki page (or you can go to the RFC if you'd like):

  DK = PBKDF2(PRF, Password, Salt, c, dkLen)

  where:

  PRF is a pseudorandom function of two parameters with output length hLen (e.g. a keyed HMAC)

  ...

  Each hLen-bit block Ti of derived key DK, is computed as follows:

  DK = T1 || T2 || ... || Tdklen/hlen

  Ti = F(Password, Salt, c, i)

  F(Password, Salt, c, i) = U1 ^ U2 ^ ... ^ Uc

  where:

  U1 = PRF(Password, Salt || INT_32_BE(i))

  U2 = PRF(Password, U1)

  ...

  Uc = PRF(Password, Uc-1)

WPA2 uses a 256 bits DK (DK = PBKDF2(HMAC−SHA1, passphrase, ssid, 4096, 256)), so the process needs two blocks (Ti) to reach this since SHA1 is only 160 bits long. Furthermore, the iteration described here uses the original password for each iteration i.e. Ui = PRF(Password, Ui-1), or you are reusing modified password on each iteration in your own loop.

For a simplified version for WPA2 I would write:

DK = B1 || trunc(B2)
B1 = F(Password, SSID || INT(1))
B2 = F(Password, SSID || INT(2))

where F(P, S) is the function

for(0, 4096) {
    U = HMAC-SHA1(P, S)
    S = U
}


Amazon Web Services ELB has permission to change DNS records by default?

There are several roles involved in the ECS service, the one you are asking about AWSServiceRoleForECS is a specific type of IAM Role called a Service-Linked Role: https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html

This type of Role allows AWS services to make changes to your account on your behalf. (By default AWS do not have permissions to make any changes to your account) To use some of their services you need to grant them permissions e.g. to modify loadbalancers to add your container services.

The key portion of the role in this case is the "Trust Relationship" which defines who is allowed to assume the role. In the case of AWSServiceRoleForECS the only trusted entity is ecs.amazonaws.com. This means that only the ECS service can access the permissions granted by the role. While this does have some risk, if you cannot trust the ECS service to make changes on your behalf then it is arguable that you should not be using such a managed service in the first place.

To answer your questions directly:

1) Your ALB does not have any permissions, this role is granted to ECS to allow it to manage ALBs for you. The only exploit that somebody within your organisation could do is via valid ECS operations that require ECS to make changes. Its unlikely there are any useful avenues here that are a worry. But you should be practising minimal permissions on ECS and all other services for your users.

2) Amazon manage the policies on service linked roles to give themselves enough permissions to do what they need, if new features were added they would update the policy. They could give all of their services admin permissions but this would be lazy and unnecessary and increase the risks in the event of both accidents (bugs) and compromises.


There is no "SHA1 with RSA encryption" for certificates used in SSL. In the context of certificates the owner of the certificate has a key pair (RSA, ECC...) and here the public key part is included in the certificate, SHA1 (or other hash algorithms) are used as a cryptographic hash within the signature and the private key (RSA, ECC..) of the issuer certificate is used in this signature too (for signing, not encrypting).

SHA1 is no longer considered secure for use in certificate signatures - use SHA2 (i.e. SHA256, SHA384... etc) instead.


Should I publish my public SSH key with user@hostname at the end?

The user@hostname part is just a comment, you can set your own comment by using the -C option or for existing keys change it with -c (http://man7.org/linux/man-pages/man1/ssh-keygen.1.html) changing it will not affect your key, so yes, you can change it to superduperuser@somfancehostname.

Snippet for these ssh-keygen options:

 -C comment
         Provides a new comment.

 -c      Requests changing the comment in the private and public key
         files.  This operation is only supported for RSA1 keys.  The
         program will prompt for the file containing the private keys,
         for the passphrase if the key has one, and for the new comment.

For instance,

You'd simply do ssh-keygen -C thebiglebowski@thedude.com and that results in the following:


Secure email hosting service for a law firm

You should be able to use PGP with standard Gmail. You can also set up 2FA. There are also plugins or Chrome extensions that help you enable it.


Using OpenSSL, this is what you would do:

$ openssl req -out codesigning.csr -key private.key -new

Where private.key is the existing private key.

As you can see you do not generate this CSR from your certificate (public key).
Also you do not generate the "same" CSR, just a new one to request a new certificate.

As per your comment, if you do not have access to the existing private key then you can create a new private key and CSR:

$ openssl req -out codesigning.csr -new -newkey rsa:2048 -nodes -keyout private.key

The end results remain the same, you get a CSR and issue a new certificate.


aircrack-ng issue: No mon0 when run "airmon-ng start wlan0" and "No such BSSID available"

In your output for airmon-ng, it says that monitor mode has been enabled for [phy0]3. This means that a new interface named 3 has been created which is using monitor mode.Therefore, 3 is the interface you should use along with aireplay or any other tools of the aircrack-ng suite. Try:
aireplay-ng --deauth 100 -a MAC_OF_AP -c MAC_OF_TARGET 3


JS snippets on my live project do not appear in my code residing on my production server

The code you have pulled out of their page is New Relic Browser monitoring. This is Javascript which lets the website track the performance of pages for their live sites and for the customers using it.

It provides performance data back for how long the page took to load, where in the world you are from and time each element loading to show where any degraded performance may be.

You can find out more information about this product at
http://newrelic.com/browser-monitoring


Are there any known exploits that come from easter eggs?

Yes, Easter eggs have caused security problems in the past.

Here are three examples, by descending severity:

The XBOX XBE Easter Egg Exploit

An Easter egg in the Xbox which displays hidden developer credits was used in an exploit to run unsigned custom executables (which Microsoft originally proibited).
This is the Easter egg:

  The Xbox contained developer credits in the dashboard. Inserting an
  audio CD and ripping it with the name "<<Eggsßox>>" would trigger
  it.

The exploit itself is documented here.

The PHP Fingerprinting Easter Egg

This PHP Easter egg is probably one of the best known security-relevant Easter eggs although it's "only" an information disclosure problem. Essentially, by appending a particular string to the URL on any PHP site that had the expose_php option set, you could reveal a hidden image instead of the original page. Since these images vary between PHP versions, that feature became a popular way to help an attacker fingerprinting the PHP version of a target server. You can find a write-up on that problem here.

The jdbgmgr.exe virus hoax

The jdbgmgr.exe virus hoax is not a real vulnerability but it was also based on an Easter egg. It's an e-mail hoax that told Windows users to delete a particular file. That file had, as a joke, a teddy bear icon which let it appear unusual in a Windows system directory. This icon made it easy for the hoax messages to convince users that the file was in fact a "dangerous virus".


PGP multi-key encryption for large, dynamic groups viewing static documents

I provided an answer to a similar, but not identical question, here: https://security.stackexchange.com/a/159962/60823

about dealing with this for an email list.

Your specific solution will obviously have to conform to your own, unique, threat model and business requirements, but essentially it will look something like this:

Encrypt D with a one-time, symmetric key (e.g. something like AES-256) cipher.  Encrypt that key with the PGP public key(s) of each member of the group G.  Add, and remove PGP keys as membership changes.

At least one key (belonging to an admin maintaining the group, or a central identity managing daemon) will have to decrypt the session key (not the whole document though) and re-encrypt it with the newly added public key.

Of course, removing people from the group won't help if they have copied the unencrypted data locally, but that's outside the scope of your question.  If you want to "lock them out" assuming they haven't already accessed the plain text, you could re-encrypt D with a new session key, and re-encrypt that to only the remaining current members of the group G.  But again, that's no help if the person leaving the group already accessed the plain text.


do SRV records make a system more vulnerable or expose too much

A SRV record defines the location of a service. It doesn't provide or expose that service. Your server (along with any firewalls you implement) provides and exposes the service, so I don't see how/why the existence of an SRV record makes you any more or less vulnerable. If you provide and expose HTTP, SMTP, SSH, etc., etc. then it matters little how a potential hacker finds those services.


What tools are available for iOS vulnerability assessment and penetration testing

SPF (Smartphone Pentest Framework) is one of the only ones I know of that are open source. Core Impact has some mobile testing modules but Core Impact is very expensive. There is Zimperium's Anti which gobbled up dSploit that performs security audits, and reading-wise, Tripwire has a decent article about pentesting mobile devices.

In the end though, Mobile devices much like other computers and servers, either have services, and network connections, that work in similar fashion. Client server, wireless/bluetooth connections... So it is trivial to use common tools such as nmap to get an idea of what services are running on a mobile device connected on your network.

There is OWASP's Mobile Security Project but they state they are focused on the application layer, and not much is written about what they do, what they've done, etc. If I were tasked with determining methods to pentest mobile devices, I would approach it from a forensics standpoint. Remember, the forensics guys/gals have likely seen more devices than you could test. The theory would be that in understanding what was found, it would make it simpler to understand how it was exploited. For something like that, I would check out the Malware Genome Project

EDITED

I also forgot to add the excellent work from Andrew Hoog and NowSecure (formerly ViaForensics). I definitely recommend getting his book to understand how iPhones/iPads, etc. work (store, connect, operate, etc)


How to find who hacked my WhatsApp account and sent messages via WhatsApp web

You can't.

All WhatsApp messages are first sent to WhatsApp's own servers and then forwarded to the recipient. Your IP address will not be sent along to the final recipient (but it will certainly be recorded and stored on the WhatsApp servers). As an end user you can neither obtain it from a regular message nor from one sent over the web messenger interface.

The obvious exception are of course official requests by a law enforcement authority. Despite end-to-end encryption WhatsApp is not an anonymizing communication tool.


What is a good source for hardened base configurations

The first repository that comes to my mind for secure baselines is NIST.

You can review the baselines for various software and operating systems, inluding Apache here: http://web.nvd.nist.gov/view/ncp/repository


Subdomain api.domain.com - more vunerable to attacks?

This is something that will yield little to nothing in the way of security.

The subdomain will still be leaked:

In your client that uses the API. To connect to the API the client has to have the correct URL, and someone with the client can extract this URL.
In plaintext traffic when using SNI (Server Name Indication). The subdomain is sent plain text before setting up an encrypted connection, in most cases.
In certificate transparency logs. If you request a HTTPS certificate for your domain, the domainname will end up in a public log.


How do I prevent tampering with form submission data, and changing the details for any account?

This seems more like a Direct Object Reference vulnerability than a SQL Injection vulnerability.

The proper way to secure this would be to check that the current session has permissions to perform the requested action on the server side.  The details of how this would be down depends on how you have implemented authorization in your application, but reading the prevention section of the link I provided should be a good start.


I doubt that they explicitly block VPN. But it is not uncommon that free networks and sometimes even paid networks in hotels restrict access to only allow web (HTTP/HTTPS) and mail in order to reduce possible misuse of their networks. This can have the side effect of implicitly blocking less common services like VPN as collateral damage.

Specifically for NordVPN see the NordVPN FAQ for firewall settings:

  What ports should be open on firewall/router for it to work?
  1723, 443 TCP and 1194 UDP ports should be open; also your firewall/router/ISP must allow pass-through for PPTP/VPN.

Likely the firewall in the medical institute does not allow port 1723 and 1194 at all and port 443 for UDP since these are not needed for the usual web and mail traffic.


Can PGP's Web of Trust be used to learn more about a person than just their identity?

Not sure this is the best of answers but as nobody else has yet stepped up ...

It totally depends on who signed it and how unique that set of people is. If, for example, it were signed by all heads of state for the G9, that probably tells someone a lot about you. Similarly, if all the signers were from your family.

Timestamps could also leak information in the same way as the signers. If all your signing timestamps occurred within a few minutes, that might indicate it happened in person for example. I'm sure there are better examples but hopefully you get the drift.

How practical is that? Not terribly I would guess except in certain very limited cases.


Unencrypted login page for EU (utility) company handling PII

It does not validate CURRENT privacy laws, as the CURRENT laws only state that you should secure the information - not how much and when - ergo, its only illegal with unsecured PII the moment a breach happens.

However, it would violate GPDR that is upcoming 1 july 2018 what I remember.
However, not all PII needs to be secured. Its depends on what PII.

A IP-adress, username, email adress is considered PII, but such a low value that theres not much requirements on securing. How much PII must be secured depends on how sensitive the PII is, where medical data and crime data is considered the most sensitive, and pseudonyms (usernames, passwords) are considered the least sensitive PII.

An adress is however PII that is considered needing extra security. Same with water usage patterns.


Can you avoid ever sending a password over the wire?

The overall situation is rather complicated. The shortest answer I can give is that it's a solvable problem in principle, but not really solved in practice. I'll give a more complete summary in "good news - bad news" format:

Good news: TLS uses server-side certificates to insure that your encrypted connection is going to the server you intended to talk to, and not being intercepted by some impostor (such as a MiTM).

Bad news: TLS only works if you use it. TLS connections aren't always the default, and things like sslstrip can (mostly) prevent the usual ways of upgrading connections to TLS.

Good news: TLS is gradually becoming the default, HSTS can lock in TLS after first use, and in many situations (client-side apps, for example) the client can know in advance to use TLS.

Bad news: Our certificate infrastructure (certificate authorities, etc) is not entirely trustworthy, and bad/fraudulent certificates do get issued.

Good news: We're starting to use things like certificate transparency and certificate pinning to provide additional checks.

Bad news: Some organizations use TLS-intercepting proxies for network security. These use their own certificates, and are therefore completely detectable by the client (and will be rejected as insecure by default). However, in these situations, the client is effectively forced to change its policy, and trust the proxy's certificates if they want access to the Internet. For a while Kazakhstan was doing this country-wide! Unfortunately, these proxies can watch the entire (unencrypted) client authentication process.

Good news: There are authentication methods that never send the password, even in encrypted form. The most basic of these use a hash of the password to authenticate, but that means the hash itself is sufficient to authenticate, making pass-the-hash attacks possible. There are better methods that don't expose the client's credentials to even a TLS-intercepting proxy, such as client-side certificates and password-authenticated key exchange ("PAKE") protocols (most notably, the Secure Remote Password, or SRP protocol).

Bad news: client-side certificates are unweildy, since they require the user to carry around a certificate file rather than just remember a password (not that remembering passwords is easy -- you can/should use a password manager, but they generally don't support certificates).

PAKE protocols like SRP look to me like a much better solution, but they also have practicality problems. IMO the biggest one is lack of standardization and client-side support. The lack of built-in support in browsers means that the server has to serve the client side of the protocol as Javascript (or something similar), and a TLS-intercepting proxy can just replace it with something that leaks the password. Whee.

Mind you, if you're writing a mobile app (or other situation where you're writing the client), you aren't limited to what any browser supports and can go ahead and use SRP or something similar with a full, secure, native client implementation.


Should I reverse the TLS client and server roles to perform client authentication in my protocol?

Server authentication is done to protect against active man in the middle attacks by knowing that one is doing the key exchange directly with the expected server. Client authentication is done so that the server knows what client connected. It is best to stay within these roles when using the protocol, because these use cases are properly cared for by TLS.
This does not mean though that other cases of using TLS are inherently insecure, but there might be weaknesses. If not validating the server certificate in theory an active man in the middle could hijack the connection starting with the TLS handshake and thus change the parameters inside the TLS handshake. This includes protocol downgrades for using weak ciphers, weak protocol versions or switching off the requirement for a client certificate etc.
As long as client and server insist on strong ciphers and protocol version such downgrade will fail though. And as long the server enforces the use of a client certificate and has strict requirements on the client certificate (i.e. will not accept a fake one by the attacker) the active MITM attack will not work - see Do client certificates provide protection against MITM? for the details.
But again, it is best to use TLS for how it was designed. Because these use cases are focused on in terms of security and focused on in security research. Thus if server authentication is optional but client authentication required in your case then better switch the roles.


Jeff's comment gets it right.  Producing an SSL certificate is necessary.  If you have a domain name registered, you could skip the self-signed and go with a free SSL certificate so every new web browser you try will not complain about the certificate being untrusted (reducing the likelihood of MITM attacks).  If you don't have a domain name, you can use openssl to create your own self signed certificate.

This allows you to login to your computer over HTTPS.

Next you'll probably want to add apache authentication along with exceptions for the local LAN block (192.168.0.0/16 or whatever).  This can be done with a simple set of rules defined at: http://httpd.apache.org/docs/2.0/howto/auth.html


How do I securely store and retrieve a many-time use key?

This answer attempts to guide you towards the ideal solution. Ideally, if an attacker can read your entire hard drive, it should still be impossible (in our lifetime) for him to get the key and data and decrypt without some additional interception. (for example a password). It is possible that this ideal solution is not feasible for your use case. More details required.

  Where do I store this key when not in use?

Encrypt the key, and store it on the hard drive.

  How do I securely retrieve this key?

Use a password to create a key that is used to asymmetrically encrypt your symmetric encryption key. This way, as long as the password is not intercepted, the symmetric key is unknown because the key has been encrypted. Further Explanation (The password can either be entered on boot, or it can be entered on login. More details needed.) Make sure that your key derivation routine is slow (100-1000ms) to make brute force sufficiently expensive.

  How do I securely use the key?

In the case of an SQL database related operation, perform the encryption in the application. Do not send the key or the unencrypted text into the SQL command, unless you are sure that there is no modify statement logging (binlogs), slow statement logging (slowlogs), likely intercepts using the show processlist command. Further Reading, Partially Relevant (my information is MySQL oriented)

Also note where you are storing the information. Some intrusions will only grant the attacker access to your SQL database, others will provide only non-root access to the filesystem, which means that UNIX permissions can be used to hide the data. Some attacks will provide read-only access, others will provide read-write, which means that the code could be changed to log the unencrypted information.

  What operations do I need to perform once encryption is finished to maintain security?

Perhaps make yourself aware of the heap dump possibility, swap reading. You should also make it a point to look on IT Security Stack Exchange regularly to expand your knowledge of security. (half joking, half serious)

It is possible that my answer is missing some important measures. I would suggest editing your question to provide more information.

You may also wish to examine how you are using the key, once it is made available. By this I mean, the encryption protocol that is used, as well as the algorithms used to create the stream encryption out of the underlying block encryption, may require examination. Further Reading

I trust the experts here will upvote me if I am right, or comment on where I am wrong.


Is it secure to send sensitive data through gmail smtp with nodemailer?

If you are worried about the confidentiality of the data you're sending:

Use end to end encryption and make it mandatory.

The two (more or less popular) alternatives that will both serve the purpose are

S/MIME
PGP/GPG

If you are only worried about the transfer to the google servers, as long as you are making sure using SMTP with TLS, the transport way is secure.

Note:

While the end-to-end encryption only encrypts the message body, the message headers  (as well as the message, if you are not using end-to-end encryption) are transmitted over the secure connection between the SMTP server and your server, thus only accessable for those parties, as far as your question goes.

Keep in mind that this is only true as long as the user does check his/her mails over a secure connection, which you have no control over.

At a minimum, if you soley rely on SMTP with TLS, all hops of your email must be trusted by you to exclusively use TLS and to respect the privacy of the user.

Those are, at least:

Your server,
Google,
The user's email provider,

Potentially many of those, depending on the forwarding the user has configured,

The user.

Bottom line being, as you cannot establish that trust:

Make either S/MIME or PGP/GPG mandatory to protect the sensitive user data on transit.


Unfortunately I think it's highly unlikely that you'll be able to recover any of the original encrypted data. Even if the data wasn't encrypted, the new installation of Windows would have overwritten many of the original files. The encryption that was originally there makes it nearly impossible.

Commercial data recovery software works by scanning empty portions of the hard drive for certain file signatures that would signal the start and end of a file. For example, JPG images always start with "FF D8 FF E0", so if the data recovery program sees this sequence of bytes in the disk, it would know that this is the start of a JPG image and proceed to attempt recovery. If the data is encrypted, however, data recovery software will not be able to find any signatures because all of the data will be scrambled. It will have no way of knowing whether a sequence of deleted bytes is data that was originally encrypted, or just a random sequence of nothingness.

Even if you could extract all of the remaining encrypted data on the HDD, it probably won't be decryptable because you'll still be missing the parts that were overwritten by the new Windows installation.