“Official statement” on php.net : CRYPT_BLOWFISH is strongest hash algorithm. Why?

we're talking about strongest for password hashing here. A good general purpose hash doesn't need to be a good password hash, and vice versa.
Length of the hash is irrelevant once it exceeds a certain threshold. A pre-image attack on an n bit hash costs 2n. For a 128 bit hash this is completely infeasible.
bcrypt using an exponential notation for cost and sha512-crypt using a linear notation is irrelevant. Comparing their CPU cost with default parameters is meaningless as well.

In practice you choose a time budget, say 10ms. Then you adjust the cost factor of the hash to match that budget. So if an attacker used the same hardware as the defender, then all decent password hashes would be the same.
An attacker uses different hardware from the defender. The defender uses a standard CPU. The attacker uses at least a GPU, or if it's an advanced attacker perhaps an FPGA or ASIC.

The difference between different hashes is how well they run on different kinds of hardware. BCrypt needs a few kilobytes of really fast memory. This works well with common CPUs, but doesn't work well with GPUs. So bcrypt is very GPU unfriendly. With FPGA the advantage of bcrypt is smaller, especially if it has integrated RAM. But it's still a bit better.
A a simple benchmark you could tune the candidate hashes to the same cost. Then run a GPU based password cracker, such as hashcat or john-the-ripper and check its performance. I expect bcrypt to have a much lower hashrate.
There is also another interesting password scheme called scrypt. It uses larger amounts of memory and if your time budget is large it's significantly better than bcrypt or SHA512-crypt.


How can I check whether file modified time has been spoofed on ext4?

Host Intrusion Detection Systems (HIDS) can offer this feature : File integrity checking.

I don't try it personnaly but according to the documentation AIDE can do this.

The idea is to create hash values of the files you want to verify they don't change then compare them regularly with new calculated values.


Doesn't imposing a minimum password length make the password weaker by reducing the number of possible combinations?

Doesn't this simply reduce the number of possible combinations?

yes, but not significantly.

As an analogy, consider passwords that are combinations of uppercase letters A-Z only, with max length of 8. Total # of possibilities = 268 + 267 + ... + 26 + 1 = 217.2 billion. If you restrict this to a minimum length of 6, that eliminates passwords of length 5 or less, which have a total # of possibilities of 265 + 264 + ... + 26 + 1 = 12.4 million, a tiny fraction of the larger password space.


What security considerations should I keep in mind when setting up home automation using IFTTT?

When using public services like IFTTT you must assume that you will be hacked. And then assess what can happen with all the knowledge a hacker may gain:

switching on a light? Probably not a big deal
fiddling with the thermostat? Except if your parents live in extreme climate conditions, this is not a big deal either
notification? depends on the kind of notification

In general, anything life-threatening (automatic alerts sent to doctors, pill distributors, ...) and potentially dangerous (electronic locks, ...) should not be dependent on a system you do not control, or at least being "generally accepted as safe" (having the green light from your medical institutions for instance).

Another element to consider is how easy it is to go from the identifier of the action to the physical address.


Can malware be dangerous even when quarantined?

No

Quarantine is nothing but a place to store the infected/suspicious files. When you quarantine a file it is deleted from the actual place and moved to the quarantine location (to the path that your anti-virus program has for them).

This is something like keeping a zombie inside a jail. Obviously it is not a threat as long as you don't open the cage.

In most anti-virus programs, the quarantine files are stored in internal binary formats. Since there is no physical connection between the infector file to your system (your anti-virus program works as the storage format is also a plus point), it is not dangerous.

Analyzing:

Regarding analyzing an infected file, yes it is not possible after quarantine. If you want to do that, you either try disinfecting it or restoring it to its original place (you have to disable your anti-virus program to do this and this is the place where you are opening the cage) and then analyze it. But remember the zombie might eat you up (unless you are good with shotguns)! So it is at your own risk.

Why not just send the infected/suspicious files to the anti-virus program team? They might give you a better picture after inspecting it with their updated virus signatures.

Bottom line: A quarantined file is not dangerous. But analyzing them yourself might be.


is it possible to extract a "hint hash" of some kind from another hash?

You want a scheme where, given only the hash values, you can compute whether two hashes refer to the same user or not. This is a rather complex question, so it has a rather complex answer. First, let's make sure we all agree on terms:

Def'n: Hash:

  A hash function is any function that can be used to map data of arbitrary size to data of fixed size. [wikipedia/Hash_Function]

For example, initials are a perfectly valid hash function (John Smith --> JS, Christina Secretmessagewriter --> CS), although it's no good for cryptography because it doesn't do much in the way of hiding.

Def'n Cryptographic Hash:

  A cryptographic hash function is a mathematical algorithm that maps data of arbitrary size to a bit string of a fixed size (a hash function) which is designed to also be one-way function, that is, a function which is infeasible to invert. [wikipedia/Cryptographic_Hash_Function]

If you click on "one-way function" and go far enough down the rabbit hole you'll find out that cryptographic hashes have to be indistinguishable from random, meaning that if I gave you two hashes, there is no way to gain any sort of information whatsoever about whether the two inputs are related (another googlable term for this is "avalanche effect").

So, by definition, what you want is at odds with the very idea of a cryptographic hash function - the goal of which is to prevent any information leakage.

Depending how much you care about information leakage, the answer can go on.

What you are asking for is to embed the hash hint inside the overall hash in such a way that it can be extracted again. There's no real security here because if you can do it, so can an attacker who knows your system, but let's explore it anyway.

One way to accomplish this would be to hash the USER:123 and fName:Alice parts separately and concatenate them to make your overall hash. Your "hash hint" is then just the first half of your overall hash (or first N chars if you use different size hashes). It meets the requirement that getHintHash(hash) will extract the hash hint from the overall hash, and it allows you to corrolate related record together without actually exposing the plaintext.

You could do something more complex by inventing your own non-cryptographic hash function that spreads the hint out over the massage rather than sticking it on the front (maybe through some clever math or using a trick from the stenography bag of tricks), but it's not clear what that gains you.

At the end of the day, you might gain some security-through-obscurity and you might be able to compress your hash a little smaller, but it's really equivalent to concatenating two hashes.


unknown MAC address in the LAN, DD-WRT router

It doesn't look like a DDOS (Distributed Denial of Service) attack.

12:34:56 is an unknown OUI (Organizationally Unique Identifier)

You can understand more about this MAC address by listening on the LAN with a protocol analyzer like Wireshark.


The brute-force resistence of bcrypt versus MD5 for password hashing?

Bcrypt use a configurable iteration count, so the answer to your question is: whatever you want it to be.

If the iteration count is such that one bcrypt invocation is as expensive as 10 computations of MD5, then brute-forcing the password will be 10 times more expensive with bcrypt than with MD5.

If the iteration count is such that one bcrypt invocation is as expensive as 10 millions of computations of MD5, then brute-forcing the password will be 10 million times more expensive with bcrypt than with MD5.

That's the point of having configurable slowness: you can make the function as slow as you wish. Or, more accurately, as slow as you can tolerate: indeed, a slow function is slow for everybody, attacker and defender alike.

An additional factor is that bcrypt is, by nature, quite hostile to GPU optimization; this is due to the kind of operations that are used within the algorithm. MD5 is, by comparison, very easy to implement and run efficiently on a GPU. This means that an attacker may get a substantial boost out of a GPU when cracking MD5-protected passwords; while with bcrypt he will need to use the same kind of CPU as the defender. See this answer for further details.

If we want some realistic figures: with a good GPU (off-the-shelf, a few hundreds of dollars), MD5 speed can reach, say, 10 billion instances per second (see benchmarks there; the machine which goes up to 93 billions per second contains 8 GPU). However, with bcrypt, it would be customary to crank up the iteration count so that each hashing takes 0.1s on your server. Instead of buying a GPU, the attacker will buy (or rent) a couple multi-core CPU and will be able to try, say, 100 passwords per second. With these figures, one can say that bcrypt will make the passwords 100 million times more robust than MD5.


How is my website vulnerable for sql injections?

Always use parameterized queries, string concatenation leaves room for error, stop leaving that room (they also look a lot nicer).

Also, because id is an int, I don't need quotes to inject:

$id = '0; Drop Table myTable;--';

$sql = "SELECT * , COUNT( * ) AS amount
        FROM articles
        WHERE id = 0; Drop Table myTable;--
        GROUP BY id";

I like to use is_numeric to check if it's a number and kick them out of it isn't.

Edit:

PDO provides preparation of SQL queries:
http://php.net/manual/en/pdo.prepare.php

So for example:

$sql = "SELECT * , COUNT( * ) AS amount
    FROM articles
    WHERE id = :id
    GROUP BY id";
$sth = $dbh->prepare($sql);
$sth->execute(array(':id' => $id));


Does error checking for SPF Records make sense?

The RFC for SPF addresses this case: an invalid SPF record will result in a PermError.

But there are no clear rules how to deal with a PermError: the mail might be rejected (thus making the sender aware of the problems) or it might be forwarded. In the latter case it might be useful to include the information into the mail, i.e. add an Received-SPF header with the PermError status so that spam filters upstream (like in the MUA itself) can take this SPF status into account.

Given that according to your information you deal with lots of invalid SPF records even from major companies rejecting such mails is probably a bad idea. I would thus suggest to forward the mails but include an Received-SPF header with the PermError status and details about the error as comment.


Such a setup can be trusted, since the payment details cannot be extracted by your hacker and the payment details can be verified securely.

The thing to watch out for is that a lot of user might not bother to double-check the details on the https page, or if there are 'hidden' paramaters sent along that aren't displayed and verified explicitly.


My logic is that if a malicious actor is able to connect to the "secure" network and get an IP address, you have much bigger problems from a security standpoint than DHCP

I partially agree with that but from a network-security point of view, DHCP can be an extra possible attacking vector for the internal network so it is considered a risk. I guess DHCP is considered insecure cause it can be abused by attackers. Two well known DHCP related attacks are the following:

DHCP starvation attack
DHCP spoofing which leads to MITM

In most cases through DHCP an attacker may be able to obtain or in some cases modify useful information (not only trivial things like the gateway ip) like:

the DNS servers (e.g. can be useful for DNS spoofing attacks)
the domain name
client host names (e.g. that might be useful for targeted attacks)

Also in some networks other things might also be configured through DHCP server like NetworkManager, NETBIOS servers, NIS servers, NTP servers etc...So for example, by abusing/exploiting DHCP you might be able to also abuse those services. An other example is shellshock, which can also be exploited over DHCP.

So I guess since DHCP is known to be usefull for attackers, it is considered one more possible attacking vector and that is why it may be considered a risk.


How do you know your server has been compromised?

UPDATED

I would check the following:

Logs. If you have root access you should check things like history which will give you command history and log files in /var/logs.
Baseline. If you have a baseline like file hashes to work with for application and system files this will help a lot. You can also use backups to compare a previous state. If using a backup to compare files, use a slightly older one if you can. The site may have been compromised a while before and it is only now that the redirect has been activated.
Check any includes. The files may not be on your server. They may be script includes such as <script src=”http://baddomain.com/s.js” /> or iframe type tags. Also do not exclude images, PDFs of Flash (SWF), video files. It is a fairly common trick to embed links in to files of a different content type. I would suggest you inspect them by hand particularly at the start and end of a file. The file may be completely a link/html/javascript or may be a legitimate image file with a link trailing at the end of the file.
Check for unusual file dates, sizes and permissions e.g. 777.
Check cron jobs for unusual jobs. Someone compromising a system will often leave a back door to get back in again and again. Cron is a very popular way to do this if they managed to get that far.
Check for the absence of files, you may not be able to have access to logs but the absence of them is equally a tell tail sign that someone has cleaned up after themself.
Use search engines. Not surprising search engines are great at finding everything. Use directives like site: e.g. site:yoursitehere.com baddomain.com see if you get any hits.
Often a link or redirect will be obfuscated so long javascript code with single letter variables should be analyzed carefully.
Do a packet capture with a tool like Wireshark or tcpdump from a secure workstation to the site. Save it to file and search the file for a parts of the url.
Check database records that may be queried or updated. The link could be injected in the database not the PHP.
Don't exclude the client's workstation. Use a free online virus scanner if need be. Also check nslookup and see what that resolves to. Check browser extensions, clear cache and check hosts files.

To clean it up (if you are compromised) you really do need to go back to bare metal and reinstall. It is painful but is really the only way to be sure that you have got the whole lot.

To prevent it in the future you should be doing the following (although you may already be doing some of these):

Harden servers, including using vendor recommendations on secure configurations, using up-to-date software. Apply tight security control such as permissions, password policies. Also see folder and file permission shared host advice.
Implement quality control proceedures such as testing on low security environments, code review and testing.
Have your web application / web site vulnerability tested by a professional certified tester at least once. Look for EC-Council, ISO 27001 and PCI certified testers. http://www.eccouncil.org/certification/licensed_penetration_tester.aspx
Check out OWASP www.owasp.org and http://phpsec.org/projects/guide/2.html for web application security resources.
Use Intrusion Prevention System (IPS) tools. However depending on your hosting provider you may have limitations on what you can use. Host based IPS tools should be ok if you have a dedicated virtual machine.

Hope that helps. Otherwise maybe you could provide more information about the systems you are running?


How can PHP unserialize() object injection be used to bypass authentication?

unserialize allows the creation of arbitrary object constructs of any class with arbitrary attributes. During deserialization, the lifetime of an object, and the interaction with the object, several methods including magic methods may get called using these arbitrarily definable attributes. An attacker may be able to utilize the functionality provided within these called methods for his benefit.

In the end, the exploitability of such a vulnerability solely depends on the available classes and their functionalities. Have a look at the Observed Examples and References section of CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes for examples and further information.

And since the mentioned vulnerability in FreePBX is accessible without authentication (it actually happens during the authentication process), one may say that it bypass authentication.


I suppose that by CSR you mean a Certificate Request. A certificate request is something that is meant to be sent to a Certification Authority so that the CA may turn it into a Certificate. The request shall contain everything that the CA needs for that, i.e. everything that the CA cannot infer or generate by itself.

One critical piece of a certificate is the public key. In a PKI, the two usual emplacements for key pair generation is on the requester or on the CA: either the requester generates his own key pair and sends the public part to the CA as part of his request, or the CA generates the key pair and will send the private key to the requester along with the certificate. I assume that you mean the former: your "CSR generating tool" actually generates a key pair, and puts the public key in a certificate request.

There are several standard formats for certificate requests. A very common format is PKCS#10. If your problem indeed involves a PKCS#10 request containing a public key, which is to be extracted, then it is "just" a matter of locating the public key in the bunch of bytes. PKCS#10 uses ASN.1, with the structures defined in the RFC:

CertificationRequest ::= SEQUENCE {
     certificationRequestInfo CertificationRequestInfo,
     signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
     signature          BIT STRING
}

CertificationRequestInfo ::= SEQUENCE {
     version       INTEGER { v1(0) } (v1,...),
     subject       Name,
     subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
     attributes    [0] Attributes{{ CRIAttributes }}
}

SubjectPublicKeyInfo { ALGORITHM : IOSet} ::= SEQUENCE {
     algorithm        AlgorithmIdentifier {{IOSet}},
     subjectPublicKey BIT STRING
}

So the PKCS#10 request is a SEQUENCE whose first field is a CertificateRequestInfo structure, another SEQUENCE whose third field is a SubjectPublicKeyInfo, which contains the public key that you are looking for. THe public key consists in an identifier for the type of key, and the encoded key value itself.

Your task is now a matter of decoding. Parsing ASN.1/DER with custom code is doable, but requires care. You'd better use some existing library which will do all the hard job for you. OpenSSL can help; see its PEM_read_bio_X509_REQ() function for decoding, then X509_REQ_get_pubkey() (though it must be said that the OpenSSL documentation can be a bit daunting).

An important point is that a public key is a collection of a few mathematical objects, while a hash function takes as input a sequence of bits. So, in order to hash the public key, some sort of encoding must happen, and if you want to compute the right hash value, you must encode the key in exactly the way required by your situation (you say that you "have to provide... a SHA256 hash of the public key": I suppose that you have some sort of formal requirement which describes the exact format with all needed clarity).


How to secure a digital ID from being faked?

the users will scan a static QR code around the neck of the door supervisors, which will display the ID on the user's phone until dismissed.

If "the user" is the subject of verification then you cannot create a system with any level of accuracy/trust based around this constraint. The subject controls both the identity data and its processing. Even if the door supervisors were technologically literate, they cannot trust information displayed on someone else's device.

Assuming that you have a database of customers and verified ages (or more correctly dates of birth) then the only way I could see this working would be for the customer to direct the door supervisor to the record (e.g. by presenting a QR code) which the door supervisor could resolve on their own device. This still needs a mechanism for tying the record back to the person standing in front of them - the most obvious and least intrusive way to do that would be to present a picture of the customer on the door supervisors device (there are lots of different ways to resolve this last part). But this is going the route of solving an impossible problem by changing the constraints.


How could the content of an e-mail get leaked?

How could the content of the mails have been leaked?

This is a known strategy of the Emotet malware campaign, see Emotet is back, it spreads reusing stolen email content. The lawyers system was likely compromised by the malware and details of a previous mail exchange were used to bypass filters and gain trust of the victim.

And what are steps to take now?

Consider the lawyers system compromised and thus communication with the lawyer and shared personal information compromised too. How relevant this is and which steps need to be taken for further protection depends on the sensitivity of the data shared with the lawyer. Depending on where you live this kind of compromise might also be relevant in the scope of data protection laws, i.e. GDPR etc.


Is there a way to prove some content came from a specific website?

The question then is, is there any way one can prove some content came
  from a website?

Not using SSL. As you mentioned, the actual content is encrypted using a shared symmetric key. Therefore either you or the other party could have created the cypher-text.

A trustworthy 3rd party such as Google cache or archive.org should be sufficient in most contexts, as mentioned in the comments.

There are plenty of cryptographic techniques which can be used for this purpose, but in this context you'd need the site to cooperate by signing the actual content using their private key (which is contrary to how SSL works).


Can a firewall appliance block http requests?

Yes. Conceptually, a firewall appliance (or a firewall application) will be able to distinguish between HTTP and HTTPS requests and, in the case of HTTP requests, will be able to view all the data being transmitted (not just the domain and IP). It can then block or modify any data going through. Not all firewalls have this capability, however. You will need to find one that meets your requirements.
You can also do this with HTTPS requests if you have a firewall that supports TLS interception, but then you'll need to install the firewall appliance's root certificate into your browser for it to trust it.


Is my sha1 SSL cert safe if they expire before 2016?

But, if all my cert expired before 2016, so I assume no action need to be taken to prevent the warning, right?

Correct.

Chrome (your link),
Firefox (https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/)
and Windows (http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx)

should not complain.

Further reading if you're interested: http://blog.ivanristic.com/2014/09/sha1-deprecation-what-you-need-to-know.html


Is there a way to prevent hackers from using cookies to bypass two step verification?

Matthew's answer is definitely the correct answer, but I thought I'd follow up with more details:

Cookie-based authentication has a big weakness - the cookie is all you need to authenticate.  If someone is able to steal a user's cookie, there is nothing built into the cookie authentication process that let's the server know that shenanigans have happened.  You use the example of an attacker having physical access to the computer, but that is a rare case to look out for.  XSS vulnerabilities on sites with insecure cookies are a far more common way for cookies to get stolen.  Also common: session fixation attacks, packet sniffing over insecure wireless networks for sites that don't use https, and various other forms of MITM attacks.  To be clear, this isn't just an issue for cookie-based authentication.  The underlying problem is that HTTP is a stateless protocol, which means that if you can replay a previous request completely, there is no way (baked into HTTP) for the server to know that you are not the same person.

So how do services make sure that the person they talk to are the person they actually want to talk to?  The answer is not necessarily straight-forward.  As Matthew mentions, you have to monitor your access credentials in other ways: IP address changes, browser changes, user agent changes, etc... In essence you keep track of meta data related to the devices you are talking to and take close attention to any suspicious changes.

As you note in a comment, even this isn't fool-proof.  People can obviously fake user-agents.  This could possibly be countered by using device fingerprinting techniques (Device fingerprinting & Mass Computer Surveillance) which an attacker has substantially less control over.  IP Addresses aren't fixed, especially for mobile carriers, but as long as each device has it's own cookie, even this can potentially be tracked and accounted for.  If a given cookie has been associated with the same IP address for 6 months and is suddenly showing up in another country, you probably have a problem.  If a device frequently changes IP addresses (i.e. a phone) but now shows up with an IP address not associated with a mobile carrier or their usual geographic area, you probably have a problem.  The other thing to keep in mind is that each device should have a unique cookie.  Therefore, even if the IP address associated with a cookie normally changes, if you are now receiving requests from that cookie from two different IP addresses at the same time, you probably have a problem.

In the end, the simplest way to fix things if their appears to be something fishy going on is to simply invalidate all cookies (aka log the user out).  The legitimate user is only slightly inconvenienced - they just have to log back in.  The attacker though has lost all access and has to start over.

The take away

There should be a couple obvious takeaways from the above discussion:

There is no definite answer.  A sufficiently smart attacker has lots of ways to try to hide that he has stolen credentials, once they are stolen.
A system that hasn't setup extensive security/monitoring around their login credentials will have no way to know that something is going on, and no way to react.
There is no clear "Okay, you are secure now" point.  There is a lot that a system can do to secure login credentials, but ultimately there are things not under the server's control that can allow credentials to be stolen.  There are ways to detect stolen credentials, but they are not always easy or straight-forward and can take a lot of effort to setup, tune, and use.  It is also possible to be overzealous and cause problems for legitimate users.

So how do the big guys minimize the potential damage done from people walking away with credentials?  Short answer: Defense in depth.  Secure access credentials at all layers of the application, monitor meta data from clients using access credentials, and if in doubt, log them out.


Disabling post-pageload http requests to account for XSS

No. Your Javascript application can be modified by the end user on their own machine, and send anything anywhere.

You should look at ensuring that your server side component only accepts chat messages from authorised sources, and that it isn't possible to make the Javascript application an authorised client without information which isn't available to the end user (e.g. require a server generated token to send chat messages - look at CSRF protection methods for an example).

Anything running on a system you don't control can be modified given sufficient time and effort, so you need to keep your protection mechanisms on systems you control.


How can I extract the hash inside an encrypted PDF file?

UPDATE 21 Dec 2017

The script pdf2john.py doesn't exist anymore. It has been substituted by a perl version, pdf2john.pl.

Extracted from HashCat Forums, this method works for me (requires Perl):

--Download pdf2john.pl from the suite John the Ripper (OCLHashCat works with the same hash format as John the Ripper):

wget https://github.com/magnumripper/JohnTheRipper/archive/bleeding-jumbo.zip
unzip bleeding-jumbo.zip

--Use it to extract the hash from your .pdf file:

perl JohnTheRipper-bleeding-jumbo/run/pdf2john.pl MyPDF.pdf > MyPDF-Hash.txt

--Output file MyPDF-Hash.txt must be edited. Original would be something like:

MyPDF.pdf:$pdf$4*4*128*1028*1*16*652fc762fdb12c47a5f90ddd2b99b809*32*dd86d858f914809078a4a47348d32c0fc4e9c08042a10e6434b48b698de7731f*32*3c1e693526d5bc8da15b99eea6cbc6ed2c2397e23e2c39d1974fdc004c588cff:::::MyPDF.pdf

so use your preferred editor:

nano MyPDF-Hash.txt
notepad MyPDF-Hash.txt

and leave only the part inside double colons : :

$pdf$4*4*128*1028*1*16*652fc762fdb12c47a5f90ddd2b99b809*32*dd86d858f914809078a4a47348d32c0fc4e9c08042a10e6434b48b698de7731f*32*3c1e693526d5bc8da15b99eea6cbc6ed2c2397e23e2c39d1974fdc004c588cff

--Hint: you can do the extraction and the edition in one step by using sed (UnxUtils version too, if you are doing it from Windows):

perl JohnTheRipper-bleeding-jumbo/run/pdf2john.pl MyPDF.pdf | sed "s/::.*$//" | sed "s/^.*://" > MyPDF-Hash.txt

--Your MyPDF-Hash.txt file is now ready to use with OCLHashCat (or John the Ripper).

NOTES:

Tested working on CygWin (Windows).
Tested working on Kali and Ubuntu Linux.


One side note not directly related to the problem :

I'm not sure if the book you're using is  the best to start your pentesting\exploit development with.
I would recommend OSCP's hands-on or Georgia weidman's book
"Penetration testing A Hands-On Introduction to Hacking"
Or you can try SEED project's labs.

Now i'm not sure i can tell what is going wrong without trying the lab (Which i'll try do and get back to you).
However, I can tell you that increasing the buffer's size is not always the answer.
In fact, it sometimes corrupts your exploit because your extra long buffer might overwrite the caller's function data causing the app to call the exception handler which -if happened -will move the address of the exception handler function  to the EIP, and will force you to do things in a different way to overwrite the EIP because now the address of the exception handler is in the EIP, not your buffer .


Mandadory checks a client should make to verify a ssl/tls certificate

And you should make a lot of checks about the cerificate genuinity, i.e. to avoid MitM or false-issued certificate by "so-called stolen" CA key. Take a look and star at Perspectives Project to have a full picture


How Can I Prevent Hackers From Spoofing TCP messages onto my server?

Never trust the client. If the client has a local copy of your application, they can do many things to manipulate and reverse engineer it. You can possibly slow down and discourage this by obfuscating and encrypting/packing the code, requiring certificate pinning, employing anti-debugging techniques etc., but a determined adversary will not be delayed for long.
Instead, focus on the server side. Make sure users are properly authenticated before they are able to interact any further, and check if they are properly authorized for every action. It is especially important to validate their input; since you can't trust the client, you should expect to receive invalid input. Any critical code (business logic, authn/authz, secrets, proprietary code) should be solely located on the server side. If the application is designed correctly, you shouldn't need to care about having rogue clients.


Is a long, random string in a URL considered adequate protection from unauthorised access?

I would say: A long random url is essentially a password.
So its still a adequate access Control.

Compare for example going to http://www.example.org/login.php and typing username=admin password=somelongrandompassword, or simply going to http://www.example.org/login.php?login=admin-somelongrandompassword

Yes, there is some attack methods that did not initially exist if a normal login would have been used, for example poking in browser history, link sharing and so on.

But you as a end user must be cautionous too, and understand to not:

use the website from a publicity accessible computer. (or ensure its a computer designed to "reset" each session so any sensitive information in cache, history and cookies are cleared)
not share the link with unauthorized persons.
Watch out if the SSL indicator is not present.

And of course, the administrators who requested you to submit the documents (which uses the documents in one way or Another) must perform the same care, but I Think the administrators are well aware that the links contain the authentication information for accessing the documents.


Plausible way to hack website keeping [username / hashed password] pairs?

If an attacker gets write access to the database (e.g. through SQL injection), then there is nothing preventing them from changing users' password hashes to their own. The reason it's not brought up too often is that, as you point out, there are usually more serious concerns if an attacker has write access to the database.

  I'm thinking of a case where the rest of the valuable information is encrypted in a way that can only be accessed by certain users.

The best way to do this would be to derive the key from the user's password (separately from the password hash used for login), in which case replacing the password hash wouldn't allow the attacker to decrypt the information.


I am a political activist, its likely that my computer will be compromised in the future, how can I secure my data?

Tails is exactly what you want, being designed with activists in mind! It is a live Linux-based operating system that can run from a DVD or USB stick which is amnesic, meaning that any data that isn't explicitly saved to storage will vanish on reboot, including settings, metadata, and other information. Every time it boots up, it boots up fresh as if you have never used it before. Additionally, it forces all network connections through Tor, using a firewall to protect even from a compromised web browser.

Tails includes a variety of useful tools for document processing such as video and audio editors, text and document processors (generally compatible with the Microsoft Office suite), and a myriad of tools for cryptography, such as email clients supporting GnuPG encryption, chat clients supporting a wide variety of protocols (IRC, XMPP, AIM, etc) with chat encryption using OTR, and disk encryption utilities. It also contains Tor Browser, a browser designed for anonymity with use of the Tor anonymity network.

Basic evil maid attacks are prevented by keeping the Tails DVD or USB stick on your person, or downloading and verifying a fresh one if your primary copy was out of your sight for too long and may have been compromised. However, it is effectively impossible to protect from a sophisticated attacker who has prolonged access to your computer and is able to insert hardware backdoors.

Tails does

Prevent someone with your powered off computer from learning what was done on it.
Protect the content of your internet communications from a Wi-Fi or ISP-level attacker.
Allow you to visit websites without the websites knowing your location (anonymity).

Tails does not

Hide the fact that you are using Tails from an attacker on the network or a local adversary.
Protect your computer from prolonged physical access before or while it is on.
Prevent you from making OPSEC mistakes, such as accidentally publishing your identity.

For more detailed information on Tails' threat model, consult the design document.

Disclaimer: While not a core developer, I contribute code to Tails and as such could be considered associated with it.


How significant is the invalid SSL cert at aoprals.state.gov?

You should not be shouting about this at all, it's (probably) totally fine.

This does look a bit odd, possibly a misconfiguration, but it depends who the target audience of that web page is.

Option 1 "bad cert") This site is meant to be consumed by the general public and should have a publicly-trusted certificate.
Option 2 "should be firewalled") This site is meant to be consumed by members of that department and should probably be behind a firewall (ie not accessible to the internet)
Option 3 "working as intended") This site is meant to be consumed by members of other government departments, so is meant to be internet-facing, but only consumed by people with the government's root certs installed in their browsers. (ie they really don't care whether you trust their site or not because you are not the target audience).

A quick look at the web page looks like it's meant to be accessed by government employees abroad who work for various departments, which sounds a lot like Option 3 "working as intended":

  The office compiles statistics of living costs abroad, quarters allowances, hardship differentials, and danger pay allowances and computes the established allowances to compensate U.S. Government civilian employees for costs and hardships related to assignments abroad.


Is there known statistics of passwords used during brute force password attacks?

As I understand it, brute force attacks come in a few flavors:

True brute force, starting at A, moving to B, and so on until you get a hit.
Dictionary attacks, working through all known words.
Targeted attacks, working from your own password list (made from leaked passwords, and transformations upon them).
Targeted attacks using the personal information of the target.
A combination of the above.

1 and 2 you can defend against, but there aren't any specific lists. Keep people away from whole words, and increase complexity, and you can do something.

For 3, you've got a password list, banning all entries on the list may not be the best move, but you can take the most frequent offenders.

For 4, there's not an easy programmatic solution. It's a people problem not a technical one.


Cordova's APP_SECRET discovered in config.xml file

I am looking at a number of Cordova mobile apps at the moment, and
  almost every single one of them appears to have the APP_SECRET
  hard-coded in the Cordova config.xml file. Is this a major risk?

Microsoft does not consider it a major risk (neither do I), since the APP_SECRET value is used to map the app to an user account in App Center, and the App Center itself is only used for reporting of Analytics, Crashes and Push Notifications.

Configuring the APP_SECRET value in the config.xml is a Microsoft requirement. From the App Center SDK for Apache Cordova GitHub page:

  To get it working in your app you will need to add some configuration
  values to your app configuration in config.xml file. See list of
  available parameters below

  APP_SECRET - (required) App secret which enables App Center to map this app to the right user account

A threat model would better define the risk and impact of this scenario, and with the Microsoft official documentation confirming this is the correct setup, and knowing the App Center does not handle sensitive or critical information for the app, one can argue having the APP_SECRET value in the config.xml file, portrays a low risk with a low impact.


Why are some Bluetooth devices susceptible to ping floods and some are not?

This is a type of Denial Of Service attack. You need to exhaust the resources of the victim in order to make a successful attack. The memory on a smartphone is way more than that of a Bluetooth speaker and so that attack has to be of a much larger scale even without any additional countermeasures deployed in the smartphone.


Can a sniffer installed by user on his machine eaves drop on my application and reverse engineer it? (Fiddler 2 HTTPS Sniffing)

Will it allow it to analyze my web service methods structure?

Yes, SSL/TLS only secures the transport of the data between your and the user's machines.

  Will the user be able to reverse engineer the user name and password of my application and access my web service?

If your application includes credentials to speak to the server, then most likely yes (this is true in general and has nothing to do with SSL).

  Will the user then be able to build his own messages (REST/SOAP) and interact with my web service?

Yes.


Is an index, nonce and HMAC good enough for session management?

If you're storing session identifier tokens server-side, tokens from a cryptographically secure PRNG work fine, assuming you use constant-time checks (either through evaluating the full length every time or via hashing before comparison). If you want to make the lookup into your session collection faster, and you're willing to trade away revealing some info about the number of active sessions in exchange for the performance improvement of using an array lookup instead of either a hashtable or a binary search, you can add an index to the random token... but the index's only job is to be a performance optimization.

HMACing the whole token afterward shouldn't be necessary, since there's neither predictable or time-able data to tamper with, so tampering gets you nothing. Replay is eliminated by just using a decently-long token. Adding an HMAC will (marginally) increase server load for no clear value (it might reduce the already-minimal risk of compromise from an attack on something below the application layer, such as CPU caching, but it's also additional complexity and thus avenues for things to go wrong with minimal expected value).

You say this is for research, not implementation, but it's still not obvious why you'd try going this route. It looks like it started with a clearly terrible idea (use an index as a token), a failed attempt to patch that idea (hmac the index... oh wait, replay), and attempted to patch the bad patch. Security is often improved iteratively, but the basis of this whole approach is such a bad idea it's not worth trying to fix.

Assuming the MAC key is kept safe and that the nonce is stored and checked server-side, this does work. Neither the generation nor the checking of the nonce has many specific requirements so long as the tuple (index, nonce) are never reused; you could (if you didn't mind leaking even more info about how many sessions have ever been created) use a simple counter (long enough to prevent wrap-around) for the nonce. Assuming you were really wedded to this index-as-the-primary-identifier-of-session idea but wanted to stop the info leaks, you could even encrypt the token. At that point, though, your system is deeply over-complex, your token much longer than it needs to be, your server doing more computation on every request than there's a need for, and you've gained approximately nothing over a simple secure-random token + constant-time check.


Norton blocks my Metasploit attacks, is there a way to bypass?

Looking at the error message it seems that exploit itself was detected, not the payload. This is bad. So encoding your payload or second stage does not help here. I would suggest to fragment the ip packets with something like fragrouter.


Is it imporant that a cookie should have secure flag set if the website is running on HTTP?

From the documentation of Set-Cookie:

  Secure Optional
  A secure cookie will only be sent to the server when a request is made using SSL and the HTTPS protocol. ....
  Note: Insecure sites (http:) can't set cookies with the "secure"
  directive anymore (new in Chrome 52+ and Firefox 52+).

In other words: it makes no sense to set secure on plain HTTP at all since a cookie with such a settings would essentially be ignored.


Why is it ok that OS X defaults to ignoring owership on external volumes?

The problem is that ownership of a file is expressed by the UID of the owning user (and GID of the group).

The UID is usually generated locally when a user account is created. If you have accounts on different machines you will in many cases have different UIDs. (Unless you have a central user registry for all machines in question)

Thus, if you create a file on one machine, and attach the drive to another you have an account with the same name on, it would in many cases not "belong" to you.

Even if OS X would manage ownership based on user name instead of UID, how can it know that user "tom" on one machine is the same person as "tom" on another?

Admittedly, just ignoring ownership is taking the cowardly way out, but to do it right is not easy at all, especially if, as you say, other may have a legitimate right to access the data.


Do the BEAST and CRIME attacks apply to an IMAP service?

CRIME and BEAST are chosen-ciphertext attacks. The attacker needs to send tens of thousands of requests in the connection of the user. This works well for a web browser. Theoretically, it is possible for IMAP by sending mails to the victim, however the target plaintext (IMAP password) needs to be in the same packet as the chosen ciphertext. This is usually not the case for IMAP.

Nevertheless, it's probably good to copy the offered SSL versions and algorithms of popular IMAP services, like Google.


Extracting as much information from a browser request as possible?

Most spammers aren't actually humans, but automated scripts sending forged requests to your site. Identifying them though JS is pointless, because they won't run it. Identifying them based on server headers might work for a while, but they will likely look just like a normal user's, and the spammer might well change them if you start blocking their requests.

A more reliable ways of stopping spammers is CAPTCHA (use reCAPTCHA and leave the hard work of identifying bots to Google - these days they don't even show anything to the user!).


How do I figure out how malware infected my server, and the subsequent sites on the server?

Well, I see a lot of questions in there ! Let me take them up one by one !

So there are two attack vectors in your case. The your webapplication and the webserver itself.

  I mean, I don't even know how the injection/XSS/malware problem even began. I don't know who started it, and why.

All injection/XSS/malware/redirection problems are basically issues with your webapplication. Hardening your server by patching and softwares like failban won't help you there. You should probably review your web code to make sure you are not prone to SQLi and XSS. There is only one solution: validation!. Validate (and escape) all bits of information you are receiving from your users. Be it date, readonly form fields, hidden fields, dropdowns, radio buttons or anything.

For the redirections, you should check the source of your pages to see the code that is causing the redirect. You can then grep your code base to see if that piece of code is appended to your php/html files (indicating a server breakin via FTP/SSH) OR if that code made its way in your MySQL databases (indicating a sql injection on your web-application).

Remember SQLi/XSS attacks don't take many attempts so failban is unlikely to ban those IPs.

As to who started it and when, you can try looking at the apache access logs to see if you can find something interesting. If an attack was mounted on your web application and used querystring parameters, access logs might have recorded it.

You also mentioned:

  Brute Force Hacking (I can verify this with the Auth logs)

Brute force SSH/FTP attempts on any public facing site server is not uncommon. SSH ports constantly get bombarded with dictionary based attacks. I'd suggest having key based authentication and disabling password authentication altogether. If that is not possible, you should have pretty strong passwords that cannot be brute forced.


To extend the answer of Can malware be dangerous even when quarantined?

AV quarantine is served as :

Audit zone : let user to audit to decide whether to send the potential malicious file to AV company for further inspection.  You shouldn't send a infected document if you think the document itself contains some sensitive data.
False positive does happens, you can recover the file from quarantine and may choose to report false positive or add the file to the exception list inside AV.
It is packed & encrypted  in non-executable format and inaccessible for all uncompressed tools.  So this will prevent an redundant detection and also abuse by malware. Nevertheless, depends on AV implementation, the quarantined folder should not be "exception safe haven" for malware (if they discover it) to hide the payload.


Safely connect to remote site from cloud based code

The solution I use in the case of secrets (not only for your case, but also to make sure that I do not commit them with the code) is to put them in an environment variable when starting my code

$ API=kjsdhtgsdsdskdjsldjsldjklskjd /usr/bin/python3 mycode.py

It is not absolutely secure as the key is still in memory. It is also a pain to start the command with the secrets like this.

I usually end up adding the keys to the systemd service file I start my code with. It is in a file, but at least not together with the code.

Finally you can prompt for the keys at startup, which is not practical is the code is supposed to run headless.

The enterprise solution is a HSM, which is a glorified service to retrieve your keys from, based on some criteria.


How can I double check security against a TLS on a public IP?

TLS only protects the communication between client and server against sniffing and modification. This means that it does not make an server side application magically secure against attacks from a malicious clients. It also does not make any existing authentication methods stronger, i.e. weak password will still be weak passwords and they are as easy to crack as without TLS. TLS can add a way more secure authentication method though in the form of client certificates.

Based on this the more secure approach is your first proposal, where the user first needs to authenticate against the SSH server (hopefully key based authentication and not passwords) and then can access the docker registry server. This is more secure since it hides everything behind an additional and strong (if key based) layer of authentication.

With proper authentication like client certificates the web interface of the docker registry could also be made public, but then you loose the protection of the additional SSH based authentication layer. Anything except the web interface should not be made accessible from outside, i.e. no database etc. But as far as I know this is also not needed for a docker registry.


There seems like a wide gaping hole in the process for checking integrity of e.g. linux distro releases

In short, the TLS PKI used in HTTPS and the packet signing with GPG aren't complementary layers of security in this context, but against totally different risk models.

Getting the public key over a secure channel. You get the public key from a trusted source, in this example over HTTPS from https://getfedora.org/static/fedora.gpg, where getfedora.org is the official site of the distribution, and the connection is encrypted using PKI validated certificate.
If in doubt, you could minimize the possibility of MitM by accessing the site from a trusted location (not e.g. over public WiFi) and by examining the certificate and the connection details manually. It's also possible to cross-check the details with some external diagnostic tools like SSL Shopper's SSL Checker, DigiCert's SSL Installation Diagnostics Tool or even Qualys' SSL Server Test. If the details match, it's unlike someone is intercepting your connection with a fake certificate signed by a trusted CA.

Getting the packages over insecure channels. Signing the packages allows a wide distribution network, while the official distribution still has full control over the contents. This addresses two security problems:

The packages aren't typically downloaded directly from getfedora.org, but from multiple mirrors from all over the world. The mirrors aren't directly controlled by the Fedora project, and it's possible someone running a mirror could act maliciously or be compromised. (Of course, getfedora.org could be compromised, too, but having multiple mirrors multiplies the chances, and constantly monitoring them all would be impossible.)

Furthermore, some of the mirrors are used over plain HTTP (and sometimes FTP), which leaves possibility for MitM attacks.


ecdh-curve and tls cipher do not work together

You need to change the right portion of your cipher spec.
In TLS 1.2 the cipher spec contains several parts corresponding to different settings:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

The first part is obvious: this is TLS
The second part (ECDHE or DHE) defines the key exchange used: elliptic curve based diffie-hellman or "normal" RSA based diffie-hellman (it also can be omitted to disable forward secrecy, but don't do that)
The next part tells which key type the certificate uses, it can be ECDSA for an elliptic curve or RSA for an rsa key, you must pecify the right one that corresponds to your certificate key
the remaining parts after the WITH define which symmetric cypher to use once authentication and key exchange are done. In this example it uses 128bit AES in CBC mode with SHA256 for message authentication. You should use AES in GCM mode wherever possible because it does encryption and authentication in one step rather than using a separate MAC.

Using that knowledge it becomes clear that you have to use at least something like
tls-cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384


How long to re-seed /dev/urandom in a virtual machine?

I'm not an expert on the nuances between urandom and random but based on your description it would seem your test is correctly approximating the time to refill the input pool. I'm not aware of any tools that do this kind of testing.

There is a better way to reseed urandom to prevent stale state affecting the quality of the random data though, and that's to write random data in urandom.

This can be done on cloud providers using cloud-init and on VMs at boot time by running some instance metadata through a hash function and writing it to urandom. This could also be part of a configuration management solution using Chef, Ansible, Puppet, etc and pull a random seed from your local machine.

Note that this doesn't increase the overall entropy count, it just sets a fresher seed. From man 4 random

  Writing to /dev/random or /dev/urandom will update the entropy pool
         with the data written, but this will not result in a higher entropy
         count.  This means that it will impact the contents read from both
         files, but it will not make reads from /dev/random faster.


OAuth2 Authorization and Resource Server security check

When acting as an authorization server (AS) that handles OAuth 2.0, i think two major security features of the library you should check are:

Preventing access token leaking by restricting the redirect URL. In the implicit flow, the AS receives an authorization grant from a client it can not trust. In order not to give away access tokens to anybody, the library should allow you to specify a (white-)list of URLs for every connecting client. In the penetration test, you should check whether you can use a URL in the redirect_url that doesn't match one of the URLs in the whitelist (that would be a fail).
Preventing Cross-Site Request Forgery and/or Session Fixation with the state parameter. The state parameter is a random value, generated by the client. The parameter will then always be included in subsequent communication with the AS. It allows the client to validate that the access token it receives corresponds to the preceeding authorization request. Without this parameter, an attacker could inject his own access token, and therefore grant access to resources that the attacker controls. The end-user would then e.g. publish his data on the attacker's account. So for the penetration test, you should check whether the library properly validates the state parameter, or if you can alter the value.

Oh, and I almost forgot: OAuth 2.0 clearly specifies that it relies on secure SSL/TLS transport. So if you're not exclusively servicing your AS over HTTPS, that's a big #FAIL in the penetration test report.

The initial OAuth 2.0 specification RFC 6749, section 10 already contains lots of security considerations. Moreover, there's an additional RFC dedicated to OAuth 2.0 security:  https://tools.ietf.org/html/rfc6819

Another great resource that sums everything up can be found here: http://www.oauthsecurity.com/


Why is the reuse of the Elliptic curve Diffie–Hellman (ECDH) public server param considered bad?

Note: I'm deliberately ignoring the difference between regular DH and elliptic curve DH. Doesn't matter here.
Just poor phrasing.
"public server param" vs. "Ephemeral DH parameters" vs. "dhparam"
I think this is just poor phrasing/terminology. SSL Labs uses the definition as per RFC to basically tell you "Yo, i received the same pubkey twice! This shouldn't happen!"
SSL Labs uses the terms DH public server param (Ys) and ECDH public server param for this.
And this only makes sense if you know that they're referring to the RFC definition of what makes up the "parameters" and not to the openssl definition of what makes up "dhparams".
RFC definition
As per the TLS 1.2 RFC the params are defined like so:
struct {
    opaque dh_p<1..2^16-1>;
    opaque dh_g<1..2^16-1>;
    opaque dh_Ys<1..2^16-1>;
} ServerDHParams;     /* Ephemeral DH parameters */

So they DO INCLUDE the pubkey (dh_Ys).
OpenSSL definition
But this conflicts with OpenSSL use of the term params which DOES NOT include the pubkey:
$ openssl dhparam 123 -noout -text
Generating DH parameters, 123 bit long safe prime, generator 2
This is going to take a long time
......+..++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*
    DH Parameters: (123 bit)
        prime:
            04:f4:19:58:a6:2c:ad:1f:4f:b8:a9:b9:fd:3d:ea:
            1b
        generator: 2 (0x2)

Only the prime and the generator are including. No PubKey.
Further reading:

An earlier answer of mine.

(Read part below only if you're bored.)

Long and rambling Sidenote
Sloppy openssl documentation.
The openssl documentation for ephemeral DH seems to have been contaminated from the openssl documentation for ephemeral RSA. eRSA is a thing of the past and no longer supported but it did the same thing that we now use ephemeral DH/ECDH for.
So what does that have to do with DH/ECDH? Well, the documentation for SSL_OP_SINGLE_DH_USE reads like this:

SSL_OP_SINGLE_DH_USE
Always create a new key when using temporary/ephemeral DH parameters [...]

But wait a minute! According to the usual openssl terminology the KEY is the ephemeral part of the parameter/key combo. So why do they even use a term such as temporary/ephemeral DH parameters. -- Well, I think they just copied that from the documentation for the (now dead and buried) eRSA.
So while THIS made sense to say for eRSA:
/* Generating a key on the fly is very costly, so use what is there */
if (rsa_1024)
    rsa_tmp=rsa_1024;

It does NOT make sense to copy that to the documentation for eDH:
/* Generating a key on the fly is very costly, so use what is there */
setup_dh_parameters_like_above();

This is copied verbatim from the old eRSA example. And in the DH context this does NOT make sense. What is costly is not so much to regenerate the DH-KEY but regenerate the DH-GROUP.
Edit 2017-07-23Sun: Removed wrong "you can share your modulus, no problem" statement.


If there are no algorithms in common, the connection will fail.

The RFCs specify "mandatory-to-implement" algorithms which should result in the two sides always having something in common, but those are updated by newer RFCs, up to the point that previously "mandatory-to-implement" become "must-not-support". This is because IPSec is an old standard. So if one side is much older than the other, they can have zero algorithms in common.

Current RFC 8221 says "ENCR_AES_GCM_16" is required. That is a good algorithm. You should make sure you can use that.

If you can't use that then use ENCR_CHACHA20_POLY1305, and if you can't use that then use ENCR_AES_CBC with AH with AUTH_HMAC_SHA2_512_256 (or any HMAC, I guess). Avoid 3DES. CCM is ok, but slower than GCM and is probably only for slow devices with a hardware AES engine, not laptops which can go GCM or phones which can do ChaCha.


keys.openpgp.org keyserver fails to send confirmation mail to an Outlook-address

From my experience it is not unusual for Microsoft Mail services (Hotmail, Outlook) to accept mails but then silently drop these if they look suspicious without any information to the sender or recipient. I don't think there is much you can do, except using a different mail provider.


I'm a White Hat and I develop my own viruses. Should I report it when almost all scanners say the executable is safe?

That's a pointless exercise.

Most malware scanners match on fragments of binary code (aka virus signatures), and they check MD5 hashes of known infected code against their blacklists.  Unless the virus you wrote has been deployed into the wild and is already on their blacklist, there isn't a chance they'll have your code's exact signatures on file.

The scanners that do trigger a match are most likely those using heuristics, which scan for "suspicious" behavior.  For example, very few programs legitimately need to request the OS grant them the privilege to "Act as a debugger", yet that's fairly common behavior in malware, so if they find it they'll flag it.

Reporting your custom viruses to McAfee won't help anyone - not McAfee, not the public.  If they don't identify your code as a virus, it's because their scanners don't have very effective heuristics (which they already know, and won't learn from your code among the hundreds of viruses they analyze per day.) And developing a match takes a researcher time and effort, which costs McAfee money.  There is no value to McAfee to waste money on researching a virus that nobody can get, and adding it to their blacklists, because as a white hat you won't allow it to be released.


Is there a way to customize the authentication mechanism on an Android Device?

If you build your custom version of Android (so called mod), the answer is yes. AOSP includes all the code for lock screen, and you are free to replace it, or modify it as you like.


Different strategies for online anonymity and their +/-s?

Strategies to stay anonymous online:

Use Tor.  I highly recommend using Tor and Torbutton (Tor kindly provides integrated distributions of all the software you need to use Tor).  Tor protects your anonymity while browsing the web and helps prevent the end site from learning your IP address.  See the Tor web site for more.

You might want to use one of the distributions that provides Tor on a LiveCD; every time you need to go online, boot from the LiveCD and use the Internet.  Using a LiveCD helps ensure that nothing is stored permanently on your computer, thus better preserving your anonymity in case your computer should be seized or inspected by the enemy.  Using your browser's private browsing feature also provides similar benefits (it does not hide your identity from web sites, but it reduces the amount of information stored on your computer).  Using a LiveCD is probably more reliable; for best protection, use both measures.

Do note that Tor only protects your web browsing, not your other use of the Internet.  For instance, it doesn't protect your anonymity while you read email.
Alternatively, use a VPN.  Alternatively, you could buy private VPN access from a reputable third-party source who will protect your anonymity.  This way, your Internet access is routed through the third party.  However, this is more dangerous, because the third party still knows your identity and is able to reveal it if they choose or if they are required to by law.

If you use a VPN, select one that is in a different jurisdiction and that you judge is unlikely to reveal your identity.
Never enter your real information online. Perhaps this is obvious, but don't enter in anything that may reveal your identity online.  If asked for your personal details when signing up for a web site, lie.
Take extra caution with email. Somewhat different strategies are needed to use email securely.  Using Tor and a webmail provider may be sufficient to read email with a reasonable degree of anonymity, if all you want to do is receive email and read it over the web.  However, if you want to send email, that's may not be enough.  One option is to look into use of anonymous remailers.
Take extra caution if you register a domain name. If you want to set up a site of your own, you might be tempted to register your own domain.  Be careful.  Domain name registrars collect a lot of information, and reveal a lot of information in WHOIS records.  If you register a domain name, register it anonymous.

The above methods may be enough to provide a reasonable degree of anonymity.  However, if your life depends upon staying anonymous, I'm not sure they are strong enough to rely upon, so be cautious.

Additional resources: EFF's tutorial for defending yourself online in authoritarian regimes.


Best way to keep cell day to day phone calls private - is VOIP better?

To be clear, this question is not concerned with surveillance by the NSA or other government authorities.

If you are just dealing with the average hacker than listening to normal calls is not a problem. Communication within the mobile network are encrypted and although the encryption is weak enough for government it is still strong enough for the average hacker.

But note that the not-so-average hacker can obtain or build stingray like devices and thus intercept and decrypt the communication.

  Or does simply owning a smartphone create more problems than it solves?

Given the amount of information the applications on the smartphone collect about you for monetizing it might be better for the average user to stick with a dumb phone than to use a smart phone. This is at least true for the Android phones where a large part of the phones has known vulnerabilities and some of these are  actively exploited. It might be different for the more closed and more tightly updated iPhone but malware is known there too.

The situation might be different for a not-so-average user who is able to harden the phone and make it do only the things the user actually needs or for the user buying pre-hardened phones. In this case better encryption found in various messaging and phone application might actually provide more security than the usual encryption of mobile communication. It still leaves the problem what information are available for the hacker by simply stealing the phone. These data are usually only protected by weak authentication, i.e. fingerprints which can be faked, pattern  are often not that hard to find out too and passwords can often be guessed or are known by should surfing.


Are Facebook, Yahoo, Google, etc. hackable?

My answer might be a little less Paranoid Parrot than ThinkerThinker's, although I have to agree on some points. These companies invest a lot in security, they also have a lot of security installed. It would be quite embarrassing if anyone could just walk up to them and hack into their database. So the reason you don't find anything about in on google is either:

It's very secure and near to impossible (nothing is impossible, but it's not something you do with a simple howto guide)
Even if it happened, why would Facebook even publish it? It's bad publicity.

Spreading a keylogger and just waiting for it to return useful information is easier than trying to hack a facebook database. Plus it generates more passwords for more platforms (paypal,hotmail,gmail,tumblr,...) for one person.

There will always people be trying to get into your system, they use automated scripts. If an open my auth.log I get this from the past 3 minutes (I know I should change the ssh port, but I'm not the one that can decide that):

Apr  1 09:02:14 jugo sshd[15626]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.191.36.89
Apr  1 09:02:20 jugo sshd[15659]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.191.36.89
Apr  1 09:02:24 jugo sshd[15661]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.191.36.89
Apr  1 09:02:29 jugo sshd[15664]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.191.36.89
Apr  1 09:05:33 jugo sshd[16424]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=217.170.184.53  user=root
Apr  1 09:05:35 jugo sshd[16427]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=217.170.184.53  user=root
Apr  1 09:05:38 jugo sshd[16429]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=217.170.184.53  user=root
Apr  1 09:05:40 jugo sshd[16431]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=217.170.184.53  user=root
Apr  1 09:05:43 jugo sshd[16433]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=217.170.184.53  user=root

They just try automatically to get into a system with some random passwords and users. In the end there will be a few servers they can get into.

Measures you can take to prevent these attacks:

make your code secure
white list instead of blacklist
least privileged principle
Use of firewalls, IDS and IPS.

They also hire penetration testers and security analysts to test their systems and go look for mistakes or problems. It's not impossible, but not it's very hard. There were companies people were able to get into that were published. You only need to have a look at all the companies Lulzsec was able to get into. But remember these guys are highly skilled.


Intercepting video in real time with arp spoofing

ARP spoofing only allows the redirection of traffic through your device. Netflix claims to have been using HTTPS secured video streams. This creates a secure connection between the user and Netflix of which ARP spoofing does nothing but simply redirect traffic through your machine on a LAN. It cannot decrypt the traffic, unless the traffic is WPA2 encrypted in which case you and all users on the LAN have the key, unless it is Enterprise. But decrypying the WPA2 still leaves HTTPS. HTTPS encrypts the HTTP data that goes by, thus you cannot see their actual video. Netflix stated they would add SSL back in April

It is possible however to use tools such as SSLStrip , or its variants to trick the user into not using SSL. If it is successful you CAN view their video. There are other sorts of SSL MiTM  attacks such as SSL interception proxys, where you trick the user into installing your SSL certificate as a CA in which you can make them think any site is secure. Then you can view all HTTP traffic as you have the decryption keys. You can turn your ARP spoofing machine into an SSL interception proxy.


Using a hard to guess name is in no way a proper method to prevent search engine indexing.  While it may sometimes work, it is the least reliable and effective way to do it.

You should instead use the officially supported method which is placing a robots.txt file in your web root detailing which files and directories should be indexed.  This is supported by all major search engines including Google, Bing, Yahoo, AOL, etc.

The syntax is pretty straight-forward.  A simple example to prevent indexing the private directory is:

User-agent: *
Disallow: /private/

See the relevant Wikipedia page on robots.txt for more details.

Note that private documents should not be accessible directly either way.  Your website should use some form of authentication system to control what the user may access and private information or documents should not be accessible from inside the web root.


Is it dangerous to serve user-uploaded Flash (SWF) files?

Older versions of flash .swf's contain vulnerabiltiies. A user could upload a clip created with an older version of Flash CS and thus expose hundreds of end users. If they don't have the latest flash player (and many don't), they could catch a nasty bug.

The .swf could be triggered to launch a cross-site injection that deploys an IFRAME within the user's browser window. Then it's game over. This blog post explains how it happens.
http://blog.sucuri.net/2014/11/malicious-injector-in-swf-adobe-flash-file.html

Yup. The actionscript contained within the .swf could launch a javascript housed on another website and cause someone to get a virus just by visiting yours.

None of the AV's in 2014 detected the badware. As a former Flash developer, I have since moved to Canvas HTML5/ jQuery as it works in mobile. See this example. It is fully compliant http://careerbuildermedia.com/atx/projects/portillos/pjb/code6/

In older browsers such as IE8 it fallsback to the equivalent flash player. The expertise to do this is high, but if you really want to support swf uploads you need a moderating process to remove the ones that aren't up to spec.


Tools helps: First time cracking passwords

As far as jail time goes, as long as your contract is effective and has protection, you can be pretty safe in many countries. In the UK we do a lot of this sort of thing- mostly password strength audits. I'm not going to give legal advice, but your legal counsel should know the wording required in a contract for this. In the UK we use Hold Harmless terms, and restriction of liability so that if we break something while accessing computer systems we aren't held liable.

Technically, if you know the password strength requirements, you will know what sort of table or brute force you need to work with. For example if your minimum length requirement is 8 chars, start your brute force at 8 chars.

If you have already covered off brute force and dictionary attacks, a rainbow table maybe your only option. As @rook says, there are a few free places you can get them. The most common, though, are paid tables or table exchange, where you create a new table in exchange for the total set so far.


openvas omp tool is not able to parse target option


Understanding SSL Cipher suite in Apache

Yes, the order of Apache's SSLCipherSuite indicates the preferred order.  To quote the link you've provided (emphasis mine),

  Now where this becomes interesting is that these can be put together
  to specify the order and ciphers you wish to use

During the TLS handshake, the client presents its cipher suite, and then the server will select the appropriate cipher to use, as dictated by the SSLHonorCipherOrder.  If off (the default), then the server will consider each cipher in Server suite order and use the first cipher which is also present in the Client suite.  If on, then the server will consider each cipher in the Client suite order and use the first cipher which is also present in the Server suite.  (Thanks to @steffen-ullrich for correcting me on that detail).

Because SSLCipherSuite accepts aliases that map to more than one cipher (e.g., "HIGH", "MEDIUM", "!MD5") you can see the actual server cipher order that results from the SSLCipherSuite string using openssl ciphers:

$ openssl ciphers 'RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5'
RC4-SHA:AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DH-DSS-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DH-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DH-RSA-AES256-SHA256:DH-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DH-RSA-AES256-SHA:DH-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DH-RSA-CAMELLIA256-SHA:DH-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DH-DSS-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DH-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DH-RSA-AES128-SHA256:DH-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DH-RSA-AES128-SHA:DH-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:DH-RSA-CAMELLIA128-SHA:DH-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:CAMELLIA128-SHA:PSK-AES128-CBC-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DH-RSA-SEED-SHA:DH-DSS-SEED-SHA:SEED-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:PSK-RC4-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DH-RSA-DES-CBC3-SHA:DH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA


Combining HTTP smuggling & Trace HTTP method

You are talking about forging  redirect response. There are several problems with that:

forging a response means an HTTP Response splitting issue, but here the 1.5 query hijacking trick is an HTTP Request splitting issue
even if you were able to send a 302 redirect response to the user, this response would not contain the user credentials, and when following the redirection the victim's browser would not send the first website credentials.

But having a backend with TRACE enable may still be used in HTTP smuggling. That would be a quite complex attack, where a lot of things could fail, but that's maybe something you can reach in a lab.

The goal

we have TRACE available on the backend, so we want to force the victim HTTP query to be a TRACE query (implying building the first line of the HTTP query with a TRACE request and adding the real victim query to that unterminated query).
TRACE will echo the victim credentials (cookies) in the Response body
We want to see the response body (that's the very hard thing, as by default the response goes to the victim, not to the attacker)

Problems

Using the classical 1.5 query attack, where the Reverse Proxy thinks there's only one query, and the backend thinks there is 1.5 queries is already something quite hard:

you need to have a response from the backend for the first query in the pipeline (If you take Apache, for example, you will never get this first response until the pipeline is complete). This way the reverse proxy can believe everything is done and can reuse the tcp/ip connection with the victim query.
you need to have a connection reused between the Reverse Proxy and the Backend (so a keepalive connection or a tcp/ip sockets spool)
All this already means several exploits were used (to hide the 0.5 query from the reverse proxy, like with an hidden header, and quite certainly another to trick the backend in revealing this header and interpret the body as another unterminated query). It also means the attacker is quite certainly running a long loop of strange queries hoping to capture one of the victim query sometime (and that's a blind attack).

I made a video on this sort of attacks, the first example on this demo is a 1.5 query attack, and you can see that's a blind loop, but the victim is enforced in running a delete-user query on the application.

The result is only hijacking the user credential for the 0.5 query (so you decide for the user what is the query running on the backend), but the response goes to the victim, and he will see that the wrong query was done. You do not have the user credentials, you just have control on the victim queries. You do not even have the victim responses.

To exploit a TRACE query we need to get the hijacked query response...

So we need to add another smuggling problems, with shifting of the response stream. If we can add a shift in the order of backend response to the Reverse Proxy then the *trace response containg the credentials in the body** may not reach the victim. It may reach anybody, so maybe also the attacker.

Shifting responses

So how to shift response? That's the kind of attacks used in cache poisoning models.

Here it would be sending 2.5 queries, not 1.5. The reverse proxy would still think that's only 1 query.

         [Attacker]                     [Proxy]              [End Server]
             |                            |                        |
             >----req. A[+Req.B+Req.C]--->|                        |
             |                            >-req. A[+B+C]---------->|
             |                            |                        |
             |                            |<----- resp. A----------<
             |<---------- resp. A---------<                        |
             |                            |                        |
             |                            |      [*X*]\-req. B --->|
             |                            |                        |
             |                           [?1]<--- resp. B----------<
             |                            |                        |
 [Victim]    |                            |      [*X*]\-req. C --->|
     |       |                            | (pending partial req.) |
     >------------------- req. Victim --->|                        |
     |                                    |                        |
     |<------------------ resp. B-------<[?2]                      |
     |                                    |                        |
                                         [?3]>-req. Victim--->[+ending req C]
       [Someone]                          |                        |
           |                              |                        |
           >----req. D------------------->|                        |
           |                             [?4]<- resp.C[TRACE BODY]-<
           |<--- resp. C[TRACE BODY]-----[?5]                      |
           |                             [?6]>------ req.D ------->|
           |                              | (...) <--- resp.D------<

Ok, that's a big mess, shifting responses is always a big mess.

req B and req C are hidden from the reverse proxy (same attack as the classical one but you hide one complete and one incomplete response)
req C is a TRACE query, unterminated (unterminated header)
[?1],[?2] and [?3] may need to appear in a very strict and different order ([?1] after [?3], so [?3]-[?1]-[?2]), and that's tricky.
same thing for [?4],[?5] and [?6], [?6]-[?4]-[?5] has more chances of succeeding
if you have a way to control the timing of request B (slow query), you may succeed for [?3],[?1],[?2]. That's harder for [?4],[?5] and [?6]
socket buffering poisoning issues may help you avoiding these timing issues. The reverse proxy would store the response and reuse it on the next query (not checking that the socket already had a response before adding a request in it).
you have to hope the [Someone] will be the attacker, the attack is running on a loop so this may effectively happen (but it also means req. D is in fact req. A[+Req.B+Req.C].
there's more than one way to fail this sort of attack. That's really very theoretical.
who's still running Trace enabled backends? I known you can enforce it in Apache, but Apache cannot be the backend in this attack, has incomplete pipelines does not send early responses (so no resp. A and no resp. B).

Just for fun, same schema with [?3]-[?1]-[?2] and [?6]-[?4]-[?5] :

         [Attacker]                     [Proxy]              [End Server]
             |                            |                        |
             >----req. A[+Req.B+Req.C]--->|                        |
             |                            >-req. A[+B+C]---------->|
             |                            |                        |
             |                            |<----- resp. A----------<
             |<---------- resp. A---------<                        |
             |                            |                        |
             |                            |      [*X*]\-req. B --->|
 [Victim]                                 |                        |
     |                                    |                        |
     >------------------- req. Victim --->|                        |
     |                                    |                        |
     |                                    |                        |
     |                                   [?3]>-req. Victim--->[+ending req C]
     |                                   [?1]<--- resp. B----------<
     |                                    |      [*X*]\-req. C --->|
     |                                    |  (filled with victime) |
     |<------------------ resp. B-------<[?2]                      |
                                          |                        |
       [Someone]                          |                        |
           |                              |                        |
           >----req. D------------------->|                        |
           |                             [?6]>------ req.D ------->|
           |                             [?4]<- resp.C[TRACE BODY]-<
           |<--- resp. C[TRACE BODY]-----[?5]                      |
           |                              | (...) <--- resp.D------<


Erasing Lastpass Preminum from mobile phone

Another thing you can do is to remove it from "Trusted devices". You can achieve this with the following steps:

Login to LastPass
View your vault
Click on Account Settings (near the bottom left of the screen)
Click the third tab in the popup window named "Trusted Devices"
Disable or Delete the broken phone


Bitlocker - does it use hardware acceleration such as AES-NI?

Bitlocker started offering encryption offloading from Windows 8.

However, it offloads to the drive. That means that your drive has to support the appropriate standards. Few do. The link below refers to a question about Surface Pro 4's but the answers show more detail including the limitations and requirements for offloading encryption to SSD.

Not Able to Enable Hardware Based Bitlocker Encryption On Surface Pro 4 (Windows 10 Pro)

TCG Protocols and IEEE 1667 appear to be requirements. Samsung EVO 840/850 or Crucial m500 are listed as having SSD's that meet the requirements. Lenovo are listed has having configuration options (SKU's).


The Wikipedia page has mathematics but also an example which may or may not be enlightening: if you can ask a database for the sum of values of a column for rows 1 to n, then doing the request for n-1 and for n allows you to rebuild the information about the row n. Thus, allowing the query "sum of all values for the first n rows" and returning the exact result can be abused into learning exact information for each row.

Differential privacy is the mathematical concept by which how much (or how little) a database preserves anonymity (i.e. avoid issues like the one above) is measured. Adding random noise is a method to achieve (hopefully) some given level of differential privacy. This is not the only possible method, but at least it is relatively simple to implement, and we can compute how much it protects anonymity, i.e., in the mathematical formalism, what is the achieved value of "ε" in the expression "the database ensures ε-differential privacy".

Adding noise is a trade-off: it gives some privacy at the expense of usability, since the returned values are "noisy", thus imprecise. If you want more privacy you must degrade the quality of the database answers. Research on differential privacy concentrates on finding new algorithms for returning more accurate answers to statistical queries while better protecting privacy. Such novel algorithms are heavy in mathematics.


When and Why does Chrome display malware detection warning?

This is Google SafeBrowsing. Google keeps a blacklist database of what sites are known or suspected of hosting malware and provides APIs for browsers to check the list.

  Safe Browsing is a service provided by Google that enables applications to check URLs against Google's constantly updated lists of suspected phishing and malware pages.


Bit 0 of the first octet, 0D in this case, indicates single device or group. It's analagous to multicast at the IP level. If the first octet is odd, as in 0D, it indicates group.

If your application needs to send to multiple devices, it sends to a goup address.

It does not make any sense to originate from a group address.

This would be a poorly configured packet generator on your local network.

As to what it's trying to accomplish, I'm not sure. From the IP addresses, I'm guessing this is probably a VM based lab you're using.


HTTPS over UDP is secure. This is because the security of HTTPS doesn't use any of the properties of TCP except that it is a transport layer. Just like UDP, TCP is easy to spoof and manipulate. TCP is only to make things more reliable, not more secure. With UDP, packets can be doubled, missed or sent in the wrong order. TLS is a means to fix these issues. TLS works on UDP instead of TCP. But then those issues would make the encryption more likely to break on one side, and the connection would fail.
If you start to add error correction and other features to higher protocols like TLS, you basically re-build TCP, which is bad as then you have to maintain (and build) your own TCP stack with all the problems this introduces.
The UDP connections you are observing are most likely not SPDY, as SPDY uses TCP for transport.


What tools are there to inspect Flash SWF files?

From what I have been using:
here http://www.swftools.org/ is a set of tools for work with SWF files, can be used for data structure analysis. Another one is a tool from HP specifically for scanning vulnerabilities in Flash: http://www.hp.com/go/swfscan (requires registration).

Tools that I have not used:
Flare: http://www.nowrap.de/flare.html - there are also links to other tools, and Swfmill http://swfmill.org/ - tool to convert SWF to XML.


With CTR mode, IVs do not have to be unpredictable or random. However, they must be unique for a given key -- reusing an IV is a fatal flaw for CTR mode. It's perfectly fine for the IV to just be i (padded out to the appropriate length); it's even fine for you to call up your mortal enemy and ask them what IV you should use for your message, provided that you check that you haven't previously used the IV; as long as you check that, there is nothing that they can do to compromise your encryption. And given that, you need more than "high probability" -- you need virtual certainty (for GCM, NIST specifies a 2^-32 probability that you ever reuse key and IV, and allowing even that is because that's acceptably unlikely and lets you get away with some randomness). A decent way would be to have the first 32 bits be unique to the sequence of messages (say, a counter value for the sequence), and the next 32 be an index of the message within the sequence, also being a counter value.

Note: This assumes that your IV is only part of the nonces that you encrypt to create a keystream. For instance, a common way to build a keystream is to concatenate a 64-bit counter to a 64-bit IV; in that case, a simple counter for the IV is sufficient. If your implementation takes a 128-bit IV, then it probably computes the keystream as E(k,IV)||E(k,IV+1)||E(k,IV+2)||..., in which case you cannot just increment the IV by one each sequence: that would make message 2's keystream E(k,IV+1)||E(k,IV+2).... If you ever encrypt the same thing with the same key to build two different keystreams, that's bad. With GCM, a typical IV is 96 bits, and you just need to ensure that you don't repeat the 96-bit IVs for any two messages. The point is that if your messages can be up to b bytes long, the first 128-16b bits of your IV should be unique between all messages. 96 bits is common, as is 64 bits.

That said, there's a separate problem -- you have no authentication on your system. That means an attacker who knows what part of a message says can change it to say whatever they want, as long as whatever they want is the same length as the part of the message they know. CTR, like all stream ciphers, is particularly easy to do this with. An AEAD mode like GCM or CCM or EAX is better in almost all cases -- it protects your messages from active attacks. I believe GCM has the same IV requirements as CTR (i.e. used once, but other than that no requirements), and plenty of good implementations are available. (With GCM, IVs are generally 96 bits).


What attacks, if any, are possible against Security Support Provider Interface (SSPI)?

Recently, there are no new attacks, vulnerabilities or exploits but in 2010 and 2007 there were some exploits related to SSPI.

CVE-2010-0161: The nsAuthSSPI::Unwrap function in extensions/auth/nsAuthSSPI.cpp in Mozilla Thunderbird before 2.0.0.24 and SeaMonkey before 1.1.19 on Windows Vista, Windows Server 2008 R2, and Windows 7 allows remote SMTP, IMAP, and POP servers to cause a denial of service (heap memory corruption and application crash) or possibly execute arbitrary code via crafted data in a session that uses SSPI.

CVE-2007-2108: Unspecified vulnerability in the Core RDBMS component in Oracle Database 9.0.1.5, 9.2.0.8, 10.1.0.5, and 10.2.0.2 on Windows allows remote attackers to have an unknown impact, aka DB01. NOTE: as of 20070424, Oracle has not disputed reliable claims that this issue occurs because the NTLM SSPI AcceptSecurityContext function grants privileges based on the username provided even though all users are authenticated as Guest, which allows remote attackers to gain privileges.


I worked at antivirus industry 12 years ago, so I'll try to explain, but it is possible that my knowledge is a bit outdated.

Each serious antivirus vendor has antivirus lab, whose work is split to:

detect new viruses and develop solutions for them: signatures, behavioral patterns for heuristic detection, specialized detection code, sometimes cleaning code etc.
identify new crypters and archive types, and develop code to decrypt original files

Both of these activities include infiltrating several forums and sites hidden from general public.

Better antivirus vendors, like ESET, Kaspersky, BitDefender etc., recognize and deal with hundreds (or today maybe even more) of crypters and archives, so from user perspective, most crypters are transparent and not affecting detection rate.

However there are also less serious antivirus vendors in the market, which recognize less crypters. So if you want maximum security, you should generally choose products from vendors that recently achieved VB100 award.


It all depends on the technical saavy of your roommates, their desire to crack your passwords and/or find another way to log and then decipher your internet traffic, and then them taking the time to do so.

In the real world, the general answer to "can someone hack this?" is yes, it can be hacked.  What needs to be asked in tandem with that question, is what would they gain by doing so.

Your best bet in this situation, assuming there is no malice between you and your roommates, is to just be proactive in your security measures.  Use a strong pass-phrase, as a single password really doesn't cut it anymore.  Do not use the same pass-phrase for every account you use, which is a pain in the rear, but if someone breaks one password/phrase they will try it on other known accounts.

Don't use the same pass-phrase in perpetuity.  Also, turn off systems ability to save passwords/login information on websites.  If someone gains physical access to a device, worrying about what is going through the wire/wireless becomes a moot point.