Collect XML files from web server with secure authentication

The "level" of security for this really depends on what the XML files contain. If the XML files confidential data then you may want to explore further techniques than discussed here.

The suggestion of using basic auth can work however there are many reasons why you should consider using a different authentication method which has been discussed in the following question,

https://security.stackexchange.com/a/990/80801

If you're using SSL/TLS then you're more than likely fine using basic auth just consider the points made within the questions above. Another technique you may wish to consider is restricting access to the end point to only certain IP addresses. I would personally recomend using some form of authentication method provided by a framework of your choice rather than attempting to roll your own at any point.

As for the question about encrypting the files.... It wouldn't hurt to throw them into an encrypted zip as an additional layer of security. Ideally this would be protected with a different password / passphrase than the basic auth which is preshared between yourself and the third-party client.


The mainboard of my s7 passed away and i need to decrypt my SD card.
  Does Samsung store the keys in their cloud?

I do not think Samsung stores the keys in their cloud as it would expose them to law enforcement agencies asking for them.

  Is there any way to decrypt the card?

There are ways, however, none of them are practical:

You could try and crack the key, this would probably take years.
Locate the chip where the key is stored and read it with specialized
equipment; this might NOT be possible.

  I can't believe that once the phone dies (mb, whatever), the user
  loose immediately their data on the whole SD card.

The whole point of this feature is twofold:

Prevent people who have stolen your phone from accessing the data
Prevent you from tinkering with the Android system. An encrypted SD
card can hold apps, if the feature is enabled in the OS.

You have also lost the data on the phone. If you do not make regular backups, and backups of backups (I have three), then the data you hold is not important enough for you.

A lesson you have learned the hard way today.


Is it possible to take over the victim's system only by DNS attacks?

A successful DNS redirection means the attacker can redirect you wherever he wants.

He can setup a malicious website to exploit your system by various techniques. One example would be the recent exploits from Hacking Team; two 0-Days that can be used to exploit a fully patched machine remotely without any user interaction on all systems running Flash.

So no, you wouldn't have been secure even with what you've mentioned with someone redirected you to a website like that.

Seeing how 0-Days are discovered frequently in all programs, you could face the same situation anytime, anywhere.

Solution: DNSCrypt.

UPDATE: with all plugins deactivated, you would've been secure actually. It's good you're decreasing the attack surface, but still, that was one example. You get the idea.


If my Android phone has a virus, can I change its SIM into a new phone to get a clean start, or can the SIM carry over the virus?

There are a couple of possible issues here -

It is technically possible the virus is able to exploit a vulnerability in how android handles the SIM. If this is the case it could be transmitted via the SIM card storage.
There is a risk of reinfection. It sounds like you haven't identified the infection vector yet - how do you know you won't retrigger it? It also sounds like the replacement phone is old and likely out of manufacturer support.
It also could be a rogue app which may get reinstalled automatically via your google account.

Personally I'd view the risk as low. SIM based transmission would require more effort than its worth for a non-state actor. Reinfection is a risk. I would fully wipe then update the replacement phone before inputting google credentials / installing apps. If possible disable automatic app installation and manually review each one.

Alternatively as suggested in the comments have your provider issue a new SIM and transfer the number over. Again take steps to protect the new phone from non-SIM related reinfection.


(Disclosure, I work for Braintree, a competitor to Stripe)

At Braintree we also allow the CVV code to be passed in our API. You are correct that the PCI-DSS explicitly forbids non-issuers from storing the CVV. You are allowed to hold the code temporarily while waiting for the charge to be authorized. This is stated in PCI-DSS Requirement 3.2 (additional formatting is my own):

  3.2 Do not store sensitive authentication data after authorization (even if
  encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.

It goes on to define sensitive data as including the CVV:

  Sensitive authentication data consists of full track data, card validation code or value, and PIN data. Storage of sensitive authentication data after authorization is prohibited! This data is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions.

What this means is that service providers and merchants are allowed to take the CVV value, they just cannot keep it stored in their database for future use.

In the API you are looking at, the creation of a new vaulted credit card, the CVV is used to run a verification on the card. A verification is a type of authorization that ensures the account is active and able to be charged before we store it. After the verification is returned we discard the CVV. This allows us to give merchants a warning that the card their customer just added will fail the next time they go to use it.


To be exact, the RFC recommends legit heartbeats be done after handshake completes; it doesn't recommend exploits ever. (Compliant with http://tools.ietf.org/html/rfc3514 which sadly never made it to BCP.)

Yes, Heartbeat is a distinct record type (24 or 0x18). Any response longer than the request by more than reasonable padding is proof of exploit. Any request or response longer than 2^14 plus epsilon is also bad, and I'd say anything more than about 50 in TLS is suspect because that would only be useful for PMTU and PMTU here is useful only, if at all, for DTLS not TLS. You don't need the plaintext.


Just Works Bluetooth Low Energy Security

if you want to have encrypted communication on bluetooth layer, you will need a pairing process. Just Works is the most simple one but using Android or iOS you will still need to press a button at least on phone side.

A basic idea of the bluetooth pairing process is that no predefined keys are necessary. Therefor, the user can secure the connection between two devices out of the box.

From you post above, some questions arise:

Do you need encryption or authentication?
What is the sense of encryption in your use case if any device is able to connect, encrypt and communicate?
What level of security do you need? Security
against professional atackers or against someone accidentally
connecting to your device with a BLE scanner app?
Do you actually need encryption or signing?

Dependent on your requirements, there are different solutions. To my knowledge, BLE encryption without pairing is not possible (with usual smartphones).

You could install predefined encryption keys and encrypt data in your application. But then, you have another problem: How to distribute the keys? And if one device is hacked, how do you revoke keys? If all devices share the same key, your whole system is broken if one device is hacked.


Why don't PGP keyservers enforce double-opt-in?

Key servers may never be understood as a source of trust and valid keys. Their only job is to exchange keys, so users of OpenPGP can use the web of trust formed by certifications between keys to validate trusted ones.

Access to a Mail Address Does not Imply Impersonation

Trusting a key is (for most people) more than just verifying a mail address once. Mail addresses tend to change, to invalidate, even to be assigned again afterwards.

Validating an email address based on trust would require some form of invalidation, eg. removal. But how should for example a revocation or other changes be distributed afterwards?

Some Key Servers Do!

But, there are key servers doing so, and thus take the role of a certification authority. Ever wondered about certifications issued by the PGP Global Directory Verification Key? These are issued by the PGP Global Directory Service after validating the mail address contained in a UID, will invalidate after a given time without re-approval (six months, if I remember correctly) and your key will be removed from the server if the certification expired.

But remember: this key server is different from the others, as it offers a very basic authentication of key ownership, but does not support the OpenPGP "way" to validate keys using the web of trust.

How to Define Valid Keys?

As there is no central "trust institution", no certificate authority (or even not several hundred of them, as in X.509); who should define whom to trust? The key server operator? This would at best reduce the number of available keys by order of magnitude, in fact possibly to a few dozen or hundred trusted keys of the operator, compared with millions of keys mostly not even connected to the OpenPGP web of trust.

Additionally, each OpenPGP users potentially has his own rules to decide how to validate keys, although these might be rather similar most of the time.

Key servers simply form a method to exchange data between OpenPGP clients. and usually do not take the role of a certification authority.

Key Servers Synchronize

Most key servers synchronize with each other. Already the ones listed in the SKS key server pool list about two hundred of them, most of them operated by individuals who even don't know each other.

Having such a decentralized key server infrastructure is crucial against several attacks (denial of service, deletion of keys, having a central log of what's requested), especially from those having access to large portions of a network (ISPs, governments).

But: how should email address verification be achieved in such a distributed network of unrelated servers not trusting each other? The only possibility (at least, no other was proposed so far) is to replicate everything, and each key server would have to decide on the validity.

Would you like to approve each of your mail addresses to 200+ key servers in given (and very likely different and rather short) time intervals?


How can we verify an installer's validity by checking its signature?

Usually, a code signature is timestamped.  This way, the signature can be verified using the public key from a trusted certificate - even if the certificate is now expired - as long as the certificate was valid when the signature was made.


When to complete PCI DSS Compliance Paperwork

As you'll be processing payments, your acquirer should ask you to demonstrate compliance. Alternatively, other partners may request you demonstrate compliance. It's entirely possible no one will ask you to demonstrate compliance for some time.

If you're a merchant and transacting less than 6 million Visa or Mastercard transactions per year, you can self-assess using the relevant SAQ.

If you're a service provider and transacting less than 250k Visa or Mastercard transactions per year, you can self-assess using SAQ D.

If you are above either of the above thresholds, you're a Level 1 Merchant or Service Provider and will not be able to self-assess. You will need a QSA to perform an on-site assessment and complete a Report on Compliance.

If no one asks you to demonstrate compliance, you should still ensure you're familiar with the requirements and have the requisite security processes in place.


Yes it does work as you say. The chip is "tamper resistant" and will erase the "seed" (secret key) if any attempt is made to attack it. This is often accomplished by having a non-user-replaceable battery and a "trap" that breaks power to the device once the device is opened, or the chip surface is removed. The key is then stored in a SRAM, requiring power to keep the key.

The key is a seed, that combined with the current time in 60 second step (effectively, the current UNIX timestamp / 60), refreshes the code.

No, the device does NOT need to be precise. Instead, the server will store the time of the last accepted code. Then the server will accept a code one minute earlier, one minute ahead, and at the current time, so if the current time at server is 23:20, then it will accept a code from 23:19, 23:20 and 23:21.

After this, it will store the time of the last accepted code, eg if a 23:21 code was accepted, it will store 23:21 in a database, and refuse to accept any code that was generated at 23:21 or earlier.

Now to the interesting part: To prevent an imprecise token from desynchronizing from the server, the server will store in its database, if it was required to accept a 23:19 code or a 23:21 code at 23:20 time. This will ensure that at next logon, the server will correct the code with the number of steps.

Lets say you at Clock 23:20 login with a 23:19 code. Server stores "-1" in its database (and if it would be a 23:21 code, it would store "+1" in database). Next time you login, Clock is 23:40. Then the server will accept a 23:38, 23:39 or 23:40 code.
If a 23:38 code is accepted, it will store "-2" in database, at 23:39 it will keep "-1" in database, and at 23:40 it will store "0" in database.

This effectively makes sure to keep the server synchronized to your token. On top of this, the system, if a token "ran too far away" from the server (due to it being unused for a long time), allows resyncronization. This is accomplished either by a system administrator, or a self service resynchronization service is presented where the token user is asked to provide 2 subsequent codes from the token, like 23:20 and 23:21, or 19:10 and 19:11. Note that the server will NEVER accept a token code generated at or prior to the time that "last used token code" was (as this would allow reuse of OTP codes). When a resyncronization is done, the token will store the difference from the provided 2 token codes, and the current server time and in a resync, the search window could be like plus/minus 50 steps (which would allow about 0,75 hours of desync in both directions).

The server can detect a desynchronized token by generating the 50 prior codes and 50 future codes, and if the specified code matches that, it will launch the resync process automatically. Many times, to prevent an attacker from using the resync process to find valid codes, once an account is in resync mode, login will not be accepted without resyncing, which would require the attacker to find the exact code subsequent or prior to the code just found.


How can I send and receive untraceable emails?

Forgetting the reasons behind why you want to do this for the moment and focusing on the technical side of your question.

Your best bet would be the following:

1) Download Tails, a linux 'Live CD' which has a focus on privacy
2) Load it up on your laptop, connect to wifi at a public hotspot such as Starbucks or McDonalds (pay in cash if you intend to eat/drink anything)
3) Connect to the TOR network (it should be integrated into the Tails distro)
4) Pick one of these 'snoop proof email providers' and sign up for an account
5) Only ever access the accounts/send mail etc via the above steps
6) Shut down your computer, remove the Live CD and leave the internet hotspot. There should be no evidence of your email anywhere

Note: While your in the Tails environment, DO NOT do anything outside of your intended purpose (such as checking your real email/facebook etc), this could potentially be linked back to you if you do. Furthermore, DO NOT be tempted to check on your email account from home/work etc. Only ever do it from within the live CD, on the TOR network at an internet cafe of some description.

Technical stuff aside, listen to the other advice posted here and seek legal advice.


Would the theory of creating tons of duplicates of a small file, 'wipe' the hard drive?

Not surely.

If there is some data deduplication mechanism in the disk - even if it is only a side effect of its wear leveling mechanism - then your data multiplication will only result the low-level overwrite of only a small part of the disk, and not the whole one.
If your file size is smaller, or isn't an exact multiplicate as page size of your CPU architecture, or as the physical sector size of your disk, then the last part of them may left without overwrite.
Even if you fill all of the allocatable space in your filesystem with files, there may be blocks in the filesystem - directory entry tables, i-node tables, MFT, file metadata, cache/index data, any reserved data area - which won't be overwritten.
Also the wear leveling mechanism can have a hidden reserved area for free / unused blocks
Simply trimming (de-allocating the block on the hardware level) doesn't surely destructs all of its data. In many cases it only says the wear leveling mechanism, that it can re-use the block, and doesn't overwrite anything. Thus, not overwritten blocks may still remain intact, even after a block-level rewrite with random data (the idea what they suggest is much weaker as this).

In case of an Apple site, the probable reason behind that they suggest a lot of small files, that they have fear from filling the disk with a large, single one. But, if you want to make sure without block-level overwrite, this is what you had to do. On any unix system, incl. OSX, there is a command dd command for that, but there are also a lot of disk wiping tools for that.

In case of SSD: the disk sectors of an SSD disk can be overwritten only 10000 - 100000 times, after that they will die. The SSD controlling electronics has an internal reindexing mechanism to balance this load (some sectors are overwritten many times, these are re-mapped through the disk sectors). This is the wear leveling, and this will be overloaded if you overwrite the whole disk with random data on the sector level. Essentially, all of your data blocks get a single hit of overwriting. But a whole-drive wiping is not an everyday thing in the life of an SSD disk, doing this once is yet negligible harm, but it is better to know.

You can find some relatively sure ways to wipe the disk here.

On my opinion, a common "mortal" never meets technologies or organizations capable and willing to do such low-level data recovery techniques. Thus, the many question cycling on the about this is grounded mainly on the serious over-estimating the real threats.

For example, if you are a commoner trying to wipe a hard disk before selling it, a simple reformat will be enough. If it contains your very sensitive data, then wipe it with a specific tool. Even the forensics won't (be able to) go deeper.


What to do when using your private key from another computer?

A more secure alternative is to create a new keypair that you use for this purpose.

Create the keypair on your boss' computer.
Transfer the public key to your own computer.
Connect to the server and add the public key.

Now your boss' computer can connect to the server. When this is done, you can remove the key on the server. This way, your own key does not leave your computer and your boss' key is only valid a short while.


Is it possible to browse Windows 7 Previous Versions of an offline hard drive?

The short answer is maybe. Windows previous versions are held in what are called volume shadow copies. The volume shadow copy service (VSC) is what is responsible for keeping these previous versions of your files. So if you are looking for one you need to gain access to the shadow copy of the drive.

The VSC does not take up used drive space but instead uses free space to store the files, as the drive fills up these copies are automatically deleted to make room for used space files.

As for accessing it, if all you have is the drive itself the best thing you can do is follow a forensic or incident response method. EnCase has the ability to mount VSC from a drive image but I doubt you have access to it. If you do then create an image of the drive and then mount it in EnCase PDE and use vssadmin to access the shadow copy.

If not there may be a method that helps you but I have not tested it myself. I have been meaning to do a trail of this method to retrieve VSC files from a drive image but never got the time to make a lab suitable for it yet. It's on my todo list. However I think it might be your best shot to recovering the files if they are indeed held in a VSC.

The full blog post is located here:

http://windowsir.blogspot.ca/2009/11/working-with-volume-shadow-copies.html

It is important that you create a full disk image of the drive. A direct bit by bit copy. dd will do fine for this or testdisk, both linux tools you can use easily to create a suitable image. I urge you not to use the drive itself for this kind of test. An image can be replaced. The drive cannot.

Follow the steps this person used to access and manipulate VSCs and you may be able to mount your VSC and find what you are looking for.

Good luck!


The reason is simple: Firefox (I think from version 27 on-wards) now encodes (URL encoded) everything and you can now only exploit DOM XSS in Firefox if in the code developers will do explicit mistake of decoding.

You may find this recently published article useful: http://www.lanmaster53.com/2014/3/dom-based-xss-revisited/


Is there any issue using the PHP crypt() function with an additional salt?

Your script is atrocious in several ways:

As was pointed out by @Corneliux, PHP's crypt() function uses the old DES-based crypt() function from the Unix world (precisely, what was used in Unix 20 years ago). It will use only the first 8 letters of the provided password, ignoring the rest. In your case, the first 7 letters are the contents of your $salt variable, not of the password. This means, in practice, that a user will be granted admin access as long as what he enters as password begins with a 'P'.
Even if crypt() used a decent password hashing function, you would still use it wrong. In PHP's crypt() function, you are supposed to provide the salt as second parameter; you don't glue it with the password; right now, you use the user name as salt.
Your $salt variable is not a salt anyway. The point of a salt is to change; ideally, each password hashing instance should have its own salt value (that is, one new salt for every user, and a new salt each time a user changes his password as well). An hardcoded salt value, always the same for everybody, is the exact opposite of what a salt is supposed to be.
Writing the plain passwords of users in the comments is, let's say, unwise.

Do yourself a favour: use a recent enough PHP (5.5.0 at least) and call password_hash(). That call will use bcrypt, which is as fine as you can realistically get. Don't fiddle with salts: just let the function generate a random salt internally; it will also store the salt encoded in the resulting hash value, which is fine.


How does ransomware connect to the Tor deep web?

Malware that needs to access a website in the Tor network often employs a Tor2web service.
These free services enable you to connect to an onion site with your regular browser. They provide a gateway to the Tor network over HTTP or HTTPS and connect to Tor themselves. This way, the malware doesn't need to come with a full-blown Tor client.
One of the most popular Tor2web domains is onion.to. You can basically append the .to extension to almost any onion link to access it from the clearnet. E.g., a mirror of The Hidden Wiki can be accessed this way:
https://zqktlwi4fecvo6ri.onion.to/wiki/index.php/Main_Page

While Tor2web is straightforward, there are also cases where ransomware prompts victims to download the Tor browser manually themselves and some malware uses actual Tor components to obscure their C&C communication:

Malware can just as easily use Tor as anyone else. In the second half of 2013, we saw more malware making use of it to hide their network traffic. In September, we blogged about the Mevade malware that downloaded a Tor component for backup command and control (C&C) communication. In October 2013, Dutch police arrested four persons behind the TorRAT malware, a malware family which also used Tor for its C&C communication. [...]
In the last weeks of 2013, we saw some ransomware variants that called itself Cryptorbit that explicitly asked the victim to use the Tor Browser (a browser bundle pre-configured for Tor) when paying the ransom.

(Source)


Separating Apache and MySQL over Tor for security, performance, and reliability

... I don't think this will work.

The latency and reliability will cripple your site.
Performance and reliability are unlikely to be close to acceptable due to the nature of TOR and any requests involving the database now including at least double the hops to service a client request, with a raised level of lossyness.

Security will also be worse I think; you'll want to run TOR on both servers to ensure other people aren't controlling your entry/exit nodes.  The requirements for this will be meek on ram/cpu but bandwidth requirements will go up, particularly if you're trying to hide from someone controlling networks you would need to be a gateway for a lot of other traffic if you're trying to hide.

I don't think I understand the security benefit of trying to hide the servers from each other like this.  If they compromise one they will know how to reach the other for the services in question - the only thing it hides a bit is that the attacker who compromises one machine will have a harder time finding other (non-key) services exposed for the other machine, maybe.  Additionally though, you're having to expose services to some degree through TOR (hopefully secured to some degree) that you wouldn't normally have to expose externally at all.


Tripwire report shows modification dates from when I was on vacation with computer shutdown at home

Are there any other traces in the system logs? It seems strange that someone could sanitize so thoroughly a system that the logs show nothing, and yet not spot Tripwire or at least reset the timestamps properly.
Try updating a package, and see whether the updated files have the timestamp of when you ran the update, or the timestamp of the original file inside the update packet (this is typical in Windows, not so in the Linux distros I'm familiar with, but on the other hand you did not say what distro you're using).
Also, you could compare the checksums with those of a known good version of your same distribution.
update
pam_systemd.so was officially updated (at least on the one system I checked, Ubuntu 14.04-LTS), and the patch was published the day you report:
-rw-r--r-- 1 root root 42864 Feb  1 16:01 /lib/x86_64-linux-gnu/security/pam_systemd.so

Notice that I am in Italy, but my system clock is in UTC; if you're in Spain, our files were updated within thirty minutes of each other.
So my guess is that someone booted up your computer at least twice (one in January, one in February), and whether he logged in or not, the system proceeded to perform automatic updates.
Depending on whether it's a laptop or a desktop etc., and whether it was plugged in, it is even possible that it might have turned on by itself (I had a desktop once that did that about once every two weeks, or in case of thunderstorms), and then turned off again by itself after some hours of inactivity.


Can I configure a router to control access from my children's telephones as well as other devices?

You could block the devices based on their MAC address. In short, a MAC address is a unique identifier for a device. This method can be used until your kids are smart enough to spoof them.

In your router you should be able to view all the assigned IP addresses, including their MAC addresses in the DHCP configuration. Then you could enable MAC address white-listing by entering the MAC address of the devices to which you want to allow internet access.

As you have not mentioned what type of router you have, I've added this (random) picture so you get an idea of what you're looking for:

Aside from the technical aspect, why not tell your kids they will lose their phone for a week if or when they start fighting?! And if they do it again, they'll lose it for a month.

Technology should not be a solution for your children's misbehaviour IMHO.


Asymmetric or symmetric - which makes sense in this scenario?

What you called "concerns" in your question is what in the world of information security is usually referred to as "protection goals". In your case, you are looking for confidentiality (no man in the middle should be able to read the data exchanged) and authenticity (only known-good entities should be able to submit data).

Note that authenticity is usually defined to mean that a message or piece of data actually originates from the source it claims to originate from - and this is exactly the crux of your question. If you know that there will only ever be one client, distributing symmetric keys will be enough to guarantee both the confidentiality and the authenticity of your data (assuming the keys do not leak).

If, however, there are (or might be in the future) multiple clients (or servers, for that matter), you would need to either

Distribute different symmetric keys for each client-server relationship, or
Use the same symmetric key and use some other means to ensure the authenticity of the data exchanged (i.e., to make sure clients cannot send data claiming to be another client)

Therefore, using asymmetric encryption with a PKI issuing certificates to each participant in the scheme might be the more future-proof solution. This would allow you to properly sign messages with each client's private key to ensure authenticity.

Please note that either way, you are probably looking for more than just authenticity and confidentiality (integrity comes to mind - you probably do not want a potential man in the middle to be able to modify data exchanged between the clients and the server). Therefore, make sure to use a properly vetted, high-level crypto API implementing established algorithms and protocols for all your cryptographic operations.

(There are a lot of pitfalls in crypto. For example, in many cases, it is trivial for a man in the middle to capture a properly constructed message and replay it at a later point. Thinking of such attacks and defending against them by combining cryptographic primitives yourself is probably not a good idea).


What free tools or techniques exist to discover anomalies in network flows?

WireShark is a free tool you can use to monitor network traffic. Excellent tool to see if a hidden keylogger is trying to email and /or FTP logs because it usually has the address and password in the wireshark log.


How does OpenSSL generate a big prime number so fast?

Testing for primality is much easier than performing integer factorization.

There are several ways to test for primality, such as the deterministic Sieve of Eratosthenes and the probabilistic Miller–Rabin primality tests. OpenSSL uses several tests to check for primality. First they subject the number to the deterministic checks, attempting division of the candidate with a number of small primes, then a series of Miller–Rabin primality tests. The vast majority of candidate primes are discarded with the very first primality test. Any candidates which pass them are subject to further rounds of testing, each of which increase the certainty that it is a prime.

When using the Miller–Rabin tests, a composite number has a 75% chance of being detected as such at each round, so after a mere 64 rounds of testing, the probability that a composite number goes undetected is a staggering 2-128. In other words, the test has a 4-n chance of a false negative, where n is the number of testing rounds. There are also a number of much slower ways to test if a number is prime with complete certainty, such as the Agrawal–Kayal–Saxena primality test, but for cryptographic purposes, being really, really sure is sufficient, so they tend not to be used.

By default, OpenSSL tends to be extra paranoid and does some other tests, specifically for a safe prime. So when a prime, p, is found, it also checks if (p - 1) / 2 is prime. This is important for specific applications of primes such as Diffie–Hellman where safe primes prevent certain attacks.

This is possible at a high speed because verifying that an integer is a prime with an extremely low margin of error is significantly easier than factoring it, and because primes are not that uncommon (it is easy to find a large number of primes by incrementing a number and testing for primality). The Miller–Rabin primality test is very efficient. The test proves compositeness if xn - 1 ≢ 1 (mod n) (the Fermat test), and by testing whether or not x(n - 1) / 2e (mod n) is a nontrivial square root of 1 mod n where n is the integer being tested and x is a random witness satisfying the interval 1 < x < n.

The pseudocode implementation of the test taken from Wikipedia is:

Input: n > 3, an odd integer to be tested for primality;
       k, a parameter that determines the accuracy of the test
Output: composite if n is composite, otherwise probably prime

write n − 1 as 2r·d with d odd by factoring powers of 2 from n − 1
WitnessLoop: repeat k times:
    pick random integer a in the range [2, n − 2]
    x ← ad mod n
    if x = 1 or x = n − 1 then
        continue WitnessLoop
    repeat r - 1 times:
        x ← x2 mod n
        if x = 1 then
            return composite
        if x = n − 1 then
            continue WitnessLoop
    return composite
return probably prime

See this Crypto.SE answer on RSA key generation and the FIPS 186-4 standard, section 5.1.


Is it safe to auto-fill credit card numbers using Chrome?

Is it possible for breaching google chrome and take my credit card
  information?

Yes.

As long as Chrome can use your number for auto completion, it has to be possible for Chrome to access it. If one program on your computer can do this, another program or a least humans can do it too.

  it's not stored with any type of encryption

Even with encryption, the statement above holds. Chrome would need the key, and this key has to be somewhere on your computer so that Chrome can use it.

As long as someone can physically access your computer, few things actually help. Encrypting your whole hard drive and taking the key away with you is one possibility. Downside 1: It´s a pain to insert flash drive and password each time to turn it on. Downside 2: If someone gets your computer while it is turned on, everything is futile again.

If you only want to protect against attacks form the internet, this is much better, but nonetheless there is no 100% protection. Not entering your card number (or any sensitive data) in the computer is the only reliable way.


This "Onion" construct can be dangerous and should only be done if you have enough reviewers, it does however add multiple favorable properties compared to simple hashing:

The first unsalted MD5 can be done by clients or frontend servers. It normalizes charset and length and obfuscates passwords early on without being too CPU intensive.

The salt is read from the user database so it is not present on the client, this is was the first HMAC adds.

The crypto service (or better HSM) defends against brute force (as the secret key is not known). In fact this predates NIST recommendations to do exactly this. This peppering is not often done as it requires complicated system setup (HSM or process isolation) - something Facebook can afford.

Since the pepper step could be compromised by insiders, the data is then passed to scrypt, a function designed to make brute force testing of passwords more expensive.

The final step might not be needed, or maybe it is used to add some diversification (SHA2 instead of SHA1).

It looks a bit like snake oil overdo but the steps can be reasonable explained. If you compare it with the (much weaker) glibc-SHA2 Voodoo it is really clean.

BTW1: memorable Authenticator are generally a bad thing, such schemes can only reduce the risk of handling them.

BTW2: collision weakness of SHA1 does not apply to HMAC constructs and the short MD5 hash size does not hurt much here (as passwords almost always have even less entropy). It would be more risky for key derivation, but that’s not the task at hand.


What's the difference between end-to-end and regular TLS encryption?

Let's define end-to-end as where the message is encrypted by the sender and decrypted by the receiver. Nobody in the middle, not even the chat provider, has the ability to decrypt it.

Compare this to a simple chat over HTTPS. The message is encrypted by the sender, just based on the fact that TLS is used. Now, while the intended recipient is another user, the TLS connection is initiated with a server (think Facebook). TLS terminates at the server, and whoever controls the server has the ability to view the messages since they are not encrypted. Then, the message may be passed on encrypted over TLS again to the recipient.

The key difference is that the provider is able to view the messages in the second case.


Message telling me that I bought something with credit card

Chances are this is scam attempting to get you to call the number listed (which does probably not, as you think, belong to any real banking institution but is most surely heavily taxed).

If you have any doubt, your best option is to call your credit card company - the relevant number must be printed on your card - and ask them about it: they can verify what transaction was made with your CC and you might be able to dispute the charge right away.


Recently had a virus, can I use backed up files on clean system?

There is an abundance of ways untrusted files could cause harm to your system.

One popular way to verify if any single file is malicious is to use Virus Total:
http://www.virustotal.com/

  Virustotal is a service that analyzes suspicious files and URLs and facilitates the quick detection of viruses, worms, trojans, and all kinds of malware detected by antivirus engines.

Short of re-installing everything from trusted sources you cannot get 100% assurance everything is clean.


How to justify that a stored XSS that occurs after logging in is a vulnerability

The Dev team is wrong. The impact here is horizontal and vertical privilege escalation.

Post-auth XSS is just as valid as pre-auth XSS. Generally, you want the victim to be logged in anyways, as you want to exploit their current authentication. The only mitigating factor is that the attacker requires an account. Depending on how easy that is to get, the impact rating of the issue would go down, but it is still a vulnerability[*]

An attacker can use XSS to perform arbitrary actions in the name of any user visiting the page containing the payload, and read any data that those users have access to.

[*] Note that for some users this may be an accepted risk. Some applications would for example let administrators post unfiltered HTML, as they already have unlimited access without XSS.

If the payload would only be displayed to the user inserting it themselves, then that would be a different issue. You could only exploit it by either getting the user to enter the data (eg via clickjacking or CSRF) or by tricking the user to log into the account that placed the payload (eg via session fixation or login CSRF).


This is a comment, but space is limited.

Based on the information provided, the best advice is: do not attempt this.

  to use in some way AES 128 (or 256) and GCM mode

Go look at some security vulnerabilities involving encryption. The algorithm is important, but most of the problems arise in the "some way" part.

  All the communications must be encrypted

Then either you need to modify all the client code and all the server code or rewrite the networking stack in the OS.

Why do they need to be encrypted? Is it just for confidentiality as the data crosses the network Do you want to implement bi-directional authentication?

  this system is not connected to Internet...for a system that must stay online on Internet

Eh?

Do the hosts connect to/provide things other than the services you are trying to protect?

It sounds like you just need a VPN.

  any suggestion about which technology / library should I use?

You really don't understand what you are trying to achieve, so its understandable that you're not able to ask the right questions. There are lots of technologies available which are well written, maintained and supportable (but there's not even enough information here to point you in the right direction).


Automatic's Jetpack login auth....Why isn't this a security flaw?

(Disclaimer: I work for Automattic)

The OP is right to be concerned, because there is something wrong here. But, it's not nearly as bad as it appears on the surface.

WordPress.com is a WordPress Multisite network, so digest.bps.org.uk is not a separate site from wordpress.com, it's just an alias. It's the exact same server/codebase/database serving both sites. Once the application receives the request, it determines which content/theme/etc to show based on the hostname.

So, when you submit your credentials into digest.bps.org.uk, they are going to wordpress.com, because digest.bps.org.uk is  wordpress.com. Individual site owners do not have access to the code/servers/database, though, so they can't see the credentials that were entered.

The actual problem here is that it trains users to enter their credentials on what appears to be a different site, which would be dangerous in most situations. Fixing that is on our roadmap.

We make mistakes, but we do care deeply about security and privacy. If you come across anything else that seems wrong in the future, we'd love to hear about it privately first, so that we can have a chance to fix it before people with malicious intent learn about it. Our website describes the process for security disclosures.


Are ECB and CBC modes of operation generally insecure?

DESede/ECB/PKCS5Padding

DES is already broken and TDES is created to use until a new cipher is developed, called now AES.
The block size of DES or TDES is 64-bit and this is insecure, see Sweet32.
ECB mode for block ciphers, forget about it. It is not even a mode of operation. It reveals a pattern in your data. See the penguin on Wikipedia. In some case you may need it like equality queries in DB, however, it still can leak information, see How can frequency analysis be applied to modern ciphers?
PKCS5Padding See in the next section.

  AES/CBC/PKCS5Padding

AES is a block cipher and is supposed to be a pseudorandom permutation. It can achieve IND-CPA or IND-CCA or authenticated encryption using AES, by using the appropriate mode of operation together with AES. It is still secure after more than 20 years
CBC mode requires an IV and that not only unique but also must be unpredictable
PKCS5Padding is vulnerable to padding oracle attacks. Actually Encrypt -than-MAC can solve this issue.

  RSA/ECB/PKCS1Padding

RSA is not mean to encryption. It can be used for signatures with PSS padding or Key encapsulation mechanism like RSA-KEM with Data Encapsulation Mechanism. Composition of a KEM and a DEM provides the standard of IND-CCA2/NM-CCA2—ciphertext indistinguishability and non-malleability under adaptive chosen-ciphertext attack if an authenticated encryption mode is used like AES-GCM, ChaCha20-Poly1305, or crypto_secretbox_xsalsa20poly1305
ECB has no meaning here. It doesn't implement ECB. None is better here.
Here the PKCS1Padding indicates RSA with PKCS#1 v1.5 padding for encryption. There are at least 8-byte makes this padding probabilistic, i.e. if you encrypt the same text you will get a different ciphertext.

Using RSA PKCS#1 v1.5 encryption securely is hard and one should not be used to. There are Bleichenbacher's attack and its variants on PKCS#1 v1.5 padding. Also, there is no security proof of it, but Optimal Asymmetric Encryption Padding (OAEP) has been proven secure in the random oracle model. If you want to encrypt you should OAEP it, but better not to use it. Prefer the Hybrid Encryption.

Short conclusion

None of the above-listed modes is preferred today. In TLS 1.3 now we have only authenticated encryption modes.

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256

CBC, gone, TDES no more, all static RSA and Diffie-Hellman suites are removed.

Stay with the recommendations. In modern Cryptography we want

IND-CCA2/NM-CCA2—ciphertext indistinguishability and non-malleability under adaptive chosen-ciphertext attack

Therefore you need authenticated encryption modes.


Is having the username and password fields on different pages more secure?

From a security control perspective, all it really does is slow down the ability of automated password probing software to perform their task of trying out multiple passwords.  The site is hoping an attacker may choose a "softer" target instead of their site.  As an actual security control, this technique is not particularly effective.

Also, specifically for banks, this is one of several Industry
approved "security enhancements" that the U.S. banking industry is requiring
member banks to choose from.  In the U.S. in 2011, all banks and
credit unions were informed of new cybersecurity policy from the
Federal Financial Institutions Examination Council
(https://www.ffiec.gov/pdf/Auth-ITS-Final%206-22-11%20%28FFIEC%20Formated%29.pdf),
along with authentication guidance presentations
(https://chapters.theiia.org/western-new-york/ChapterDocuments/FFIEC%20Authentication%20Guidance.pptx).
I remember the bank I use converting their login pages in 2012 and 2013
to meet the new standards before their annual audit, including moving the password to a separate page from the userid.
Given all the
stolen password lists, the separate stolen email address lists, the
fact that most users use the same password on all the sites they have
accounts at, and the fact that most sites stupidly (from a security
perspective) force user-ids to be email addresses, there are new
types of highly selective "low-and-slow" over-the-web password
probing systems that take advantage of all the above.  So the site is hoping that making the login sequence slower to do the automated password probing may make the attackers give up sooner.

From a security UI design perspective, this UI design pattern does offer some useful advantages.  It allows sites that adopt it to add conditional authentication steps.  For example, a site can offer their users the option for a text-message token to create a two-factor authentication.  For those users that provided a mobile number, the sequence may be: page1=enter userid, page2=enter token, page3=enter password.  For those users that did not provide a mobile number, it is just page1=enter userid, page2=enter password.

This UI design template also allows for gradual conversion of their user base to newer and stronger authentication both over-a-timespan and user-by-user, which are both critical considerations for a site with thousands or more of users.
Another example, the bank I use in 2012 converted their login pages to first ask me for user id, then asks me to confirm an image I picked in my profile from a set of images, then finally asks for my password, all on separate pages.  Whether or not picking an image from a set of images really adds any authentication effectiveness is a separate issue from the question about the login UI design template.
A further example, some banks chose to implement a "UI Keyboard" to attempt to thwart key loggers (userid is entered on one page with a regular UI text field, then a second page is brought up with the "UI Keyboard".  One can debate whether an on-screen keyboard is or is not effectivesecurity-wise, but the UI design pattern of configurable and sequential authentication on separate pages allows sites this freedom to innovate.
Most sites do not prematurely end the login sequence if something is incorrectly entered.  The end-user enters all information in the various pages of the sequence, and only at the end learns if authentication was successful or not.  Some sites do exit early, which creates some institutional residual risk in terms of account validity detection.
Which specific authentication steps are shown can even vary by the particular user-id given what that user selected in their profile.  So sites that do this are not forced anymore to offer only one fixed authentication sequence for all their end-users.
Even more advanced login systems of this style can even vary the authentication steps for the same end-user who fails a first authentication, or is accessing from an unknown computer/device, or from an IP address that is significantly out-of-area, or if the site's automated IDS software thinks a password probing attack is in-progress.
So separating IDENTIFICATION from AUTHENTICATION (aka user-id from password and other steps) in the login UI gives sites more freedom and flexibility to evolve their login processes over time.  Those sites that change their login pages to this new template can further adapt or alter the login sequence in the future, yet have their end-users not feel like the login process is changing all that much.


How does SSH client ensure that SSH server bears the private key, which is the pair of the public key in client's "known_hosts" file?

The Secure Shell (SSH) Transport Layer Protocol (RFC 4253) describes how server authentication is done. According to section 7 there is implicit and explicit server authentication. Implicit authentication requires a shared secret between client. Explicit authentication means that the "key exchange messages include a signature or other proof of the server's authenticity". This is the kind of server authentication one usually uses, i.e. where the server has a key pair, the public key is known to the client and it wants to verify that the target of the connection knows the matching private key.

How explicit authentication is included in the Diffie-Hellman key exchange is described in section 8. Essentially the server signs some data from the client using the servers private key to prove ownership of the key and the client validates this signature using the known public key. These client provided data include random data so replaying an older signature is impossible. For the much deeper details see the RFC itself.


What is better salted hash or openssl encryption?

Generally hashing and encryption are for two different things. The main distinction in your case is that hashing is one way, and encryption is two-way. That is, you can decrypt the password to get them in plain text, but you cannot "de-hash" something.

If your system gets compromised and you are using encryption, the attacker will probably have all the information needed to decrypt all the passwords. This is obviously not good. If you hashed the password, even if the attacker got access to the hashed password and seed, they could not get the plain-text password.

For this reason, it's better to hash the password instead of encrypting it. Of course, this assumes you are doing the hashing correctly. Look into something like bcrypt to do this for you.


Is it possible to change the wifi password with a script?

I'm not aware of any routers providing an easy API to change your wifi password in an automatic fashion.

However, every wifi router that I have used makes it possible to change the wifi password by logging into the router through a web browser using HTTP requests (GET / POST).

Thus its possible to automate out these activities if you want; granted it will be specific to your specific webbrowser.  E.g., in python I can get to my router with using requests

import requests
pw = '<replace_this_with_your_password>'
requests.get('http://192.168.1.1', auth=('admin', pw))

Granted how to change the password, depends on the specific router, what POST variables it wants, what URL is required, etc.


What risks are inherent with connecting to an untrusted public key server?

I'm not sure if there's anything specific to OpenPGP, but the problem you describe doesn't seem specific to this context.

As far as I'm aware, the exploits that lead to arbitrary code execution (e.g. based on buffer overflows) could happen to the processing of any type of a priori untrusted data that could be processed. Whether it happens in the code that processed a malformed key or any other form of data probably doesn't matter that much in this context.

Whenever you run some code that processes some data that you don't already trust (and in a way that you trust), you want that code to be bug-free, at least free of bugs that would lead to arbitrary code execution or other security problems.
Whether the data is used later by a security mechanism is a secondary concern in this case.
(Of course you also want the implementation of the necessary signature verification to be correct. That's where it matters for security purposes.)

The same type of issue could happen with any X.509-based TLS stack, for example. You'd want the TLS stack not to allow malformed certificates let an attacker get control of your system (again, that's true of any system that process a bunch of bytes it doesn't know in advance). The correct validation and verification of the certificate that will let you trust the TLS connection established once the handshake has completed successfully is very important, but only a secondary matter, then.

I think the main difference compared to other types of data is in the difficulty of implementing this type of code correctly. The storage structures used in the context of PGP or X.509 tend to rely on ASN.1, which can be about as clear as mud in many cases. Writing bug-free code that deals with ASN.1 isn't easy (IMHO).

I think Thomas's quote ("...you should not trust the key server...") had more to do with the fact you can't trust the key server as an entity vouching for the key it serves. This is just a hosting service, as opposed to an editor/publisher/author.


Limiting FTP privileges on Windows Server

First things first -- FTP is a deprecated protocol according to the IETF.  It has been deprecated in favor of secure protocols such as SFTP.  I recommend using only SFTP and not using FTP, because FTP commands and usernames/passwords are sent in plain text.  Anyone monitoring the user's network (e.g. a coffee shop wifi) could obtain their password and easily get into their account.

That said, FileZilla server has a function called "Filename Filters" but this isn't enforced on the server, and can only be used from the client.  So, there is no way in FileZilla server according to the documentation that I see to do this.  That said, malicious files can easily be javascript files, or simply have no extension or masquerade as a legitimate extension such as .html.  If an exploit is run to somehow invoke the code in those files (e.g. being executed through another executable -- like a bug in the filezilla server, so ostensibly filezilla.exe is executing this code), it wouldn't matter what the file extension was, as that code will be executed.  Thus, the server's lack of support for this filtering isn't much of a security loss.

So, limiting filename extensions can provide a minor increase in security; but is definitely not a cure-all nor would it prevent a skilled attacker from exploiting your system -- thus probably the reason support isn't implemented in FileZilla server.  Instead, think of it as a small part of a comprehensive program of "best practices" to limit access, including using secure protocols such as SFTP, security hardening the server (e.g. CIS hardening standards), installing regular updates, antivirus protection, firewalls and/or intrusion detection, regularly updating the FileZilla server, et cetera.


Password length limits in history of operating systems and popular web sites

There are a variety of sources out there for this kind of information, but only for individual services or operating systems. It's rather hard to get exact dates and version information on a lot of this, because people still had old versions of software running, or changes weren't documented at the same time they were made. I've done my best to correlate the facts into a single list.

Services

Facebook: No limit (tried up to 1000 characters)
Twitter: No limit (tried up to 500 characters)
Twitter API: No limit.Windows Live ID / Hotmail: 16 characters. The service is now known as Outlook.com
MySpace: In 2009, there was a 10 character limit. This has been increased, but I've not tested the limits.
LinkedIn: In 2009, there was a 16 character limit. Again, this has been increased. Currently there doesn't seem to be a limit.
Google Accounts / GMail / YouTube: There has never been a limit.
OpenID: No limit.

Mobile

Android: No limits on unlock / device encryption / root passwords.
iOS: No limits on unlock / device encryption passwords. Root password uses old crypt, so limit is 8 characters (the rest are ignored). Tested on iOS 4 and 5. (source)
Blackberry: 32 characters (source).
PalmOS: 31 ASCII characters (source). This may have changed since 2001.

Operating Systems

Windows 95 / 98: 14 characters (split into two 7-character hashes)
Windows 2000 / XP / Server 2003: Technical limit is 127 characters. Password change dialog limits to 32 characters. If 14 or less characters are used, the old LanMan hash is used. If 15 or more are used, the newer NTLM hash is used.
Windows Vista / 7 / Server 2008: 127 characters.
Unix (1990s and earlier): 8 ASCII characters.
OS X: No limit. Earlier Apple OS products may have had limits, but these have not been thoroughly investigated or documented.
Linux: Varies between distributions. Old versions have the same problem as Unix, since they use the old DES-based crypt hashes. Most have no limit, since they use a proper hash algorithm. Some have a soft limit of 72, 79 or 127 characters.

Here's a quick rundown of password hashing in some popular distros:

Ubuntu: Early versions use MD5, 8.10 and later use SHA512 with a 64-bit salt.
Debian: 5.0 and earlier used MD5, 6.0 and later use SHA512 with a 64-bit salt.
CentOS: 5.0 and earlier used MD5, 6.0 and later use SHA512 with a 64-bit salt.
RHEL: Old versions used DES-based crypt with 8-character limit. After that, MD5 was used. Changed to SHA512 in version 4.7.
Fedora: Prior to Fedora 9, MD5 was used. Default was changed to SHA256 in Fedora 9, with support for SHA512 available.
Arch: Used to be MD5, was changed to SHA512 in November 2011.


Sure but I don't think that the certificate authority should receive CSRs by email unless they are employing a mechanism (like signing your email with PGP/GPG) to ensure that the CSR came from you (rather than someone pretending to be you).


How can I prevent people from duplicating my barcodes

You can't stop duplication of barcodes. What you're describing is a replay attack. The solution to this particular case is to keep a database of issued barcodes and their values. When a barcode is redeemed, the database must invalidate that code.

It works best if this system is online in which codes are atomically applied and cancelled. It is also possible to limit the window during which codes can be re-used in a batch processing based system if the terminals cannot be online, though any use of a code between when it is first redeemed and when that redemption is copied to other systems is a risk.


Can a client application volunteer to send a certificate?

The client will only send a client certificate when requested by the server. This CertificateRequest can be sent by the server in the initial TLS handshake. But it can also be sent in a later renegotiation (up to TLS 1.2) or post-handshake authentication (TLS 1.3). This is typically the case when only some resources on the server require client certificates and the requested resource is only known after the initial TLS handshake.


OpenSSL - 2040 bit temporary key size, 2048 bit private key

There is no mathematical connection between the key exchange and the authentication part of the TLS handshake. TLS handshake just needs some way to do Diffie Hellman which is secure and some way to do end-point / counterparty authentication which is secure.

So you can do DHE with at least 2048bit group, or ECDHE with NIST P-256, or X25519 as the key exchange part, and you can do RSA with at least 2048bit key with PKCS#1 v1.5 padding or RSA-PSS padding, or ECDSA with NIST P-256, or in the future ed25519/ed448 as the authentication part. [1]

You are free to mix and match DHE with ECDSA, ECDHE with RSA, ECDHE and ECDSA with different curves, DHE and RSA with different number of bits, whatever.

Each algorithm has its own requirements for how to do it securely, as long as each part is secure you're good.

There is an argument that each part should match the strength of the others, as the weakest part will naturally be attacked so extra strength on the part which is not weakest is just wasted effort / resources (basically, don't invest in extremely strong door if you have paper walls).

So people say that if your TLS Record Protocol / bulk encryption have 128bit equivalent symmetric encryption and MAC (which is what you get with AES-128-GCM which is what you should be using), the key exchange and authentication should be about 128bit equivalent strength. This would be 256bit ECC (so exactly ECDHE and ECDSA with NIST P-256 or X25519 with Ed25519) or 3072bit RSA with DHE. But most people use 2048bit RSA (which is secure enough, though it is considered only 112bit symmetric equivalent). So you can use 2048bit DHE or 3072bit DHE. 4096bit DHE would be overkill, but would work.

Against the argument of matching algorithmic strength, I have to say that matching auth and key exchange strength is wrong because a certificate used only for auth needs only to stay unbroken until its date of expiry. Key exchange needs to stay unbroken as long as the confidentiality of the data needs to stay unbroken. So if 10 years from now the enemy can break your current certificate which is used only for auth, you don't really care because they can't MiTM your connections 10 years in the future using a certificate that by then has long expired. But if they can break the key exchange they can decrypt the data, and if the data needs to stay secret even 10 years from now, that's a problem. [2]

Thus, there is logic in making DHE stronger than the key of the certificate, and 3072bit DHE with only 2048bit RSA cert makes some sense, though most people don't need it.

In summary, use openssl dhparam 2048 to generate a file that postfix smtpd will use (configuration confusingly called smtpd_tls_dh1024_param_file). It's fine to use 2048, 3072 or 4096 here with any certificate. That command does take a while to finish, let it.

1 - You can even do PSK which is symmetric authentication instead of asymmetric authentication, but ~nobody does this. You can do RSA encryption to do both key exchange and auth, though you don't get forward secrecy so it's not allowed for HTTP/2 and in TLS 1.3 (and you shouldn't do this even when it's allowed).

2 - If you allow RSA key exchange that means the key for the certificate was used for key exchange and it needs to be kept safe for as long as data confidentiality matters, so no losing the keys for expired certificates on old hard drives you throw away. This is the argument for only support PFS cipher suites.


I hate to say the answer is yes/no but given the information I have to and I will explain why. It really depends on your guests and your level of paranoia/how much time you want to spend administering this AP.

You can write iptable rules to keep a guest from gaining information about/accessing your internal network but you pretty much have to write a rule for every type of protocol that could leak including arp,dns,smb,bonjour,etc... While this is doable you would need to revisit these rules pretty regular and compare against packet captures you are collecting from the guest network to make sure they are still working.

If your guests are the hacker types things like 802.1q won't stop them. VLANs are designed for routing and network identification, not security. Vlans need something on top of them to do additional security. If you google VLAN hopping you can find resources to do this pretty easily.

In order to secure the setup you mentioned I would look at this article: http://www.zdnet.com/blog/ou/a-secure-wireless-lan-hotspot-for-anonymous-users/587 (its a few years old but the technology is the same). You can set up 802.1x auth on DD-WRT.

A quick example would be here: http://www.dd-wrt.com/phpBB2/viewtopic.php?p=684347

Don't forget to use different keys for your primary and guest network. If a guest can decrypt your traffic they might not be able to access it but doing packet caps would give them a lot of information about it.


027 on most systems. This gives a default of rw-,r--,--- which is suitable for me. I have seen some environments use 077, but unless the users are very limited in what the can do (so why give them a shell at all?) or experienced it just causes helpdesk/IT issues.


I found that I could delete the state parameter in an OAuth request and the response was validated and e-mail was still verified

I think it is not enough for the poc. Just make another account and see if you can validate it from the original account.


Comply with data protection requirements without giving away too much?

The request for this information may not only be for a security audit, but also a process audit, and it sounds like it might be well founded, since:

  If you wanted to break into their portion of this system, you come after me.

What would happen if you were "hit by a truck" tomorrow? If you are the only one that knows the systems, your clients and theirs would certainly have a big problem. Ideally, someone else needs to have access also, and it should be documented who that is and how to contact them.

Depending on the requirements, it may be possible for the holder of the keys to be a company rather than a person, perhaps with a primary and secondary contact named. The primary contact could likely also be someone at your client, and they probably should have all the documentation for how to access their systems in an emergency if you are not available.

Also, you may be able to provide a report with certain things redacted. They likely are more interested in knowing that the non-redacted documentation exists somewhere and that the proper people have access to it when needed. They probably won't care that the port numbers, etc. are blacked out, as long as they can be sure that they exist in a document somewhere.


How secure is this two factor authentication?

So two factor is when you authenticate with two pieces of information:

Something you know, passphrase for example
Something you have, yubi key, RSA token or a google authenticator

This way if an attacker has one - which in most cases will be a passphrase it will not authenticate without the piece you have. Your pin will only work if it is a OTP (One-time-password) otherwise you have actually just added a second password to your login process which will only slow an attacker not prevent them from breaching your site given the first passphrase.


OCSP and CRLs: Specified in CA or client certificate?

Short version: all the URI should be in the end-entity certificates.

For OCSP, the location of the OCSP responder should be specified in an Authority Information Access extension, which is described in section 4.2.2.1 of RFC 5280:

  The authority information access extension indicates how to access
     information and services for the issuer of the certificate in which
     the extension appears.

The OCSP responder able to give revocation information on a given EE certificate is part of a service of the CA, i.e. the issuer of the EE certificate. So the URI should be published as an extension of the EE certificate, as per the sentence quoted above.

For CRL, the primary role of the CRL Distribution Points extension is to segregate certificates into subsets, so that individual CRL may have a limited scope and remain short. This mechanism works by having the same "distribution point" appear in both the EE certificate (as part of a CRL Distribution Points extension) and the CRL which applies on that certificate (as part of an Issuing Distribution Point extension) (see section 4.2.1.13). Since distribution points contain "names" and names can be URI, it is customary to use such an URI as pointing to the place from where the CRL may be downloaded.

That OCSP responder and CRL download URI appear in the target certificate (the one whose revocation status is to be ascertained) makes sense: the corresponding servers are under the control of the issuing CA, so the URI are chosen by that CA, and can be set only in certificates whose contents are under control of the CA. The CA does not get to arbitrarily choose the contents of its own certificate: that certificate is issued by an upper CA (here, the "root CA"). Hence, the CA stuffs its URI into the certificate that it issues itself (the end-entity certificates).


Can an SSL client send CLIENT HELLO with version 3.2 and NOT negotiate 3.1

There is a theoretical way which is explained in appendix E of RFC 5246; but its implementation is not necessarily easy.

In the ClientHello message, the client sends a "protocol version" which is the highest that the client supports (and is willing to use). This includes the implicit message "but I may support some older versions as well". The server then chooses the version which will be used, and states it in its ServerHello message. For instance, the client may have sent "up to TLS 1.1" (encoded as 0x0302) and the server could respond "we'll do TLS 1.0" (encoded as 0x0301).

There is no way for the client to proactively announce exclusions (as in: "I support TLS 1.1 but I don't want to do TLS 1.0"). However, if the server tries to use a protocol version that the client does not want to support, then the client always has the possibility to close the connection. Appendix E says that:

  If the version chosen by the server is not supported by the client
     (or not acceptable), the client MUST send a "protocol_version" alert
     message and close the connection.

In all generality, if the client wishes to support only a non-contiguous set of protocol versions, then he can enforce that by dint of using several connection attempts. For instance, suppose that, for some reason, the client wants to do TLS 1.1 or SSL 3.0, but not TLS 1.0. In that case, the client may first send a ClientHello specifying TLS 1.1 as highest supported version, and, if the server tries to use TLS 1.0, the client may close the connection (preferably with the "protocol_version" alert message), and then connect again, this time sending a ClientHello specifying SSL 3.0 as highest supported version.

This works only if the usage context is such that the client can attempt several connections (e.g. we are talking about HTTPS, with TCP connections that the client can open at will).

In practice, a server or a client usually supports a contiguous range of protocol versions (e.g. supports TLS 1.1 and 1.2, but not 1.0 or SSL 3.0). In that case, a single handshake attempt is sufficient: either the server will choose at the first try a protocol version which will be acceptable to the client, or there is no version which is acceptable to both client and server and it will never work.

Whether a given implementation of a SSL client offers an API to disable support of an old protocol version, is another question, of course.


How would an external attacker utilise universal plug and play to bypass a firewall?

UPNP opens ports on the router without user intervention. This means in your example the FTP server would (could) be exposed on the internet by the IoT itself.

This means if there was a vulnerability within the FTP server or poor programming/setup by the IoT company, then an attacker could attempt access just as if you had manually port forwarded the port to the device.

My advise in this example with UPNP is if you do not need it at all, turn it off at the router. If you need UPNP for a device then

make sure the device is patched with latest firmware
make sure the device doesn't have default username and password
make sure (if possible) any services that the device has running are disabled if not being used
ideally run the IOT devices on a different network to your main home internet (such as phones and laptops) - that way if the device is compromised the hop to other devices on your network is mitigated


Is sending "Access-Control-Allow-Origin: http://localhost:8888" dangerous?

For an attacker to make use of this CORS header, he must run Javascript on localhost:8888. Inspired by your question, I looked for a service that runs on localhost:8888 and allows an attacker to run Javascript. I found one:

MAMP is a webstack that runs on port 8888 by default, and comes with the vulnerable SQLiteManager. SQLiteManager has several vulnerabilities, one of which is XSS using CSRF, so an attacker could trigger Javascript remotely to run in the context of localhost:8888. It would then be able to read data from your high value target.

This attack is not really probable, since it would only work for users that are both visitors of your site and users of MAMP. Furthermore, MAMP also has a remote code execution vulnerability, so the attacker does not need the CORS header to read HTTP responses.


There's a lot to the PCI Standards that you'll have to get by reading the most recent standards. Read these standards in conjunction with the glossary, where it will explain things like what they consider "strong cryptography." For instance, PCI defines strong cryptography as:

  AES (128 bits and higher), TDES/TDEA (triple-length keys), RSA (2048 bits and higher), ECC (224 bits and higher), and DSA/D-H (2048/224 bits and higher).

To clarify something from #1 in your question, PCI is requiring migration from SSL (any version) and early TLS (version 1.0). The terminology PCI uses is "SSL/early TLS." More about the migration can be found in PCI's information supplement, Migrating from SSL and Early TLS, or in Appendix A2 of the current standards linked above.


What are the problems of using OTP encryption with TRNG?

First, let's get some terminology straight. In order to call something a one-time-pad, the key must be truly random. So with that in mind:

You almost asked two separate questions:

I am using CryptGenRandom() to generate my key. Is this good enough or should I consider using a TRNG?
If I use a TRNG, what practical problems, if any, are there in deploying OTP with TRNG?

For Question 1, as I understand it, the only way anyone has ever successfully cracked (i.e. re-generated the proper seed) for CryptGenRandom() is by gaining access to the original machine where the key was created. And that was using a flaw in Windows 2000 which is 15 year old technology. So, based on that (combined with smart people at MS claiming it's cryptographically secure), I would argue that yes, CryptGenRandom() should be practically good enough to be used for key generation.

That being said, some high bit encryption should be good enough too, and if someone is thinking about using OTP instead of some other method of encryption, they are likely paranoid to the point that good enough isn't going to cut it. In other words, if you're going to implement something that you can truly call OTP, it must be absolutely impossible to crack your implementation without the key, which you cannot accomplish unless you use a TRNG.

As for Question 2, IMHO, there are no practical problems with using a TRNG. The reason is that only 1 trusted party involved in the communication needs to have the TRNG, not everyone. The harder problem is with key distribution, not key generation. The party with the TRNG (USB dongle or some other contraption) could generate a large set of random data, and then distribute the data to all involved parties. Each party when sending a communication would then simply need to specify the offset into the random data where their key begins. When the random data set is used up, a new data set can be generated.

However, the fact that someone involved in each communication has to initially obtain a hardware device in order to create the key may be considered a "problem", depending on how you look at it. This could have an effect on your "sales pitch", so to speak, since you won't appeal to impulse users who want to send a message with unbreakable encryption right now; all new users will have to wait some amount of time to obtain the TRNG device. You could consider using a service such as www.random.org, but if you do that, your ultra-paranoid users may not like the fact that the key is being downloaded over measly SSL!

TLDR; Regardless of whether you use CryptGenRandom() or a TRNG, the hard part is not actually in key generation, but in distributing the keys to each party so they can decrypt the message.


How can I tell which process is generating SYN traffic to localhost?

The problem with tools like netstat, ss and lsof is that these work on snapshots of the network state. Connections that are reset during the setup will not show up with high probability.

While Wireshark can capture the TCP packets, it will not be able to tell the process ID that was responsible for it. This information is not provided in a normal Ethernet capture. There is a different mechanism (NFLOG) that can log packets as seen by Netfilter (iptables), but this may at most contain the User ID of the process that generated a packet.

One approach to tackle the issue is by stalling or completely dropping network traffic.

Using Wireshark, you could for example determine that the port range is within 5037-5585.
Add a new firewall rule that drops newly initiated TCP traffic to the loopback interface for that port range:

sudo iptables -I INPUT -p tcp -i lo --dport 5037:5585 --syn -j DROP

Now you can use netstat, ss, etc. to find the offending program. For example:

sudo ss -tapn | grep '5[0-5]'

When done, remove the firewall rule again such that new connections can occur:

sudo iptables -D INPUT -p tcp -i lo --dport 5037:5585 --syn -j DROP

I used this approach to identify that the ADB daemon was trying to connect all the time to some local ports, presumably to locate an Android simulator.


What's the difference between pixie attack and other attacks on WPS?

Pixie works by exploiting weaknesses in the generation of the E-S1 and E-S2 nonces which are used to produce the enrollee hash, as described in the Pixie Dust Attack.

Traditional attacks attack the two halves of the WPS PIN (PSK1, PSK2) in an online attack, essentially brute-forcing all possible options for the PIN until it is found. This has to be done online against the target, so it takes a long time.

The WPS exchange involves computing two hashes (E-Hash1, E-Hash2) which are derived from two nonces (E-S1, E-S2), the public keys of the enrollee and registrar (PKE, PKR), the authkey (a value derived from the Key Derivation Key / KDK), and two halves of the WPS PIN (PSK1, PSK2). The values PKE, PKR, E-Hash1 and E-Hash2 are known by an attacker since the router will give you them (or you're providing them as a client) and you need to find the correct combination of E-S1, E-S2, PSK1, and PSK2 in order to break the hash offline.

Cracking the PSK1 and PSK2 parts is relatively easy; there are only 10,000 possible values for PSK1 and 1,000 for PSK2 (the last number is a checksum) and each hash is separate so you only need to compute 11,000 hashes. This doesn't take a lot of time on a modern system.

However, the problem is that you need to know the two nonce values E-S1 and E-S2. This makes the offline bruteforce approach untenable, as these are 128-bit values.

The crux of the Pixie Dust Attack is that the E-S1 and E-S2 nonces are not generated securely in many routers. As an example, MediaTek routers are known to just use zero for both values. In some Broadcom routers, the PRNG used is a weak one (likely an LFSR or something like Mersenne Twister) and it is also used to generate the PKE. By guessing the possilbe PRNG seed values until you find one which generates the same PKE as the router gave, you can then generate the E-S1 and E-S2 values trivially. Realtek routers use the Unix timestamp in seconds to generate the PKE, E-S1, and E-S2 values, but since the generation is fast it's usually the case that E-S1 = E-S2 = PKE (or E-S1 = E-S2 = PKE+1 in the case that it did tick over a second boundary) and since we know PKE, we now know E-S1 and E-S2.

This is why the Pixie attack is so fast. Instead of trying 11,000 possible PINs against the live router (which is slow and might result in the router blocking you), it captures the WPS hash values and cracks them offline, utilising weaknesses in nonce generation so that it only has to try 11,000 PIN values against each possible guessed E-S1 and E-S2 value pair.


What are the risks of allowing business users direct production database access?

Just about any one piece of data from this document should be sufficient:

http://pages.clearswift.com/rs/591-QHZ-135/images/Clearswift_Insider_Threat_Index_2015_US.pdf

The kicker for me: roughly 75% of all data breaches start internally, with a large chunk of those being accidental breaches as a result of employee mistakes.

The more employees who have access to your data, the more space there is for accidents to happen.  Not just the "accidentally drop database" type of accidents (which baldPrussian discusses on in his answer), but the "took a picture at work, posted it on facebook, and didn't notice that my monitor in the background was display the production database password" kind of mistake.

I once had an employee post a video to facebook from his office, and in it his camera panned nice and slow across his monitor, showing all the code he had been actively working on at that moment.  Fortunately it was just front-end javascript and had no access credentials in it, but I nearly had a heart-attack.

Mistakes like that happen.  If it hasn't happened yet, consider yourself lucky.  But it will happen, because we are all human.  The only question is how much it will cost your company.  Accidentally drop your database?  If you have a current backup you may only lose a few hours of work: relatively cheap.  Disgruntled employee with full access to your production database?  Who knows how much that one will cost.

You can talk to Uber about the cost of these things. Their recent data breach was effectively caused by giving too many people access to their production systems.  The direct cost in dollars will likely be very large, and many years before they are done paying for it.  The legal ramifications will also take years to work out, and no one will be able to measure the loss of reputation from all of this.

Audit Trails!

h/t to baldPrussian
Another big downside of giving everyone direct database access is the complete lack of accountability it creates.  Above, I focus on the fact that accidental data breaches from employees are a thing.  Unfortunately, intentional data breaches from employees are also a thing.  They are less common than accidental breaches, but they do happen.  The problem with everyone getting full database access is that if data gets leaked, stolen, or maliciously modified, your chances of properly identifying the problem employee are substantially decreased.

Summary

Having worked predominantly for and with small businesses, I know that there is very much an attitude of trust.  When everyone knows everyone (and knows their kids by name), everything starts from the perspective of "This is a good person.  I don't have to worry about them.  Let's let them have access so they can do their job easier".  I'm sure this is how your company approaches the problem.  They are operating from a position of implicit trust.  As a result, I think your best bet is to focus on the potential damage done by accidental mistakes.  The issue is not that they can't trust their employees, but their employees are people and make mistakes just like the rest of it.  The more people you have who have direct access to the center of your business, the more likely it is that someday someone will do something that will accidentally nuke your business.  Again, this stuff happens.  If you need another example, just ask Pixar:

https://thenextweb.com/media/2012/05/21/how-pixars-toy-story-2-was-deleted-twice-once-by-technology-and-again-for-its-own-good/


Preventing DDOS attacks without collecting personal data?

It's not possible.
DDoS is a layer 3 issue, which means that IPs are the primary piece of data. Blocking DDoS higher up the stack will not be effective, and it is not possible to go lower in the stack. So, at some point, DDoS defences rely on IPs.
And if IPs are the dependency, then other realities come into play, like the fact that innocent people might have the same IP as an attacker. This is true for different users behind the same NAT.
You also appear to be of the impression that identifying users is somehow a part of DDoS defence. It isn't. Since this is a networking issue, and not an application issue, the connection between IPs and any user accounts is not made. Defences occur before the application.
So, not only is this not possible, but your requirements are unnecessary.


Is it secure to store a two factor authentication seed in a password manager?

Assuming you mean the initialisation code for a given 2FA series, such as required when you first configure a TOTP generator for a specific service, then yes, storing it with the other login details isn't ideal.

As you say, should someone gain access to the password safe, they'd be able to log in without any hassle by using their own TOTP generator with the same initializations.

If you wanted to keep 2FA initialization values, a second password safe, kept apart from your day to day one wouldn't be a terrible idea, but you wouldn't want to keep the password in the main safe! Since you should only require the values very infrequently, they don't need to be as easily accessible. Even a print out in a safe may be acceptable.

Some services allow you to generate one use codes to regain access to your account in the event of 2FA device loss or failure. In that case, it's probably better to rely on those, rather than keeping the initialization values around, since they usually can't be used to gain access without a notification being sent.


How do I secure devices for use on conference wifi?

A VPN solution would be suitable here. It allows your family member to connect to any public (in your example conference) wifi hotspot and have all their internet traffic protected from being snooped on or otherwise interfered with.

You mention in the comments at the top about trust. Yes a VPN moves the who you trust to someone else. But then that applies to anything on the internet, including which ISP you trust to connect to the internet to start with. If you use an OpenVPN solution you could setup a VPN host at your home and get them to connect to that. That way they will be using your internet. But personally if you do not know how to do that I would suggest using one of the many VPN providers on the internet, some free some paid for.

Also make sure their device has been patched with an AV and firewall enabled to stop local traffic attempting to access their laptop.


Risk of configuring MySQL for remote access with a dynamic IP address?

You are extending your trust to outsiders beyond your subnet neighbors.

  By default, MySQL uses unencrypted connections between the client and the server. This means that someone with access to the network could watch all your traffic and look at the data being sent or received. They could even change the data while it is in transit between client and server.

This, of course, means any device between you and the server and everyone with access to those devices (either authorized or unauthorized).

If the data is valuable then I would do more to ensure the security of it.  Several options exist to help you secure all the traffic, including:

MySQL supports secure (encrypted) connections between MySQL clients and the server using the Secure Sockets Layer (SSL) protocol (http://dev.mysql.com/doc/refman/5.5/en/secure-connections.html)
OpenVPN (http://openvpn.net/) and/or SSH tunneling (http://upshell.wordpress.com/2011/02/23/connecting-to-a-remote-mysql-server-securely-using-ssh-port-forwarding/), which are free.  (options mentioned by @Jeff Ferland)


Would it be easier to be tracked if you were using an IP phone, cell phone or satellite phone?

All mobile phones transmit, so an IP phone connects via wireless networks, a cell phone connects via towers and a satellite phone connects, well, via satellites. Which means signal is traceable. If you are important enough, you can be tracked.

All of these services have location facilities - but how useful they are can depend on who is trying to find out the location.

Mobile phone service providers have triangulation data from cell towers, and law enforcement can generally gain access to this data (in disasters, other groups may also be given access). It is reasonably accurate (to within a few metres)

Satellite phones are not as simple to locate, but locations can typically be worked out in a similar way to the efforts to find Malaysia Airlines flight MH370. The last transponder communications gave search organisations an arc of possible locations. In that case, because there were only a couple of pings, the arc was incredibly long, and across inhospitable ocean, so finding the wreckage was very difficult. If your communication was targeted, it would be possible to narrow down the arc considerably, and if you had to connect to multiple satellites, each one would give a different arc - locating your general area to greater and greater precision over time. Short calls could provide protection here.

IP phones leak routing data, which could be used to locate you to within WiFi range, and with some analysis of data, range from the wireless access point is possible. Routing through a number of networks, and obfuscating where possible will help - although calls suffer badly when this is too extreme.


A lot of software exists for this reason. And some of it can be managed by a single person, or a whole team of people. The main principle about this is:

Identify what you will be logging.
Identify what type of information you need (operational or security)
Identify use cases; malicious user logs in, someone logs in at odd hours, someone who isn't supposed to allowed logs in.
Identify with the given infrastructure how to collect these events.
Create the alerts, plug in your email, and wait until something happens.

This type of tool that you are looking for is for Information Security purposes, although other tools of the opertaional standpoint have started to create themselves as SIEM operators. What is a SIEM? (thanks to wiki)

  Security information and event management (SIEM) is a term for software and products services combining security information management (SIM) and security event management (SEM). SIEM technology provides real-time analysis of security alerts generated by network hardware and applications.

I am not affiliated with any of these development of these tools, nor do I work for any of the companies that sell them (although I do work WITH the tools themselves).

I am going to break this down as a cost basis. From Free(ish) to Expensive, and also give you some information on identifying the type of information you are looking for within them. These will allow you to put all the data within one place and receive an email when something occurs rather then reading Event Log all day (BLEH!).

OSSIM

  OSSIM provides all of the features that a security professional needs
  from a SIEM offering – event collection, normalization, and
  correlation. Established and launched by security engineers out of
  necessity, OSSIM was created with an understanding of the reality many
  security professionals face: a SIEM is useless without the basic
  security controls necessary for security visibility.

This product provides a good foundation with the ability to receive Event Log, Syslog, and other types of events, create rules, and receive alerts when something happens that you didn't want to. This is free, and coupled with there Threat Intelligence data.

Splunk
https://www.splunk.com/view/it-security/SP-CAAAAKD

This is an operational software gone security. It does some of the more basic features of correlation, the rules are easy to make and it looks flashy. It's easy to use and easy to setup. A lot of people use this free version although alerting is lacking in the free version.

Nitro (McAfee)

This is one of the expensive ones that will require 8-10 months of configuration and build out time to make it manageable by a single user.

ArcSight (HP)

The bohemouth that is HP's ArcSight, as beautiful and amazing as it is, it requires a lot of working to keep it running. Although it is one of the best products out there, its really expensive and likely not worth the purchase for your use case.

--
So I hope this helps you identify that it isn't difficult to configure something like this and just wait around for emails about alerts.


There are three methods used for authentication: something you know, something you have, and something you are. The first is generally a password. A key file is an instance of the second, something you have. The more of these methods you use together, the more secure your database.

Your issue would be an attacker stealing the key file. Having it on a separate USB is a good plan, but an attacker could still steal it. I always use a password as well a key file.

You might also want to invest in a hardware token, such as Yubikey, if you were really paranoid. That would make it very difficult for an attacker to extract that portion of the key, even if they stole the key itself.


To extract sensitive information from plain old HTTP passive sniffing is sufficient and it is also possible to just passively capture the data and analyze later. To extract the same amount of information from SSL (HTTPS) an active man in the middle attack is needed in order to create a SSL connection between attacker and client and another one between attacker and server. Certificate validation just lets the client detect such an attack before any data gets transmitted, i.e. even if certificates are not properly validated the attacker still needs to do an active MITM attack and passively sniffing the encrypted data is not sufficient.

If such an active attack is actually harder than a passive sniffing depends on your specific environment.


What data related to a specific web page can be obtained outside the browser?

You should avoid consider storing sensitive data at all. Conceptually, if a system is compromised, it doesn't matter where you store the data; any code that can examine's the browser's memory doesn't need to directly access localStorage or an indexedDB, since it could be read straight from memory. So, store only the data you need, but keep in mind that a compromised device cannot be trusted at all.


What security operations provide confidentiality, integrity and authentication?

Your question is difficult to answer because security is a property of a system, not a property of a single technology or algorithm.

Confidentiality

It can be assured using encryption, but that's not enough. You need to look at the whole system to give a meaningful answer.

Here's a system that uses encryption and doesn't guarantee confidentiality: The WEP wireless encryption system. It is flawed because is reuses IVs too fast (I think), meaning that you can decrypt WEP communications after listening to the encrypted traffic for a while.

Also, sometimes the content of a message isn't as important as the fact that there was a message at all. So just knowing that A sent a message to B might already be enough to destroy confidentiality. If you call a suicide prevention hotline and I learn of this conversation, I can be fairly sure what you were talking about without knowing the exact content of the conversation.

Integrity and Authentication

You have a related problem when using encryption for integrity. Assume you're using a block cipher which encrypts data in 8 byte blocks. Assume you're trying to protect the integrity of the string "I give Reinards $1000000". You encrypt that, yielding "a7nBg2iUlRaM1iiRT64O21pm". What's to stop me from taking the last 8 bytes of the ciphertext and replacing them with something else? As long as it decrypts correctly, how are you going to know it's not the original? And what if I manage to replace the last 8 bytes with something that decrypts to "$9999999", or "my child"? Okay, maybe the times where we sold children into slavery are over, but you've just given me much more than you bargained for. So you don't need encryption for message integrity, you need message authentication, which is commonly done using message authentication codes.

Availability

Availability means the data is there when you need it. You don't just "have" availability in contexts where data sits in a datacenter at the other end of the planet. A large number of systems must interoperate perfectly to allow you to look at that data when you want it. One of these systems may be Nagios, which alerts people to service disruptions. Another might be a set of high-availability solutions which switch over to another datacenter when the first one currently suffers from a power outage or hurricane damage. This has nothing at all to do with encryption or digital signing.

The currently gravest threat to service availabilty is probably distributed denial of service attacks, which are very difficult to counter. No amount of encryption or digital signing can help here.


Storing passwords online using Gmail documents

I have done that before and it is a fairly good solution when you need to share certain password lists with other administrators. Yes, your gmail account can be somewhat safe if you use it correctly. On the other hand, gmail is also a pretty big target, is susceptible to government subpoenas, and you have to be VERY careful that everything that connects to your gmail account uses a trusted SSL connection. It is very easy to take over a gmail account just by sniffing unencrypted traffic.

My preferred solution, other than an online password manager, is to place a password-protected excel spreadsheet on a shared cloud storage folder.