How should I make diceware passphrases more memorable?

Throw out passphrases until you get one you can remember -

If you look at 16 passphrases, and keep the one you like best, then you've reduced your entropy by at most 4 bits (log2 16 = 4).  The intuition is similar to what you gave for rearranging: the worst case is that there is logically only 1 of those 16 passphrases that someone is likely to choose.

In general, if you look at N passphrases and keep the one you like best, then you've reduced your entropy by at most log2 N bits.  If you throw out N-1 passphrases and keep the Nth, then this is basically the same situation, so you can estimate that you've probably reduced your entropy by at worst log2 N bits.
Throw out individual words that are difficult for you to remember -

Let me suggest two different methods to calculate how much entropy you've lost:

You could think of this as taking your 7776-word dictionary and throwing out a bunch of words that are too difficult for you to remember.  If you throw out 1000 words, you've reduced from a 7776-word dictionary to a 6776-word dictionary, so you've reduced the entropy per word from about 12.9 bits to 12.7 bits, or the total entropy of your passphrase from about 51.7 bits to about 50.9 bits.  Not much of a reduction.

Unfortunately, this calculation method is a bit tricky to use in practice.  To estimate the entropy this way, you'd have to peruse the entire word list and count how many words are too difficult for you to remember, or scan a random sample of the word list and use that to estimate what fraction are too difficult to remember.  (Also, this calculation assumes that whether a word is too difficult to remember is independent of the rest of the passphrase.)  It would not be valid to choose a random passphrase, reject it because one of the words was too difficult, choose a second passphrase, keep that one, and then reason that you've reduced the dictionary from 7776 words to 7775 words so your entropy goes from 51.6993 to 51.6985 bits.  That would not be valid reasoning, because it doesn't count how many other words might be in the dictionary that you also would have rejected, if they had been selected.
You could think of this as just another reason that you might throw out a passphrase.  Then we're back in the situation we already analyzed above ("Throw out passphrases until you get one you can remember").

Rearrange words so that it is easier to remember -

You've already covered this in your question, and yes, your reasoning is accurate.  You've reduced entropy by at most log2 4! = 4.6 bits of entropy.


TrueCrypt External Multimedia Hard Drive

With TryeCrypt, the files are encrypted on the hard disk, so if an attacker formats the partitions and he use a recovery software, the files will still be encrypted. By the way, even if all your parition would be encrypted, an attack could still format your hard drive.

The attacker needs the key to decrypt your files. The key is kept in the RAM of the computer who is decrypting the files. You must protect your computer from deep freeze attacks and of course you need to protect your computer from key logger that would steel your key when you type it. Also, you need to put a long key so a brute force attack will fail to decrypt your files.


Prevention of netcutter use in the College LAN

Are you talking about the software that can be used in ARP spoofing? Sorry, I just did a quick search on Netcut and wanted to be certain. If not, then ignore the rest of this post.

If so, these type of issues can be resolved on a managed switch, but the net admin will need to perform the configuration. Do you have physical access to the switch? Wireshark can detect ARP issues, but you may need to be tapped into the correct location in order to see the responses. Or, start unplugging cables and wait until someone calls about the loss of network connectivity (I am joking about that point).

It may be hard as a non-admin to locate the person, but a properly configured switch can mitigate the issue and tossing Wireshark on a computer to detect duplicate IP addresses may need to be performed by the admin.


For how long ISPs keep record of Internet usage?

As one commenter already alluded to this is a pretty broad question. The broad reply is this: assume anything put on the internet is there forever. Different cities,states/provinces, countries, organizations, etc have various retention policies. It even varies from industry to industry. What kind of data stored can also change dramatically between all of these different groups.

Further, even if a site takes down data within a relatively short period there's no guarantee nothing isn't scraping it and storing it for later (4chan comes to mind as a prime example).

This goes a little deeper than your initial question but it's a part of the larger picture: a lot of things can leave a lot of historical evidence of your whereabouts.

Lastly, in regard to your question about if an ISP employee can monitor your activity - that's a pretty easy "yep!" unless you're taking certain steps to obfuscate your traffic. However, your destination IP address will likely be able to be easily mapped back to your account.


This is a great question.

The TLDR is; Yes, Call Centers are generally less secure than online payments. The reason for this is because of the inherent human factor in a call center - e.g. saving payment card details into notepad to process later because the payment service is down (seriously!!!).

But, there are a couple of things to address here, 1. Payment security and 2. Call security.

To start with 2. Calls are encrypted both on their way to the bank from your Telco's PBX, and again once they hit the banks DMZ, with a thing called an SBC (Session Border Controller). This has been standard since the proliferation of VoIP tech in the enterprise environment. That said, the quality of said encryption isn't great (Base64??) and relies on an assumption that both your telco and the banks telephony team are applying patches to their kit, and upgrading it when needed.

On 1, the payments / banking industry has been at the forefront of understanding the importance of getting this sh*t right for a long time because it is such a huge risk for them.

The standard for secure payments processes / infrastructure / architecture is called PCI DSS. PCI DSS was developed specifically to provide consumers like us better security when making payments. All call centers including banks, must adhere to its standards. This also applies for any other payment "endpoint" such as in store or online payments.

There are different levels of PCI compliance based on how many payments you are processing each year. Even the lowest requires 4 random audits to be conducted each year for an organisation to retain their compliance certificate.

In fact PCI DSS is almost an industry of its own these days, with companies building infrastructure and payment services to take organisations payment services "out of scope" of PCI DSS by owning all the risk.

To answer your question specifically, some of the key things outlined by PCI DSS are:

Never storing card data in plain text at rest - Tokenisation is used to overcome this.
Never storing card verification ID's like CVV or Pin - Never ever
Using the principle of least privilege

For access to network services
For access to payment GUI's (call center agents)
For access to call recordings for QA purposes

Ensuring transmission of cardholder data across public networks is encrypted - With standards like SSL / TLS
DTMF Masking - so that if you do punch in your card number from your keypad, all the beeps are monotone

I don't have enough rep to post more than 2 links, but for a better overview of what's required for telephone based payments, check out this blog post.

So, banks and call centers may store some of your payment card information at rest, as long as it is tokenised, and stored in a walled off PCI compliant network. Further, you will have basic encryption provided at the call being made, and again inside the banks telephony network, plus DTMF masking during any keypad payments.

In summary, with these standards and practices, you are more secure from a technology perspective when paying with an automated service than when you are talking to a human!

Sorry for the long post! :)


Why do I need to unlock my phone to enable wifi

When you enable WiFi your phone will broadcast all it's known SSIDs it has been connecting to. So let's assume one of the SSIDs you've been connected to is called "StackExchange" without an password and your running some highly sentensive application with are sharing information over none encrypted connection and you have automatically connnect ticked (which is done by default).

I would able to use AirCrack-NG to spoof an SSID "StackExchange" which would make your phone connect to my AP then I would able to sniff all your packets and then it would open your phone to attack.


How to allow only the public key owner to submit requests to my site? And what is this type of security called?

There's a little detail here on how Paypal issue Application IDs for issuing on servers which will host applications making API calls to PayPal on behalf of merchants/service providers - https://www.x.com/developers/paypal/documentation-tools/going-live-with-your-application#register

The approach you're taking above is similar so it's a way of providing client side authentication to the server gateway.

An alternate way to do this would be to issue certificates which you populate with details of the client you're issuing the certificates to. They would then install the certificates on their web servers so those certs would authenticate to your server-side cert.

The immediate issue with the above appears that if someone gets access to the public key your client stores in a script src tag, your client can be impersonated and be given an access token... As such, perhaps the authentication should be abstracted from the published, accessible code.


Does certificate pinning protect against Fiddler?

Per this answer, cert pinning can be bypassed on a rooted Android device or jailbroken iOS device.

I would go on to state that I think that your approach of trying to secure your application by adding client-side security is doomed to fail. While you can raise the bar of having your application examined via obfuscation and other tricks, as there's no physical security, you can't secure the client.

You need to make your API sufficiently strong to withstand attack from any client. The only alternative is to maintain physical control over the clients to ensure they are secured (rather awkward in a mobile app).


Is it dangerous to use hamachi for sharing game servers

I'm going out on a limb here and going to say you are talking about: http://en.wikipedia.org/wiki/Hamachi_(software)

Since its a publicly available VPN, connecting to a Hamachi network is a lot like connecting you your own LAN; except for the fact that EVERYONE on the Hamachi network you are connected to is unknown and can pose a very real threat to anyone on the network. Since you are essentially providing a door into your own network without some of the more external safety precautions, I wouldn't be surprised if there were some unscrupulous people taking advantage of it.

Be careful!


Authenticating to the API and then receiving a token is a far better approach. This ensures that the user is authenticated and the token is the representation of that authentication. You can use a framework like JWT to make such tokens.

Encrypting the User-ID is not a good idea. What this "authenticates" is that the request comes from the mobile App, which an attacker can reverse engineer to gain access to the keys. An attacker can then freely create "authentication tokens" for arbitrary user IDs.

In general, OAuth 2 may be a worthwhile thing to look into.


TL;DR Don't use Type 7 refrain from using Type 5 where possible and almost always try to use Type 8 (Unfortunately Type 8 in the world of Cisco isn't always available on all devices.1)

As stated by the users here, there are "two" (I use speech marks here because there are actually more, some only feature on newer versions of code and certain products and I will talk about those later) but the two password types that are common are Type 7 and Type 5.
As you've been told Type 7 is very easily cracked, in-fact with a quick Google search you can find a decrypter online as an example here is one I've used in the past. The point is, it's easy to reverse, there is no security behind it whatsoever so please don't ever use it (unless you're just running labs).
What you've not been told is why it's insecure - Type 7 uses the Vigenère cipher this cipher is now considered to be completely broken in-short this cipher uses

A series of interwoven Caesar ciphers based on the letters of a keyword.

What this essentially means is you take multiple Ceaser ciphers in sequence however you change the shift value each time. So where in a Ceaser you simply use a shift of three in a Vigenère cipher you shift with different values each time. A good website to see how Vigenère ciphers work is Crypto Corner.

So what about Type 5 is that more secure? Yes, it's more secure, Is it good? Well for storing passwords, not really. Type 5 uses MD5. MD5 isn't at all good for storing password see Is MD5 considered insecure? (I suggest reading both CodesInChaos's answer and Thomas Pornins answer below it) both answers are great and will tell you why you shouldn't store passwords in MD5. In essence, MD5 is fast, you can hash billions of passwords per second. Ciscos implementation of MD5 uses a Salt however as mentioned here by Tom Leek, in reality, using Salt in MD5 doesn't make any difference because of speed. So should you use Type 5 it honestly depends on your threat-model but I would advise against it where possible. As I mentioned earlier there are actually other types.
In newer versions of Cisco's IOS, there are now Type 8 and Type 9 passwords. These are much more secure.

Type 8 uses PBKDF2-SHA-256. PBKDF2 is good due to the fact that's it is designed to be slow where MD5 isn't. Type 8 is incredibly slow which can be a problem especially on a router, switch, etc this is because they don't use powerful CPUs, whilst a company like Cisco doesn't disclose specifically what CPUs they use it would be logical to say they're not extremely powerful for example in reality what a switch is doing isn't that intensive so they're not going to be using very powerful hardware. This becomes obvious when you generate an RSA key with 4096 bits on a Cisco switch. In general it seems that PBKDF2 appears to be the standard for password storing as mentioned by Tom here it also appears to be the NIST recommended for storing passwords so if you have the option I would recommend Type 8 it's going to be infinitely more secure than Type 7 and significantly more secure than Type 5 so if you have the ability then use it. Again this is all subjective to your Threat Model. In general, though I would say if you're using this on a customers network (customer being a client perhaps you sell networking solutions too) then where possible try to use Type 8.

Finally you have Type 9 Scrypt whilst I cannot evaluate the security of this that well Scrypt appears to be in general "more secure than Bcrypt" the issue with it, is that it's a lot more recent so that obviously means it has had a lot less time to be looked at by crypto experts. However, put simply Scrypt will be a lot more secure than Type 7 and Type 5 because it is again designed to be slow, which means computation time is a lot longer thus you'd like to think "more secure". Again a good resource for Scrypt is here.

To sum up, should you use Type 7 or Type 5? The answer is no. You should certainly not be using Type 7, it's awful. In regards to Type 5 don't use it either. Storing passwords with MD5 is not secure at all.
In a production environment please refrain entirely from using Type 7 refrain from using Type 5 where necessary/possible and almost certainly try to implement Type 8 or Type 9 considering PBKDF2 is the recommended from NIST as per this I would edge towards using that over Type 9.

One final thing I would like to mention is this - obviously this is only for local credentials (I would hope) if you're going to be installing production networks please use a RADIUS server of some sorts, this is much more secure (especially if you have a NOC where multiple engineers work).

1 - I realise I failed to mention Type 4 but if you're going to implement that on a network you shouldn't be working in I.T and you need to upgrade your devices in order to enjoy that they will no-longer support Type 4


Computer Forensics: what is in your toolbox?

The majority of my forensics work is done after the fact in a lab environment, so by the time I get involved on-line work is too late, i.e. no memory analysis.

Historically I would use

EnCase
Helix LiveCD
Argus

Recently I have started moving away from that combination and on to

Argus
Autopsy - For aquisition and system analysis
BackTrack (Forensics Mode)
sed/awk/grep/last, etc

In both cases acquisitions are performed using whichever write-blocker is appropriate, most of the ones I use are made by Tableau.  One reason I have moved to Autopsy is the support for hash databases, such as NSRL.  Another is that it is free.  EnCase is a great tool, but expensive.


You don't need anti-virus. Simply look at the contents of one of the drives. Are they empty? Fine, then you are ok. Pull random samples out and check them.

If you asked the vendor to put files on the drive, such as promotional materials for you company, then makes sure that the files match precisely.

Remember: do this from a machine with the latest patches. For example, you don't want to do this with a Windows machine with autorun enabled, or the virus will hop to your machine, infect it, then hide its files from you. A recent Mac or Linux machine will probably be safe.

Beware that USB drives can have multiple "partitions", one of which might appear as a CD-ROM drive. Check not just the one you expect, but these additional partitions as well.

All this assumes the device acts as a normal flash drive. Hackers can do something more nefarious, such as pretend to be a keyboard and inject keystrokes that log the hacker in. It's so unlikely that you don't have to worry about it, but if you do, then you'd have to hire an expert to test them.

Lastly, because of these security concerns, promotional USB drives are a very bad promotional items. Most Fortune 500 corporations and the military have rules dictating that such drives should be destroyed, and never plugged into a computer.


What OID Issuance Policies are appropriate for SmartCard and Browser Certificates?

What Microsoft calls "issuance policies" or "assurance" are known as Certificate Policies in X.509 (see section 4.2.1.4). A certificate policy is defined as such:

  In an end entity certificate, these policy information terms indicate
     the policy under which the certificate has been issued and the
     purposes for which the certificate may be used.  In a CA certificate,
     these policy information terms limit the set of policies for
     certification paths that include this certificate.

The whole idea of an OID is to uniquely and unambiguously identify an "object" (which can really be anything, including abstract concepts) in a worldwide naming hierarchy. As such, randomly generated OID totally defeat the purpose and cannot be condoned. In the case of certificate policies, the OID should "point" at a specific policy, i.e. a document which defines the conditions under which the certificate was issued and for what it may be used. You should obtain an OID subtree: any organization can obtain its own subtree from the IANA (it's free and permanent). Then you allocate the OID in that subtree in any way that you sees fit.

That being said, certificate policies make sense as part of the certificate validation process described in section 6 of RFC 5280 (see in particular step (a) of 6.1.2, (d), (e) and (f) of 6.1.3, and step (g) of 6.1.5). The validation process computes the set of certificate policies which are valid for the whole path, i.e. which appear in every certificate in the path. There are various subtleties, notably with regards to the special wildcard anyPolicy (that's 2.5.29.32.0, which Microsoft calls "All Issuance") and the policy mappings. However, if one of the CA certificates in the path does not have any Certificate Policies extension at all, then the vallid_policy_tree will be NULL, i.e. it all comes to naught. The certificate path will be validated "generically" but no specifically identified policy will come out of it.

The sad truth is that many CA use certificates in the way Microsoft promotes it, i.e. completely wrong with regards to what they were supposed to do; instead, they use certificate policies as a kind of fancy comment which software will consistently ignore (policies can be adjoined qualifiers, which can be plain text or a URL pointing to something which may or may not be a readable document).

Since certificate policies are so thoroughly misused, it is not useful to make the extension critical. In practice, you add the extension with a URL pointing to a 200+ page Certification Practice Statement as a PDF file, which at least demonstrates that you are serious about your CA business, to the point that you are willing to indulge in some heavy legalese. See RFC 3647 for guidance on writing a CPS.


Is it safe to visit any website in TOR when the Security Bar is set at Maximum? (Safest)

The "Safest" setting is in relation to the tor browser and it will only allow features that a static site would have.  Thus it will disable things such a javascript, and etc.
This will improve your security posture, (at a major cost of functionality) but is not a guarantee against compromise from websites or strategies to defeat tor's anonymity model.  The Tor browser and tor network are designed to complement each other so it is more secure than just using tor from a random browser.
There is not enough info in the question to indicate if you were compromised or not.
If you looking to increase your security posture, I recommend using Tails in A VM.


How do you use a public key to encrypt a string

There's a few different things here.

  a public key is the product of two large prime numbers

That is partially true for RSA, though RSA public keys also contain an additional integer (e, in the algorithm's description). Other public key algorithms, and even public key ciphers, do not work the same way (see ElGamal Encryption, for example.)

  as long as the private key is kept private, the owner knows something that the outside world does not

This is correct. Specifically, the critical element is that only the holder of the private key can perform operations (in practice, generally just "reversal") related to operations that can be performed with the public key, and the private key cannot be derived (in a remotely plausible amount of computation) from the public key.

  how, in simple terms does one take a string or number (like a proposed symmetric key for a session) and encrypt it with the public key

The Wikipedia link for RSA, given above, has a very nice step-by-step breakdown of the algorithm in use for both encryption and decryption, in math you can probably follow (the other algorithms arguably require more mathematical background).

  in such a way that the rest of the world with the public key cannot decrypt it (since they also have the public key)

Anybody can encrypt a given plaintext with a given public key, and produce a ciphertext that cannot be decrypted without the corresponding private key.

Two parties with the same plaintext and the same public key will, if they use the same padding (basically, a way to convert or short string or number into a number of the correct size for the cipher in question) and cipher, produce the same ciphertext; an adversary who knows that the plaintext was one of a limited number of values could potentially use this to identify which value it was, but for a key exchange (such as is used in OpenPGP, SSH, TLS, etc.) it'd be just as easy or easier to simply try each candidate symmetric key on the message (and its authentication code) until one of them matches. Symmetric encryption (and decryption) is way faster than public-key encryption. In practice, the attacker has no knowledge about the symmetric key beyond perhaps its length, and brute-forcing even a 128 bit key takes a quite impractically long time (terms like "lifetime of the sun" are sometimes used to describe such time spans).

  in such a way that the owner with the private key can?

Well, that's the whole point of public-key cryptosystems; two keys, and (at least) one of them can be used to do some operation but the complementary operation requires the other. For RSA in particular, the trick is to set up modular exponentiation (c = (m^e) mod(n)) such that it can be reversed only via modular exponentiation using a number d that is related to e and n (m = (c^d) mod(n)).

Specifically, d is the modular multiplicative inverse of e modulo Carmichael's totient function of n, and computing that requires knowing the prime factors of n, and since n is a really stupidly big number, factoring it is completely impractical (but simply finding any two stupidly big primes and multiplying them together is a lot easier, and then you already have the factors, so key generation is practical).

To use even smaller, more "toy-like" numbers than the example from Wikipedia:

  Choose p = 11 and q = 13 (these are distinct primes; they're also only four bits long so this is going to be a really weak key).
  n = 11 * 13 = 143 (eight bits long - that is, between 128 and and 255 inclusive - so yeah, really weak).
  Carmichael's totient of n is the least common multiple of p-1 and q-1; LCM(10, 12) = 60.
  Choose an e that is in the range 1 < e < 60 and is coprime (has no factors in common) with 60: e = 7 (2,3,4,5,6 are all factors of 60; 7 is prime so it's coprime with anything except its own multiples and 60 is not a multiple of 7).
  To compute d, we find the number such that 1 = (d * e) mod 60 (or in other words, d * e is one more than a multiple of 60); 301 is one more than a multiple of 60, and 43 * 7 = 301, so d = 43.
  So the public key is n = 143, e = 7
  The private key is n = 143, d = 43

  The ciphertext c is m^e mod(n). Anybody with the public key (which contains m and e) can compute this, for any given m. Let's say we want to encrypt the message "42" (we'll say m = 42). In our case, the math looks like this:

  42^7 = 230,539,333,248
  81 = 230539333248 mod(143), so c = 81.

  We (who have the public key but not the private key) send the number 81, along with the fact that it was encrypted with this particular public key. The recipient, holding the corresponding private key, decrypts the message using m = c^d mod(n):

  81^43 is a quite large number, approximately 1.161 * 10^82 (if you're following along at home, make sure you have a calculator that uses a good bignum library!)
  That giant number, modulo 143, is... 42!

So, we successfully decrypted the message, using our knowledge that d was 43. However, it'd be quite impractical to figure out what d is without knowing p and q. A TI-83 can probably tell you the prime factors of n = 143 in milliseconds, but a "real" RSA public key's modulus n is so large, it puts the value of 81^43 (which is 83 digits long in base 10, and takes 273 bits to represent!!) to shame. We're talking really big numbers here, like 7.5x that long. Good luck figuring out the prime factors of one of those!

If you want to know more about the general theory behind public-key cryptosystems, or want an explanation of how any particular one works, you might want to check out https://cryptography.stackexchange.com/.


Why we use GPG signatures for file verification instead of hash values?

When you check the hash value, you have to check it against a reference hash value: this does not solve the problem, just moves it around. You still have to make sure that you got the correct hash value. If the hash value is obtained through the same channel as the software package (i.e. you both got them from a HTTPS Web page), then you have gained nothing against attackers: if the attacker could alter the package, then he could also recompute the hash and alter the hash value you obtain so that you would not see any problem. Typically, someone who hijacks the download server itself.

Hash values "alone" are good at detecting random transmission errors (e.g. a router with bad RAM), not intentional alterations.

Digital signatures offer an enhanced service: they link the package to the individual who produced it, regardless of intermediate servers. With a GPG signature, you can download the package from a shady mirror site and still do not have to fear the package being bugged.

As for performance, know that signature verification will have the same cost as computing a hash, plus an extra mathematical operation which even an asthmatic PC should be able to do within a few milliseconds. I seriously doubt you could actually observe that extra cost.


Is any of my data shared with my budgeting app yet?

tl/dr: Passwords are like old food: when in doubt, throw them out.  If you're worried just change your password.

3rd Party Financial Services
First some background: the banking industry can, unfortunately, be a bit behind the times in this area.  As a general rule of thumb there isn't yet a great way (at least in the US) for 3rd party financial services (such as Emma) to easily integrate with banks.  I'm sure that some banks have well-secured API services for just these sorts of things, but many banks (especially smaller ones), just don't.
As a result it is unfortunately common for 3rd party financial services to access your account by asking for your actual online banking username and password.  It's a terrible idea, and it really shouldn't be done like that, but unfortunately it is.
One (of the many) reasons why it is so dangerous is because it teaches people to hand over their usernames and passwords.  When you have a service you integrate like this and then use it successfully for a while, it makes it seem less crazy when a scammer comes around and says, "I just need your username and password".  Anytime someone asks for your username and password to your online banking the default response should be exactly what you did - "NO WAY!  You're crazy!".  Unfortunately though, the fact that a service asked for your username/password doesn't actually mean that it is a scam, because in many cases that is the only way that legitimate 3rd party financial services can actually access your data.
Unfortunately telling the difference between "Legitimate and safe 3rd party service", "Legitimate but unsafe 3rd party service", and "Outright scam" can be very difficult or just impossible.  That leaves a lot of people in your boat.
Can you leave your account partially registered?
This is really up to you.  If you signed up with a strong password then you probably have very little to worry about.  Personally though I would reach out to their customer service and ask them to delete my account.  You may or may not have success.
Password in Username
Only Emma would be able to tell you the implications of accidentally sending your password in the email field.  Personally I wouldn't be too concerned.  It is possible that they log all details of all failed login attempts, and therefore there is a plain-text copy of your banking account password somewhere in their system.  From my own personal experience though I don't expect many companies do this, so the risk is likely low.  Either way an employee seeing that in the logs, fetching your bank account info, and trying to login to your bank account to do something malicious is probably also very unlikely.
Still, think of this as a risk/benefit analysis.  The risk of someone seeing your password and trying to log into your bank account is hard to predict but probably low.  However, the cost of changing your online banking password is probably also very low, and the benefit of doing so is that you no longer have to worry about whether or not someone will use your old password.  As a result, if you're worried, just change your online bank account password.


What are the security implications of allowing API consumer to decide primary key stored in database?

It depends.

Objects are Secret

If the data being uploaded with those GUID is considered secret, then you do not want users to share the same GUID. For that reason, you want to include another identifier in your primary key to make sure that each customer has its own set of GUIDs. In other words, as Conor mentioned in his comment, every user would be able to create an object with GUID 12345 and the customer has no clue that another customer also has a object with GUID 12345.

You can easily do that by adding the customer identifier to the GUID to identify the object(s) on a per customer basis.

Note that in this case you would also include a way to identify the user since the data is secret. Either a long UUID like string that was given to the user when they logged in or directly the credentials of the user (that one only works if only the costumer's server access your server since such credentials.)

Objects are Public

When objects are anyway public, there is no real security issue. However, it puts a burden on the client which is to generate a new GUID when an upload fails because of a clash.

Now, a GUID should be unique so the possibility of a clash is minimal. It probably would happen because a hacker is trying to find objects which said hacker should not otherwise know exists.

Since the data is public, though, having a hacker find it is not big deal. It's available to them one way or another...

Identifier

The idea of an identifier that gets incremented has been used a lot and it is still being used a lot.

If the data the identifier references is public, then it is not important to have a number incremented one by one like this.

However, something that should remain somewhat secret should not use such numbers. This is because a hacker can easily check for all the objects by using a URL such as:

http://example.com/user/1
http://example.com/user/2
http://example.com/user/3
   ...
http://example.com/user/n

Now we can see that the hacker can find all the users. If the user's account is public, he can check their name, with that name, they can attempt a login with some random password. So you do have a vector of attack which is simplified.

Create vs Modify

Yes. This mechanism is used by many systems, especially in the NoSQL world. For example, Cassandra let you use INSERT or UPDATE to create and/or modify content.

Cassandra has one column which is called the PRIMARY KEY (as in SQL, only it can not be more than one column). That PRIMARY KEY is used to index the data. This is the same as your GUID only can be absolutely anything, including binary data.


Probing Unsubscribe Link Vulnerabilities

Yes, unsubscribing customers unwillingly is a security finding. It's hard to say how much that finding is "worth." Have you joined or read up on bug crowd or other centralized bug hunting and bounty programs? This kind of thing tends to go better if you are part of a "syndicate" instead of disclosing alone.


How to secure delete inside a virtual machine?

No, absolutely not.

A virtual machine lacks the necessary knowledge and control over the underlying storage infrastructure to ensure secure deletion of data.

For any number of reasons, writes may be redirected to new blocks and thus leaving the old data intact on physical storage. This is a typical behavior for SSD devices due to wear leveling, for storage arrays and filers for reasons related to error correction and efficiency, and by any sort of snapshot functionality to support backup, cloning or data retention.

There may be exceptions in certain configurations where the hypervisor is able to facilitate deletion (by means such as an API that can be called from the guest), or where the VM has enough of a direct relation to physical storage (By means such as I/O paravirtualization or attaching an iSCSI device directly to the guest), but in general you should not depend upon any virtual machine to overwrite specific physical blocks.

Particularly in the case of a virtual machine in the cloud (Infrastructure as a Service aka Virtual Private Server) you can not expect to exert any influence on physical storage. On a poorly implemented service it's conceivable that blocks of  data can leak to neighbouring virtual machines.

Sensitive data should be protected with encryption at rest or perhaps stored on a trusted storage service that can provide the required level of security.

Much of this even applies to physical servers, you need to know the specifics of the storage components to ensure secure deletion - eg. release snapshots, recondition cells, destroy redundant block copies, rewrite parity information, clear out journals and transaction logs or commit write-back cache to disk - all depending on type of storage.


Can I use an encryption of a url as a password to use on that url?

Is this secure, even if someone were to find my code (or this question)? By secure, I mean, as secure as the master password itself.

Yes, this is as secure as your password if you choose your encryption method carefully. In fact, what you want isn't encryption; what you need is a hash function (such as sha256) which takes input and scrambles it to produce a fixed-length output:

hash = sha256(url)

Obviously that's not good enough because there's no master password involved, so you might try

website_password = sha256( password || url)

or

website_password = sha256( url ||  password)

However, even though that might look perfectly fine, don't do it like that!. It's not secure.

What you should do is use a pre-existing primitive, HMAC, which guards against some weaknesses of the above two examples:

website_password = hmac(password, url)

This should be secure (the security depending on the quality of your password and the strength of the hash function used in hmac (you have some room for decisions there - hmac defines a protocol, but gives you a choice in hash primitive).

Still, rockStars's question is valid: Why not just use a password manager and decouple your master password from the site passwords? Because if someone guesses your master password, all your site passwords are immediately known.


Must an encrypted hash value be bigger than the password it was generated from?

First things first: this is NOT encryption. This is hashing. If your book talks of "encrypted hash" then that book is confused, and thus confusing. Notably, hashed passwords are never "decrypted", since they are not encrypted in the first place.

A cryptographic hash function offers a fixed output size. In the case of passwords, one needs to do something specific called "password-hashing", which has its own theory (see this answer for details). However, the main principle is still there: when verifying an incoming password, the password is hashed into a value x, and that x is compared to the value that was stored. If the password is the right one, then the same x is obtained. However, if a wrong password was entered, another value x' is obtained, which is distinct from x with high probability.

This is the important point here: an attacker could still get (very) lucky and instead of sending the right password, he could theoretically stumble on another, distinct password that, by pure chance, would yield the same hash value.

Of course, we do not want such a thing to happen, and the best way to make that event utterly improbable is to make these values x (i.e. output of the hash function) large enough for bad luck not to occur in practice. Existing hash functions have an output size which is typically 16 bytes (128 bits) or more. This also applies to password hashing functions; e.g. bcrypt outputs 192 bytes.

(Compounding the effect is that hash outputs are binary, but often encoded in Base64 before storage in database, which increases the size; also, password hashing functions need some extra parameters, e.g. a salt, which, in some functions, are also encoded in the output, further expanding the output.)

User-chosen passwords rarely exceed a dozen characters in length, so, generally speaking, the hash output will be larger. However, hash functions can use large inputs, so there is no intrinsic reason why hash outputs should always be larger than passwords. It just happens that we need, to thwart the "lucky attacker" described above, an output size which is "large enough", and that "large enough" is larger than the average size of passwords chosen by human users.


Is it safer to download a file from the internet and open it versus opening a DVD?

Information security policies in corporations and other businesses are strict when it comes to removable media. There is the risk of abuse from someone copying malicious data to and from the removable media, both knowingly and unknowingly, the same risks will also apply with Internet media, let's take a look at the Pros and Cons of both Network Level Traffic Filtering and Local Scanning.

Pros/Cons of Network Level Traffic Filtering:

One index of virus definitions to keep updated
Scanning is in real time
All clients on the network are protected, not just the ones that the virus definitions index is updated on.
The benefits won't extend to scanning USBs, DVDs, etc

Pros/Cons of Local Scanning:

One index of virus definitions per device to keep updated, whileas this can be mostly automated, there are various risks including tampering, a device might not have the latest update downloaded yet, etc so there are potential problems with operating this at scale so this shouldn't be the first line of defense on large networks.
The benefits are extended to scanning USBs, DVDs, etc making sure that all media is scanned against the index.
Only clients with the scanning installed are safe.

It's safe to say that while both formats of media have their own sets of risks, and while each form of filtering/scanning has it's own pros and cons, the filtering of network traffic can be centralized while removable media cannot be easily centralized. So to summarize getting a file from the Internet isn't really safer, but from the network administration perspective, it's a lot easier for them to manage and I understand why such a policy is in place.


Web & insecure HTTP - Using RSA for encrypting passwords on the client side

Firstly, I'm assuming that you're doing this to weaken man in the middle attacks (which really are the only problem when it comes to plaintext passwords over insecure HTTP)

Client side hashing has little to no benefit. An attacker, on picking up the hash will not need to brute force the hash. All your server needs is the hash, so the attacker can simply craft a POST request with the hash in it and send it over. One doesn't need the plaintext to get in to the system.

Regarding your solution:

If you're using the same public key for all clients, then the situation is effectively the same. As an attacker all I need to sniff is the ciphertext you send over, and I can impersonate you by sending the same ciphertext.

What if you gave different public keys to each client on each login? Then I could launch a man in the middle attack where I swap the server's public key with my own, decrypt the ciphertext you send (this getting your plaintext, even better), and encrypt it with the server's public key.

There has got to be a way for the client to know which public key is correct. For that you'd need some kind of trust system. Where clients know which public keys correspond to which server. But that will lead to millions of public keys being stored in browsers. So you'd need some sort of certificate chaining system. And I think you realize where I'm going with this ;-)

TL;DR: Use HTTPS, client side encryption without a trust system is not any more secure than no encryption at all.

If you're worried about shared passwords on other sites being detected after breaking the hash, then both hashing and public key encryption are fine (public key encryption is better due to rainbow tables). Note that these will only foil the plans of a passive attacker. If the attacker mounts an active MITM attack, then they can change the JS code that you send and remove the encryption bits entirely.


Why are attacks pointed to 'Null island' in tools like Norsecorp?

Those tools use GeoIP databases that map IP addresses to approximate locations to display location data as here is no physical way to tell where data is actually flowing (and there's no guaranteed those DBs are true nor up to date).

Sometimes those databases don't know about a particular IP and return 0,0, which is what you see here.


Can autoplay USB stick spread virus to windows 8 or 10?

The difference in modern version of Windows is that Autoplay is off by default, but it is still available and can be enabled. However, if you do not know the current Autoplay configuration of a Windows machine, you should check it before inserting a suspect stick.


How can TOCTTOU vulnerabilities within the Windows OS be mitigated?

Without actually answering the declared question, I want to address your given example - because I think you're actually just trying to solve that issue, and not the generic issue.

Once you grant administrative privileges to a user - it's done with, you aint never getting them away again.
As you say, the user can just add himself back into the Administrators group...  But there are actually many, many other ways he can do ensure that he keeps his privileges, while he still has the privilege, such that you would be hard pressed to remove it, even if you happened to have full and complete system auditing turned on.

For example, he can create another user, and add that to Administrators.
Or reset the password on Administrator, and enable that. (Since you don't use it, right??, you'd never know...)
Or create another group, make it hidden, and add that as a member of Administrators.
Or, simply setup some Windows Service, or MSTask etc, running as LOCALSYSTEM.
Or install some kinda rootkit.

Of course the system auditing won't really help, since and Admin can easily shut that off, temporarily...

I could go on, but I hope I already proved my point... TOC-TOU is not your problem here, it's granting temporary administrative privileges (not really possible), or maybe dealing with malicious administrators (Really Hard Problem) in general.

As you said, don't grant Administrator privileges to end users. There are other solutions to enable them to install programs.


I'm currently working on this as well, I'm not an expert but I think you have to understand the Windows objects part as well, I couldn't find RPC Control till I read about it, you can use the Sysinternals tool WinObj this will show you a bit more.

I was able to use create mount point between two folders but not to an object, there is more details here https://offsec.provadys.com/intro-to-file-operation-abuse-on-Windows.html


Likely Sources of MITM Attack over Public Internet SSH

I have no idea about sources of attacks, so strictly speaking, this won't answer your question. However, I think there are some things you can do to figure out who or what may be engaged in this. It will require extreme care on your part. Also, it's been a few days, so first you need to see if it's still happening.

You should set up your server to determine who's doing this (by IP). Turn on logging on the server and your firewall was my first thought. See if someone is knocking on your front door and testing SSH credentials. Note the times in the logs. If it isn't you, examine the logs for IP addresses of the attacker(s).

You can do a lot with an IP address. Reverse lookup won't tell you everything, but it will tell you a lot. Is the address a cable modem, a US government address or an endpoint in China or Bulgaria? Perhaps, it terminates inside Comcast? Then, you can call up Comcast and ask them, WTF?

No matter what, DO NOT SCAN OR ATTACK THAT IP. You have no idea who or what you're dealing with. You're almost certainly ill equipped to handle whomever is on the other side of this thing if it's any kind of sophisticated attacker. You don't want the Eye of Sauron upon you.

However, you don't know if the attacker has reached your server, yet, or if the logs are showing some random scanning of your ssh port, although you should be able to figure this out. So, if you feel like continuing, jump to your client computer.

Look over your entire client and server set up, the credentials used to authenticate the server, the usr/pwd and other secrets used to authenticate the client. Keep a copy of all of this information, or just note it all and be prepared to change it later. Make a copy of your client's known_hosts file.

Test running an IP snooping program on your client, something like wireshark. Become familiar with how it works and make sure you can capture the ssh/tcp/ip session with the attacker/server. As it will be over SSH, you won't see the content. However, (just like NSA meta data collection) you will know the remote IP address. You might be able to know that without wire shark because the IP should appear in your client's ARP database (arp -a). However, wire shark will give a little bit more information (and it's cool to watch the packet exchange). Also, compare IPs from your server logs with IPs from your client. Are there matches? Are they related?

You've gone pretty far and collected a lot of data. You've logged at your server (and may have seen the MITM IP), you've passively set up an SSH session from the client, you can see the offending host (MITM), you have knowledge of the IP, perhaps that's far enough.

If you feel like digging deeper, you can. However, this one becomes a bit more dangerous for your home network. You need to be very confident about your ability to protect that network from the inside. Honestly, I'm not sure you should take this step, but here's how far you can go.

You could set up what amounts to a honeypot. Replace your machine on the backend with another old machine. I'm not sure if your backend needs to be live 24x7, so this may not be possible. If you can, just disconnect your backend network and leave only the honeypot in place. If you have a real router, isolate the honeypot so all incoming connections are to it. Harden it as best you can. Set up a dummy account with very different username/password and whatever other secrets you need. Set up some dummy information, maybe even load a web server on there and a mysql database. Something that looks vaguely real. Also, the best honeypot is actually running a VM, where you've virtualized the honeypot running on top of the real hardware. It can be harder to break out of a VM and do damage.

Turn on logging on the honeypot on everything. Log incoming connections, log shell session histories, log everything you can. Run wire shark on the real computer underneath the VM honeypot. Then, perform the whole shebang. Connect from the client via ssh (run wireshark), use your honeypot credentials and complete the SSH login. Are you on your honeypot or on some foreign machine? Then, go home and check your honeypot logs. Did someone connect in? Can you leave the pot around for a few days? It might take a little while.

This last bit doesn't get you a whole lot more information, but you will know two things if you see someone log in. (1) You are definitely dealing with an active attacker and (2) you have the IP of the machine used to engage in the attack.

At that point, I'd hand things off to the authorities. It's a tough call who to go to. If you get this far and can't find anyone who will listen to you, PM me and I might be able to help get you to someone (casual acquaintance type of thing).

Lastly, throw away the honeypot. Smash it, destroy it, never use it again. That thing cannot be trusted, they might have dug into its BIOS. Never again plug it into a network you care about. Change every single password you have on everything. Modem, router, machines, accounts. Consider re-imaging and/or re-installing firmware on any device used in the honeypot scenario. Get that firmware/image before you start the honeypot project and keep it well secured.  In fact, use an old modem for the honeypot project and just disconnect everything else and smash that modem, too, when you're done. If I were you, I would be completely paranoid when running the honeypot scenario.

I hope this helps.


If certificate its the same, WPA-PSK without EAP uses key and not certificate. Shoud run without problems.. mechanism are both same but difference in certificate and user and password added for more security. WPA-PSK are Encryption method and EAP add just user and password to. In other words.. EAP its designed for a Corporative Networks that require much security.


The cold boot attack can be limited by setting an EFI password, so that the attacker can't get to the memory during the limited time window following a reset. Notice that if the firmware password is set, the FireWire device driver disallows DMA requests which is another very similar (and IMO more likely) attack.

The key place where the password should be considered "at risk" from any direct memory access attack including cold boot is not in securityd, which does a pretty good job (all of the relevant code is open source so check for yourself), it's in the client application. It's the client application that wants the password, and the vendor may not have been careful about zeroing the memory out (particularly if the password is put into an autoreleased or garbage-collected NSString instance).

(I wrote a whole chapter on Keychain security in Professional Cocoa Application Security)


Is it safe to use jku, kid and x5u in JSON Web Signature (JWS) header?

These fields are here to allow the component verifying the ticket to identify the key used for the signature.

jku is an URI that reference the public key used for generating the signature. It must follow RFC7517 format. The entity verifying the token is responsible for checking whether that signing key can be trusted or not.
kid is the key identification and it's only valid in the context of a given audience: the context of your application must define how to use that parameter to identify the key. It can be the fingerpring of the x509 cert user for signing, it can be the certificat serial number, it can be a reference to a row in a table, it can be the ID of a HMAC secret stored into a JSON file, or the XPath inside a XML document, whatever is defined by the signing party.
x5u must contain an URL to the x509 certificate that was used for signing the token. That certificate must be in PEM format.

Typically, you will only have one of these parameters in any given token (there can only be one signing key, after all) although it isn't impossible to have the same key accessible through different methods (this mostly means that it's not impossible to have both a jku and a x5u header that point to the same key but you should try to avoid that kind of ambiguity).

By definition, if someone changes the headers and signs the ticket again, the result is not the same token so you don't need to worry about that: you can safely reject any token that you can't properly validate.


SSD enrcyption with ATA password - AHCI mode?

The disk lock is a built-in security feature in the disk. It is part
of the ATA specification, and thus not specific to any brand or
device. The disk lock can be enabled and disabled by sending special
ATA commands to the drive. If a disk is locked, it will refuse all
access until it is unlocked.
Source

Based on that I believe that it is not part of the AHCI/SATA standard, however as other comments have suggested, Full disk encryption using software like true-crypt is recommended.
Furthermore:

While the ATA disk lock is intended to be impossible to defeat without
a valid password, there are workarounds to unlock a drive. Many data
recovery companies offer unlocking services,[25] so while the disk
lock will deter a casual attacker, it is not secure against a
qualified adversary.
The drive is simply 'locked' whereas TrueCrypt actually encrypts the data on the drive.

In addition, You should be aware that ATA mode has noticeable performance loss over AHCI. There are a number of comparisons available online between the performance benchmarks of the two. It might be that any performance impact on your system from FDE may be negated by using AHCI mode. You will need to test for your own system.
Hope that helps,


Is PCI DSS applicable to other solutions than those dealing with payment cards?

Some of the PCI DSS requirements may apply to your situation (in fact, it's highly likely that some of them will). However, your application will have requirements that are specific to its problem domain, and that PCI does not address: similarly, PCI will make some requirements that are irrelevant (or even counterproductive) in your domain because they are specific to the domain of the payment card industry. Remember that standards, industry practices and checklists are a useful starting point for any endeavour, but that at some time you're going to have to solve your problem.

So in answer to your question about credit: if you're selling a livestock management application as PCI compliant, I would consider myself warned that you thought cows and credit cards were the same thing in creating your security model.


Need some clarification regards end-to-end encryption process

There are many ways that private key can be stored by the client in a web-based end-to-end encryption application.
One way is not to store the key it at all, but instead, derive the key from a password.  The user enters a password, then the private key is derived from the password using a key derivation function, such as PBKDF2.
Another way is to use the Web Crypto API to store the private key in a CryptoKey object, then store the CryptoKey object in the web browser's indexDB storage.  See https://crypto.stackexchange.com/questions/35530/where-and-how-to-store-private-keys-in-web-applications-for-private-messaging-wi/52488#52488 for more info on this method.
Another way of storing the private key is the way that ProtonMail does it.  The private key is encrypted using another key derived from a password, then the encrypted private key is stored on their server.  See https://protonmail.com/support/knowledge-base/how-is-the-private-key-stored/ for more info.
Yet another way of storing a private key is the way that EncryptedSend does it (full disclosure, I am the developer of EncryptedSend).  The private key is encrypted using another key derived from a password, then this encrypted blob is written to a file that the user stores on his/her system.  To begin a session, the user simply provides this file and the password, then the private key is used both to decrypt messages and authenticate the user with the server.


Is setting a firmware password on a Macbook enough to prevent cold boot attacks?

From wikipedia

  Alternatively, the memory modules are removed from the original system and quickly placed in a compatible machine under the attacker's control, which is then booted to access the memory.

This means that your computer is still vulnerable to cold boot attack.

Furthermore from wikipedia

  This is not the only attack that allows encryption keys to be read from memory - for example, a DMA attack allows physical memory to be accessed via a 1394 DMA channel.


Secure Client-Initiated Renegotiation - DoS DANGER

how can I mitigate and protect against such vulnerability warning

Well, generally speaking, everybody knows that defending against DoS attacks -whatever their nature is- is a difficult and expensive thing to achieve. Coming back to your essential problem, it happens when an attacker overwhelms  your server with secure connection requests leading it to consume more CPU resources. This problem is called TLS renegotiation MITM and was first discovered on 2009 exploiting a flaw in the TLS v.1/SSL v.3 stack layers before RFC 5746 and its implementations appeared. Before that, several patches were applied more or less genuinely.

So right now, I suppose your OpenSSL version is outdate. You can update it to at least to OpenSSL version 0.9.8m release or newer (but      OpenSSL versions 1.0.1 through 1.0.1f and     OpenSSL 1.0.2-beta are affected by the HeartBleed problem).

Whether you are using Apache (recent versions), IIS or any other product that supports the client-initiated renegotiation feature, please disable it (it is often their by default).

If you know to know more about how this vulnerability, please refer to this: SSL / TLS Renegotiation Handshakes MiTM Plaintext Data Injection- medium or low risk?. Also, may be you are interested in reading about the first tool developed for this type of DoS attack.


Strange spam to my IG and email with my secret information

I am not exactly sure if any one of the following is the case or not but I will try to suggest you many possible cases:

Your Gmail account :
One might find it amusing how much user data Google services log and use for providing various features. Try to remember if you had ever forgotten to log out from your gmail account when you had used it on a device not exactly yours or less trustworthy. If so you should immediately go to Google account security tab and check your logins and log yourself out of all the unknown sessions.

Your mobile phone :
Attackers or those who use smart tools such as metasploit etc. can create a payload app and use some social engineering skills to install it on target device. These apps are surprisingly strong enough to track your geographic locations and other such critical details. You should check your oppo phone's installed apps and find out those apps which are suspicious and uninstall them after finding details. Do not think that there are only those apps which are visible in the menu of your phone.

Social media check-ins :
Now this might sound funny but there are people who are so obsessed with instantly updating their statuses and check-ins on social media such as Facebook ,Instagram, etc. Make sure you are not one of them and remove unknown people from your friend list, maybe the one who is attacking you is one of them.
A close person to you :
Don't just deny this entirely based on your affection for your close people. Many a times there are people who do this just to scare you out and with no serious bad intention like a prank or some sort of that stuff. Make sure this is not the case with you.
Further reading 1
Further reading 2
Further reading 3


How to encrypt and authenticate large amounts of data with NaCl

The NaCl API is designed to work on an entire message at a time for a reason: The largest message you are willing to handle is the largest amount of memory that an attacker can waste in a denial of service attack on the receiver of the message.  You probably want to limit this to something small like a single IP packet, or a single megabyte, or similar.

You should break your data up into smaller pieces, and authenticate them in order, e.g. with the piece sequence number or byte offset figured into the nonce or associated data.  The overhead of an authentication tag is a mere 16 bytes, which is trifling in comparison to a megabyte of data.

Although this means you can confidently act on each piece of data in your pile as soon as you have verified it, doing so also means that you have to be able to handle truncation of the data partway through.  (But it's better to merely have to deal with truncation than to be tempted to operate on unauthenticated data, which is pure evil—don't touch it!)

There are some existing generic systems for authenticated encryption of streams, like miscreant.


Private Tor networks: what are the benefits, and how would it be accomplished?

The anonymity provided by Tor stems for the large number of cooperating nodes; a "private Tor network" looks like ultimate counterproductivity. Wait, no, a private Tor with peer authentication is even better in that role: anonymity is so much more guaranteed when you make sure of who you are talking to.

Nevertheless, Tor is free software so you could download the source code, compile it, and start from that point.


What is the difference between EV-SSL certificates and Normal SSL certificates?

The first example is a normal SSL certificate meaning that it's a valid certificate issued by a trusted Certificate Authority, but there was no extended validation of the owner of the domain/site. This could mean that the certificate claims to be from Foo Inc. but the CA did not check that the person/entity applying for the certificate was indeed Foo Inc. when they issued the certificate.

The second example is that of a Extended Validation SSL Certificate. This type of certificate does extended validation in that the CA verifies the physical address and other details of Foo Inc. before issuing the certificate. In the end this just serves to give more assurance to the end user that the owner of the site/domain is indeed the company Foo Inc.

You can read more here: How is EV-SSL different from SSL?


Passwords are hashed for the case that an attacker can read the hashes from the database (e.g. SQL-injection). Afterwards he can brute-force with the full speed of his own environment, often with a GPU, this is called an offline attack.

A sleep on the other hand could only protect from online attacks, even then an attacker could make multiple requests and wait for the results which are a bit delayed but are not slower.


How are hackers able to plant Phishing URLs in existing websites?

You honestly could have a wide array of possibilities and answers depending on how something would be 'compromised.' When you think about it, if StackExchange wasn't monitoring for active hyperlinks and tracing it to things like reputation sources at virustotal, proofpoint, etc. Then you could easily just comment/post phishing URL's in any public forums for comment. If you're referring to more of a compromise sort of things there's a few things to think about:

If the site has input capabilities; then vulnerable injection vectors such as persistent XSS can have layered scripts inserted that have phishing links or other click fraud and related malicious objects
There's also direct compromise-- manipulating the content displayed on the webpage. Common vulnerabilities and exploits exist in CMS's like wordpress.
There's also possibilities where an advertising network or CDN is compromised and attackers can have phishing related clickable links or ads served (even exploits).

As far as detection, you need active content scraping and analysis possibly including the following protection mechanisms:

Static pages -- integrity checking
Have a crawler or bot continuously check the ads or dynamic content served for malicious scripts or URL's
Have your reverse proxy or WAF detect returned content to the user for possible injected or unauthorized content
Ensure that whatever combination of LAYERED detection and protection mechanisms you have can deobfuscate basic encodings like Base64, HTML, etc.


What to do in response to a source code and/or database leak by a third party hosting provider?

There is very little information in your question, so it is difficult to give a concrete answer.

Before your blame the hosting company or even sue them, you should review your own program code, including all libraries and web applications you have installed.

You should especially look for SQL injection, shell code injection, various ways of remote code execution. A common vulnerability in old versions of many common PHP applications is the writing of files with configuration settings or user uploaded files that can be executed as .php files by visiting the appropriate url in the webbrowser.

The OWASP Top 10 and especially the PHP Top 5 of the Open Web Application Security Project are a good starting point.

Furthermore check that the php files are not world readable on the server.

There are two things you could test on your hosting provider. But depending on the legislation, you are in, this may not be a good idea:

Can you look into other peoples folder by going up in the directory tree in the ftp/sftp/ftps/scp program?
Can your PHP programs read files of other people?


How can I confirm that my server is protected against HeartBleed?

I was able to download this tool and put it on one of my systems so that I could test my hosts without an external checker:

heartbleeder

The results were consistent with what I expected (dirty to clean after patching, and the one time it didn't clean up after patching, further investigation showed the tool was right and I hadn't patched every copy of the openssl library).

And by the way, what you're describing is incredibly common.  Many distributions (RHEL in particular) backport patches without changing the old rev.  Red Hat actually takes the cake for this one - openssl-1.0.1e-16.el6_5.4 is the bad old RPM, and openssl-1.0.1e-16.el6_5.7 is the fixed new RPM.  Really, Red Hat?  You couldn't have nudged -16 up to -17?

Update:

In answer to @question-overflow's comment, here's an excellent dissection of the issue including walkthrough of the code and links to full source.


Can my computer get hacked if I use a local server for development only? For example WAMP?

Yes, it is possible as long as you are connected to the internet, check your network configuration that could possibly expose the machine you're using which has WAMP installed.

Let's say for example your router is configured to port forward all ports to the IP of your machine and you also have a vulnerable version of WordPress installed inside your WAMP, the attacker can use that to run code on your machine and install anything on it.


Is the law the only thing stopping many sites from being hacked/cracked?

From a purely objective view, I don't think there is any evidence showing that cyberlaws are having a large impact on computers not being cracked.  It's too easy to avoid prosecution (jurisdiction) and it's too easy to automate mass cracking.

On a more subjective view, I think the cyberlaws do keep the highly skilled security professionals honest, because the risk isn't worth it compared to their careers.  You could argue that the laws are limiting the pool of people that might launch sophisticated attacks, making it easier put enough defense in place to stop the most likely attacker.


Wiping data properly in LUKS encrypted drive

In the modern day, I would recommend logical wiping to a consistent value and verifying, even for an encrypted disk with the key stored only in one place.  Given the possibility of bad blocks being silently recovered on a spinning HD, SSDs scheduling data for delete later on, it just seems safer.

In contrast, I'd say that for an un-encrypted disk you should assume that even with multiple logical overwrites that there could be some bits leaking.

If the standard you are looking for is: "provably recoverable is unacceptable," then erasing the only places the key is stored seems fine.  If the standard is "probably recoverable is unacceptable," then you're still probably fine with your described plan (my personal judgment).  If your standard is "possibly recoverable is unacceptable," then go the extra mile.


Active Directory password complexity based onto entropy

Yes. You would need to create a custom Password Filter, but it's not a point and click function. See this Microsoft article on how to do so: Custom Password Filter

There are also a number of third party password filters available that may make it easier for you (e.g. NFront, SpecOps, etc.)


Your understanding of how asymmetric cryptography works is somewhat flawed.  In general the public key is NOT used to decrypt anything.  It is used to encrypt.  The private key is used to decrypt.

There are several mechanisms to get secret communication going starting with a public/private key pair held by the server.  For the most part they involve the client and server exchanging messages to establish a shared symmetric key which both use for subsequent communication.

In the simplest, but somewhat disfavoured, method the client picks the symmetric session key, encrypts it with the server's public key and sends it to the server.  Since the session key is encrypted with the server's public key any observer won't be able to determine what it is.

More complex methods of establishing the session key include Diffie-Helman Key Exchange and Elliptic-Curve Diffie-Helman key exchange.  These avoid sending any key over the network and preserve secrecy in the event of a future compromise of the server's key but involve some maths to allow both server and client to derive the same key.

In no case is the private part of a public-key pair ever sent over the network.


Unfortunately the previous answers given to this question, are not only wrong, but also quite dangerous.

While it is certainly true that digital signatures usually involve hash functions, which by its nature are inherently deterministic, you should note that digital signatures are more than just a simple hash. They involve public key cryptography, which is used in a way that guarantees only the legitimate owner of a private key is able to sign something. There are quite a few digital signature algorithms, with the following being used widely in practice:

RSA
DSA and its elliptic curve equivalent ECDSA
ElGamal

At least DSA, ECDSA and ElGamal do absolutely require random numbers by design. Reusing a random number, can lead to the recovery of the private key. This is trivially easy and can be understood by anyone interested in the topic with only a few very basic equations.

There have been all sorts of attacks in the past exploting this very fact. Probably the most prevalent example is the hack of the PlayStation 3, which brought us the following xkcd comic:

With RSA on the other hand it is not that easy. "Schoolbook" RSA does not require random numbers. However it is possible for an attacker to perform existential forgery attacks on simple RSA implementations. Therefore in practice modified schemes are used, which might operate in a probabilistic way. The basic idea is that valid signatures have to satisfy a certain form. One such standard is called Probabilistic Signature Protocol (PSS).

GPG has all of the above schemes implemented. By now RSA seems to be the default on most systems. RFC 4880 states that OpenPGP makes use of EMSA-PKCS1-v1_5, which is a deterministic padding scheme and does indeed not require random numbers.

So, in essence: Yes, digital signatures do require random numbers and it might be a bad idea to use virtual machines for such tasks. At least it is something to consciously think about.


How do you send a 64 bit meterpreter stager?

Just use a 64 bit Meterpreter payload.
For example the windows/x64/meterpreter/reverse_tcp payload.
You can get a 64 bit shell from a 32 bit shell by using the payload_inject module built-in to Metasploit. You can do this by running the following commands after you already have a 32 bit Meterpreter shell: use windows/local/payload_inject  set payload windows/x64/meterpreter/reverse_tcp. Then setting the other parameters (SESSION, LHOST, LPORT) to yours. Then you get a 64 bit Meterpreter shell!


(Disclaimer: I am not an authority on OpenVZ. This answer is more opinionated than my answers usually are, so feel free to criticise!)

OpenVZ might be "more" secure in that it does not integrate with the entire kernel, so that its attack surface is a bit lower. Though, essentially OpenVZ is what served as inspiration for namespaces and hence ultimately, LXC and Docker. I don't believe it's going to be continued for long now that those more complete solutions are, well, complete.

As pointed out by WhiteWinterWolf one of the big differences is that LXC finally gets to use the user namespace, opening the ability of unprivileged users to run containers and ensuring that contained code that breaks out of the container retains unprivileged users' privileges. Also, namespace-based containers may eventually be fully SELinux-labelled. Docker containers normally already are, and Dan Walsh is working on a way to make SELinux automatically enforce an extra layer of isolation between containers by using randomly generated categories for contained processes.

So in summary, containers are better because:
- They can partially thwart some container breakouts (limiting them to an unprivileged UID), making privilege escalations inside the container irrelevant.
- They are more supported and more actively developed, and in particular they'll greatly benefit from SELinux support.

And they are worse because:
- Their TCB is very large, across the entire kernel and bugs will occur every now and then leading to exploits and breakouts.
- The user namespace feels to me to be kind of an edge case. You usually achieve privilege escalation via a bug in the SCI (which you would be able to reproduce after your breakout) or confused deputy attacks on a privileged service (which are likely to keep existing outside your container in the first place). So you would still need to tightly limit that container-running UID to running containers.

In summary, keep practising defence in depth, and keep thinking about how you let contained processes interact with the outside world and how you run containers. Differences exist but as you can see are rather minimal.


Hashing and signing partial data in payload

A cryptographic signature can only assert trust on the data it is signing. Unless there's a way to validate the validity of the unsigned fields based on the validity of the signed fields, then no you can't trust the unsigned fields.


The credentials go to the server requesting them, in this case, the server serving the image. (attacker.com in your example.)

This is called a 401 phishing attack, and while rare, I have seen it in the wild so it is something that you need to consider if you're going to allow images to be loaded from arbitrary domains.


Let's Encrypt is based in the US and subject to US laws

Good questions all. I can't speak too much to other things they could do, but here's some comment on the ones your brought up:

Yes, they could revoke a certificate. But while this could cause some availability issues for your users, it wouldn't compromise confidentiality or integrity.
Let's Encrypt could issue a counterfeit certificate, but that's why all certificates are reported in the Certificate Transparency log. If you're concerned about this, you could watch for certificates being issued with your domain name that were never in used on your servers.
Again, this is the benefit of Certificate Transparency. Users could cross-check against the CT logs to ensure that any given certificate is valid. This will be slightly less effective than watching for a certificate on your domain, but in theory a rogue certificate could still be identified.

In terms of its impact on Confidentiality and Integrity, I'd be most concerned about a supply-chain attack on the tools that you use the request a Let's Encrypt certificate. The default tool - certbot - requires a great deal of access, because it's also designed to install the certificates in a variety of web servers, and the designers felt that if you are issuing certificates you should be root anyway. Fortunately, the tool is open source with over 300 direct contributors, so slipping something into the tooling would be less likely than say... slipping something into one of the libraries you use for your web application.


Is it safe to use Diffie-Hellman public keys as nonces to protect against replay attacks?

A nonce is a "number used once".

This is question is asking "should I use a the same value for my nonce each time". The answer is no.

Start with a number which is not predictable, e.g. from a good random source.

Edit 2: You gave the answer yourself. The nonce need not be kept secret. But the DH shared key must be. If you use the key for the nonce you will then need to keep the nonce secret...

Edit: I think what we have here is that nobody has ever considered the question, in the same way as nobody has ever asked "is it safe to clean my teeth with the polishing bit on a dremel". Spending any time thinking about the question is a waste of time.

To clean your teeth, use a toothbrush.
For a nonce, use a good random source.

Then get on with the next job.

Or, to be slightly less snarky, you need to ensure the number is only used once. A good random source achieves that statistically. Using e.g. the time remote IP achieves that physically. Neither of those uses information which must be kept secret.


Simplest solution to addressing SSL certificates on internal applications

You're on the right track.  Since you mentioned GPO, it sounds like you have a Microsoft Active Directory.  Therefore, the easiest would be to leverage Microsoft Active Directory Certificate Services (ADCS).

Definitely want an offline root CA if you're supporting an enterprise environment.  This typically means deploying a two tier architecture.  Meaning there'll still be the offline Root CA but another server will be configured as the Issuing CA and will remain online.  There's a great tutorial for setting up a two tier architecture here.

FWIW, ADCS is fairly easy to setup and deploy.  The difficult part is fully understanding all the moving parts so it can be properly configured for your network.  Such items include how often the revocation lists are updated and setting up the appropriate level of overlap, where will the revocation lists and certificates get published, are there any legacy applications/clients that need to be supported, etc.  Luckily Microsoft has been doing a great job creating documentation for ADCS.  There is a Design Guide here as well as a document for securing a Microsoft PKI here.

Using a GPO is the right approach for pushing out the certificate from your Root CA to domain joined systems.  Have a plan for non-domain joined systems too such as alternative platforms (Apple, *nix).  This goes back to my prior comment about planning where the certificates will be served along with the revocation lists.  AD is great, but also consider a more accessible web server.

All of this will allow you to issue SSL certificates (and many more!) that will be trusted by internal clients or more specifically anyone that trusts your Root CA.


Does hiding version numbers increase my security?

If that's your only security measure, this is what is known as security by obscurity.

Security by obscurity is bad if it is the only thing you rely on. Your first priority should always be ensuring that the software isn't exploitable in the first place. This means patching frequently. That said, there isn't any point in shouting out the exact version of the software you are using. If hiding the version numbers make an attackers life harder, by all means do it. Just make sure you don't get a false sense of security and that it isn't the only thing you do.


If you're using HTTPS/SSL and you trust your endpoints, this is fairly secure for your purposes, because the get parameter will be encrypted as part of the query string, so traffic capture is not a problem.

The "secret" hashes will most likely end up in the web server logs of the web server which servers your web application, but if you control these logs, then for your level of desired security that's probably a non-issue.

You'll obviously  also have to trust all the services which store these URLs (browser bookmarks, cloud services etc, but you seeem to be fine with that). I'd think the greatest risk was here (e.g. one of your users logs in using a public computer, and the next user of that public computer looks at the browser history, clicks the link and has access to your protected data).

If you're using unencrypted HTTP, your secret hashes will also end up in proxy server logs and basically anyone who can eavesdrop on your connection will have tons of chances to capture the secrets.

However, I'd only do direct GET param authentication if I really didn't care much about the secrecy and integrity of the data the secret hashes are supposed to protect (basically if I wanted to keep the hordes of stupid vandals at bay, but didn't think any determined person might be interested enough in my data to try to access it, and didn't have a problem if it turned out I was wrong).

A very simple way to considerably improve the security of your authentication scheme would be to have the secret tokens expire, or even better yet, to treat them as one-time-passwords. Give each user a list of tokens, to be used one after the other. This doesn't require much code on the server side and solves the problem of one of your users accidentally leaving/publishing his secret token somewhere.


How can I manage the hashing for large file size? May be file size is over 100 MB or something. In my opinion, it may take too long.

If you want to verify the integrity of a file you have to run over the full file. There is no way to skip any bits because exactly these might be affected by a change. Computing the hash over a file takes exactly one sequential run over the whole file and the algorithms are designed to be fast. You probably will not get it any faster.

  So I would like to use some fields such as file size, and creation date in hashing. Is that possible or safe way for hashing?

No its not. The contents of the file can be changed without affecting size and creation date. Apart from that the creation date is not a property of the file but a property of the storage, i.e. it can be changed without even affecting the file contents. This means with this proposal a matching hash does not proof integrity nor a hash mismatch shows loss of integrity.


What are the risks of connecting via VNC to an untrusted host?

There's a couple of potential risks which spring to mind.

Firstly if there's a vulnerability in the client software (e.g. a buffer overflow) by connecting to a malicious server it could be possible for the server to compromise the client machine via the VNC protocol.

Secondly, there's the obvious risk that the client machine is visible to the server (i.e. the server would know the IP address of the client machine) which may allow it to target the client for other attacks (whether these would succeed would of course depend on the configuration of the client).

The last risk that springs to mind is again kind of obvious which is that any data entered by the client into the VNC session on the server could be observed and modified, so for example by connecting to the malicious server and then using the browser on that server, things like website login credentials may be compromised.


Can browser cookies be "physically" stolen?

Yes, but the exact implications depend on the authentication techniques used by the website which set the cookies. For example, some websites may have particularly short expiry times for their cookies, or the website may do extra checks (for example IP address or browser user agent) before allowing authentication to continue. In general, session hijacking requires a few things:

The cookies must not have naturally reached their expiration date.
The cookies alone must be sufficient to authenticate the session (no TLS certs, etc).
The user must not have logged out (which would invalidate the cookies).

Some particularly badly-designed sites will not invalidate the cookies server-side when the user logs out or when the cookies reach their expiration date. These websites rely entirely on the browser, and are very easy to hijack once you have the cookies themselves. A well-designed website will keep track of the validity of the cookies independently of the expiration date set in the cookie, and should immediately refuse to accept any authentication cookies after the user logs out.


Cookies information disclosure "PreviousLoggedinUser"

It can be used by an attacker with access to cookies to determine the username of the last person who logged into that site using that browser. It can also possibly reveal a person's other account if they have multiple of them and were previously logged in using the other one and did not clear their cookies (which to be fair isn't necessary assuming they trust the site and expect logging out to fully log them out and not leave references to their account in cookies).

I am not sure why the server needs that information nor how is it used but there may be a vulnerability where the server blindly trusts the value and allows some kind of access based on it. In that case an attacker could set the cookie to anything they want and impersonate the corresponding user.

How to avoid it? Not set the value in the first place - again I am not sure what purpose it could serve, but if you truly do need such a value, keep it in the server's session instead. The client will not be able to see nor tamper with the value that way.


Launch a game client with custom protocol and auto login the user using web server's session

You could use something like a unique session ID. This means, your custom protocol would be

thegame://launch-tournament/tournament-id/VERY-LONG-UNIQUE-HASHCODE

How it works:

When the player klicks on the selected tournament in his webbrowser the server generates a unique identifer and stores it for some time. Just a few minutes.
Then this code will be appended to the link.
When the Gameclient launches, it sends this code to the server. It works like a one time login token.
The Server checks if the code is valid. If so, it will transmit the user information to the client and the player can start using his account.

To prevent fraud, the whole communication should be encrypted.

Additionally the server could store the IP of the Webbrowser together with the token and checks if the IP of the client using the token to login is the same.


Where exactly does the problem exist ?

Nowhere. There is no problem.

With ping you are working only at the network layer and on this layer there is no such thing as a hostname, there are only IP addresses. And crashsafari.com has the same IP address as s3-website-us-east-1.amazonaws.com because this is just an alias (DNS CNAME):

$ dig crashsafari.com
...
;; ANSWER SECTION:
crashsafari.com.        59      IN      CNAME   crashsafari.com.s3-website-us-east-1.amazonaws.com.
crashsafari.com.s3-website-us-east-1.amazonaws.com. 59 IN CNAME s3-website-us-east-1.amazonaws.com.
s3-website-us-east-1.amazonaws.com. 4 IN A      54.231.17.132

But when using a browser to access a site you are using the application layer protocol HTTP instead. Within this protocol the hostname is sent by the client (HTTP Host header) and thus different hostnames with the same IP address can be distinguished by the server. A request to http://crashsafari.com looks like this:

GET / HTTP/1.1
Host: crashsafari.com
...

whereas a request to http://s3-website-us-east-1.amazonaws.com looks like this:

GET / HTTP/1.1
Host: s3-website-us-east-1.amazonaws.com
...

And based on the Host header the server will use a configuration specific for the given hostname, which makes both sites look different even if they share the same IP address.


Does using a non Nexus/Google Play Editon Android device have a higher security risk?

Devices that are slower to get security patches are more vulnerable, all things being equal.

However, whether this means you should avoid them depends on your particular threat model and risk tolerance.


Why do cellphones not use software to simulate a NAT router between the phone and the internet?

NAT does not explicitly add security. It only implicitly adds security because it needs to keep a state for all outgoing connections to map incoming packets back to the originating connection - and thus implicitly denies any incoming packets which don't match an outgoing connection. But, this security can already be done with a stateful packet filter (like iptables) which is usually the base for a NAT solution anyway.

But, this kind of security is actually only needed to protect services on the phone which accept packets from outside even though they don't expect such packets. This means services which bind to any address instead of only the localhost address. Usually there are no such services, i.e. either they bind to localhost only or they actually expect traffic from outside.

That does not mean that such a packet filter is not useful on mobile devices. It actually is very useful because for example on a rooted Android phone you can use the builtin iptables with a nice interface (such as Android Firewall) to limit which applications can access the local network, use WLAN, use mobile data or even can be used with roaming.


What process on my jail broken iPhone is listening on port 80

I think you'll want to run "netstat" on your jail-broken device

http://www.iphonefaq.org/archives/971616

Related:
https://apple.stackexchange.com/questions/12238/how-to-display-alter-a-jailbroken-ios-devices-route-table

This looks interesting... No idea if it works:
https://itunes.apple.com/us/app/netstat/id400071873?mt=8


The only thing I can think of is a broadcast storm or similar, where responses from the target are what's keeping the attack going.  These are rare and almost invariably accidental, and there's an easier way to stop them than messing around with ports: just take the target system briefly offline.


If the attacker knows part of the password but not the length, does that help him in any way?

This would work as a personal scheme for keeping long passwords on paper - if you work out a system and apply it to your long passwords, but don't tell anyone else, it would be an effective form of security by obscurity. An attacker finding your password list might try the written password, then perhaps if he was very enterprising he might try variations on the written passwords, transpositions, subsequences and so on, but his chances of finding your exact transformation would be very low indeed.

However, an attacker might gain access to your password list and one or more of your actual passwords. The attacker could then observe the relationship between some passwords in your written list and the ones he knows in full, then know exactly how much space he had to bruteforce to get the real passwords from the written ones. In this case your effective password strength is reduced to the strength of your inserted string.

In practice many people use schemes like this for their most important and longest passwords, changing a few characters in an algorithmic but unguessable way then writing down the transformed password. This protects you very well against the common scenario of a house-burglary yielding a piece of paper with 'CitiBank: Login: xxx Password: yyy' written on it, but would be no use at all applied systematically, for all the usual reasons given against security by obscurity.


What auth info is locally revealed with eduroam WPA-Enterprise 802.1X?

Eduroam's RADIUS configuration creates a TLS-secured tunnel between your device and your home RADIUS server for the RADIUS Access Challenge.

While the local institution's RADIUS server will see who you are (i.e. your username) (they have to, in order to know whether to authenticate you locally or send you out to the Eduroam network), the actual authentication using the password is done completely inside the tunnel.

Here is a sequence diagram from the documentation:

See the Eduroam US Technical Overview for System Administrators for more details.

NOTE: The RADIUS standard does allow you to specify a separate "outer identity" that the local server sees which is different from the one that you actually use for authentication. However, that is typically left unset by default. If you want to anonymize your username, Eduroam allows you to change the outer identity to anonymous@realm where realm is your university's domain.

If you set an outer identity, the local institution's RADIUS server uses the realm portion to determine where to send the request. While the local institution may be able to log the user portion of the outer identity, they do not use it for the authentication.  Therefore, it is technically possible for someone else to pretend to be you to the local institution while still authenticating as themselves to their home institution.  However, if the two institutions compare their RADIUS server logs, they will easily discover that the other person is pretending to be you.  There is no way to hide such things as malicious or criminal activity as long as both institutions are logging access to their servers (which I know that at least some Eduroam institutions are doing).
Additionally, the realm of the outer identity must be the correct one for your institution in order for the authentication to succeed, so there is no way to pretend that you are from a different institution.

For more information about this process, consult the paragraph above Figure 3 and Figure 3 itself on the page linked above.


How to keep Mac secure from viruses, malware and keyloggers?

Nope it's not true, by design Mac has a better security model than Windows, but that doesn't mean it's secure. Furthermore due to the market share of Apple growing more and more chances are that Mac will get more interest from attackers than they currently have due to the growth of potential targets.

There have been virusses for Mac in the past like the Trojan BackDoor.Flashback which specifically targetted a Java exploit within OS:X.

I would indeed run anti-virus software on your Mac, it provides an extra layer of defense.


Should I stop using DSA key algorithm self-signed certificates in production in favor of RSA Certificates?

RSA is generally considered to be a better idea simply because it is less fragile than DSA. When used properly, they are both equally secure. The problem stems from the fact that DSA signatures, if created on a system with insufficient entropy, can leak the private key. All it takes is for this to happen once. RSA does not have this issue. So yes, best practices are to use RSA instead of DSA, if possible.

Make sure you pin the fingerprint (since you said the certificates were self-signed), and use keys that are at least 2048 bits in size. This goes for both RSA and DSA. If moving to RSA would be problematic, then there's really no rush. DSA is simply fragile and not an ideal choice, but is not cryptographically broken.

If you have control over the signing code, you can use RFC 6979 to create signatures in a deterministic manner without risking loss of the private key in the event that only poor randomness is available.