OWASP ZAP bruteforce by password not username I want to bruteforce a login page using OWASP ZAP, using two separate passwords (90 lines) and username (200 lines) files, with the bruteforce POST requests to be ordered by password like:

user001:pass00
user002:pass00
....
user200:pass00
user001:pass01
user002:pass01
etc.

Fuzzing with wordlists is working with ZAP but I can't get this specific ordering happening, ZAP is trying all the passwords by each user name instead.

I've tried changing option Fuzzer: Options: Length / Breadth first but that has no effect.
My assumption is that ZAP is iterating through the payloads by the order that the POST parameters appear, but I am not able to edit the actual POST request in the Fuzzer to reorder them.
Additionally, once the Fuzzer is started, I can only pause or stop it but cannot reconfigure it.
Any insight into this would be appreciated.

tl;dr -- Use ZAP to find the username and password parameters, and then Hydra with the -u switch to brute force logins, iterating through users instead of passwords as you asked.

EDIT: you can also use Burp Intruder using Cluster Bomb to cycle through. Works pretty well but not quite as fast as Hydra if memory serves correctly. There may be a similar feature in ZAP but I'm not as familiar. See the last Attack Type on Burp's site here.

Detail --

I would use THC Hydra with the '-u' switch. The tool is very simple and accomplishes what you're looking at by default. It comes pre-installed on Kali, and you can install the package on most Unix-based systems.

From the Hydra man page, the -u switch will "loop around users, not passwords". This will try pass01 for all 200 users before trying pass02 for each user. Here is a sample of what your command should look like:

hydra www.target-url.com http-form-post -L usernames.txt -P passwords.txt "/path/to/login:username=^USER^&password=^PASS^:Incorrect Login" -u -V -o hydra_output.txt

Breakdown: "hydra" is the name of the program. "www.target-url.com" is the address of the target, but you can alternatively use an IP (and specify a port). "Http-form-post" is the service you are trying to brute force. "-L" and "-P" are pretty self-explanatory, they are your login username and password files.

The next portion in the double quotes has 3 parameters you can capture with the ZAP proxy or by viewing the source code, and they are separated by the ":". First is the path, followed by a colon and the username and password parameters identified by ZAP (I like Burp, but ZAP will do the trick). Hydra will replace the "^USER^" and "^PASS^" strings with the values from your user/pass files.

Finally, the -u, as said before, will iterate through usernames, rather than passwords. "-V" will show you every password guess in stdout so you can verify it's working as it should, and -o will output the successful password guesses to the hydra_output.txt file.

I hope this helped. I am not super familiar with ZAP, but the free edition of Burp Suite is a counterpart product as far as I know, and Burp Intruder should have the functionality you desire if you must use a proxy.


Is there any sense in using two-step authentication for personal email address? There is two-step authentication available at gmail and outlook as well. There are some using it, but the majority doesn't. In what cases it is recommended? If I have a strong password what are the chances of abuse?

YES!  There is absolutely sense in using two-factor authentication for personal email!  Your personal email is the absolutely most precious account you own!

Almost every website's "forgot password" feature will kindly send an email containing a reset link to your inbox if you forget your password.

Once an attacker has access to your email, they can access pretty much any account you have just by using the "forgot password" feature on any website you're registered with under that email address.

Does your bank send you statements via email?  Perfect!  The attacker even knows which bank website to go to to get your info.  Other creditors?  Same thing.

Even if your password is strong, you have no way of knowing how it's protected on the server. Suppose they're storing it in plain text, or in an easily decrypted format, and they get breached (repeatedly).  Or someone breaks in and steals their hard drives with your data.  The strength of your password means squat in these scenarios.

As others have noted, passwords are ultimately a "broken technology".  Given the high value of your personal email - the fact that losing it can expose ALL your accounts and the broken nature of the whole username/password paradigm, using two-factor authentication is (IMO) a must.

More here: http://www.codinghorror.com/blog/2012/04/make-your-email-hacker-proof.html


For untrusted user upload sites: what should the contents of crossdomain.xml and clientaccesspolicy.xml be? Flash has a long history of ignoring MIME types of files and reading the file directly for executable content or for cross domain execution permissions.  That means a malicious user can take advantage of this to create XSS flaws on the same domain as my other secured services.

Since I will not be serving flash from my site, and the presence of a flash document in the same domain will cause a security risk, I want to block all Flash-initiated XSS actions.

What is the recommended content of crossdomain.xml or clientaccess.xml?

With regard to Flash issues, every site that doesn't use Flash should use one of the two files at the root of the web server named crossdomain.xml.  This will prevent XSS via that plugin

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
 "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">

<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd">
  <site-control permitted-cross-domain-policies="master-only"/>
</cross-domain-policy>

The "Master Only" directive prevents any other file from being read, even if they have the correct content type.  The MIME type of this file should be text/x-cross-domain-policy


Why does Amazon verify a TLS certificate? Show site information, then Connection for https://support.mozilla.org indicates  Verified by: Amazon

Why is this? Is Amazon spying on me?

https://support.mozilla.org's certificate is signed by the Amazon Certificate Authority, Amazon Trust Services. This is widely considered a trustworthy third party for signing certificates, and your browser is apparently configured to trust certificates signed by Amazon Trust Services without prompting you.

There are many Certificate Authorities in the world, which sign certificates for individual web sites. There is no single universal authority that validates websites; each browser picks a set of CAs that they will trust by default, but you can configure trust, sometimes for the browser specifically and sometimes for your operating system as a whole. (It depends on the browser and OS in question.)

In theory, a rogue CA can issue fraudulent certificates and do things like spy on you. Any CA could do that, not just Amazon. In practice, CAs are trusted precisely because they are trustworthy. It is unlikely that they would abuse that trust, but it is not impossible. For example, when Symantec had issues with their security, browser vendors stopped trusting certificates signed by Symantec.


Forcefully revoking any used permissions by apps on Android by (hot reloading firmware)? There is a recent malware called MalLocker that hijacks and occupies the full screen size by using SYSTEM_ALERT_WINDOW permission. It poses as ransomware by looking as such but doesn't encrypt files.

"The notification was intended to be used for system alerts
or errors, but Android threats misused it to force the
attacker-controlled UI to fully occupy the screen, blocking access to
the device. Attackers create this scenario to persuade users to pay
the ransom so they can gain back access to the device," - Microsoft

Is there a way to forcefully withdraw any ongoing permissions used by Android apps (and preserving current state of the device)?

I think that the adb command can be useful here, but it is likely that debugging mode needs to be enabled on the android device, which requires the device to be in developer mode.
To troubleshoot:

How can debugging mode be enabled without expressly enabling it in the GUI?
Would it be useful to connect the infected device to a terminal while being in debugging mode, or can't a android device infect a PC this way up?
If adb can be used, and the permission in context is revoked then how will this affect the unwanted overlay screen? Will the app just break or will it stay since it used the permission already?

Note: my last question is very practical, for this reason I just want to now how this affects running apps in general.

User authorised permissions can be revoked from device settings. SYSTEM_ALERT_WINDOW is shown as Draw over other apps in device settings which is known for infamous chat head bubble in facebook messenger. Because of its potential abuse by malvertising apps,

Google started restricting the areas in which overlays can draw back in Android Oreo, and they’ve completely removed access to the API for Android Q (Go Edition.) The biggest problem with SYSTEM_ALERT_WINDOW is that, despite the fact that users are supposed to manually grant the permission through a special permission management screen, the Google Play Store automatically grants access to the permission upon installation. In Android Q, access to the SYSTEM_ALERT_WINDOW permission is transient: side-loaded apps only have access to the permission for 30 seconds and apps installed via Google Play have access to the permission until a device reboot.

But in a future Android release, SYSTEM_ALERT_WINDOW will be fully deprecated, and all Android apps using it will have to transition over to the new Bubbles API introduced in Android Q. [1]

MalLocker is exploiting this design problem that prevents user to reach device settings to uninstall the malware or revoke its permission. No other permissions can block user from exiting/switching/uninstalling/force stopping a malicious app. adb is only available from developer settings. However, some OEMs allow adb from recovery mode. Once a permission is revoked, either app crashes for unhandled exception or reprompt user to allow permission again.
An infected android device can infect other connected devices but that largely depends on the type of intrusion. A malware with root access on android device can change the device identity. It can show PC that it is a LAN device instead of MTP or it's a keyboard. It's no different than badUSB attack once the malware controls firmware of the device. Whereas a malvertising app with no exploitative features is harmless. Every app runs inside of ART sandbox except adb daemon (adbd). Theoretically, a vulnerability in adbd and adb sdk can be used by unprivileged apps to deliver payload in PC but this setup will require chain of high severity vulnerabilities to work.

[1] Bubbles in Android Q will fully replace the overlay API in a future Android version


Attack tree file format? Wikipedia lists five software packages for creating/editing/analysing attack trees.

These software packages do not seem to have settled, between them, upon an agreed file format for attack trees. This lack of standardisation means that interoperability between these programs is low. It also potentially discourages the community from investing effort into creating a library of attack trees for common scenarios: after all, why invest the effort if only the users of program X, rather than the whole community, would be able to benefit?

My question: has there ever been a serious effort to create a standard file format for interchanging attack trees and associated metadata? If so, when, and by whom?

There were discussions of placing attack trees 1, 2 in existing SGML derivatives 3 that describe system architecture or govern security modules, but nothing like unanimity appears to have been reached.

The issues include

The complexity in which attacks relate to individual architectural components and
That the nodes described in Schreier's tree proposal don't directly correlate with elements of authorization and authentication markups.

Some academic approaches of interest treat attacks as anti-goals in a goal tree 4.

Most important to the development of attack model formalization is that attack relationships do not frequently form trees.  Although attack relationships can always be represented by graphs (nodes connected by edges), attack categorization often requires multiple parental relationships to comprehensively represent the conceptual realities of security.

The removal of the single parent restriction of a tree allows the attributes of nodes and edges to contain what vendors are now calling metadata, which is a misnomer.  The metadata of these modelling formats does not always describe overarching qualities of the attack tree.

CySeMeL may not catch on as an acronym, but The Royal Institute of Technology has approached the relationships without the single parent restriction, calling the modelling language as a graph tool 5.  Such could lead to a more lasting and adaptable standard.

The automated generation of attack trees is being investigated by IEEE authors 6, and the ACM has interest in this same direction.  Either may later lead to standardization.

Another direction is to piggyback UML with a security model diagram 7.

It appears that the upstream academic work is still as varied as the product array available to architects, system administrators, security teams, and managers.  Inter-operable products may be further down the road, but if other standards that appeal to narrow audiences are any indication, import export menu items and converters may be the first emergence of at least partially inter-operable semantics.

[1] Early reference to attack trees in Dr. Dobbs Journal at https://www.schneier.com/academic/archives/1999/12/attack_trees.html.

[2] Later development from Bruse Schneier on Attack Trees http://tnlandforms.us/cs494-cns01/attacktrees.pdf

[3] Generating attacks in SysML activity diagrams by detecting attack; by Samir OuchaniEmail authorGabriele Lenzini; DOI: 10.1007/s12652-015-0269-8

[4] Design of a Modelling Language for Information System Security Risk Management, by Nicolas Mayer, Patrick Heymans (Member IEEE), and Raimundas Matulevičius.

[5] A Manual for the Cyber Security Modeling Language; by Hannes Holm, Mathias Ekstedt, Teodor Sommestad, Matus Korman; Department of Industrial Information and Control Systems, Royal Institute of Technology, 100 44 Stockholm, Sweden; http://www.kth.se/polopoly_fs/1.433836!/Menu/general/column-content/attachment/cysemol_manual_short.pdf.

[6] Automated Generation of Attack Trees; Roberto Vigo, Flemming Nielson, and Hanne Riis Nielson; Department of Applied Mathematics and Computer Science; Technical University of Denmark; 2014;  http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6957121

[7] SecureUML: A UML-Based Modeling Language for Model-Driven Security?; Torsten Lodderstedt, David Basin, and Jürgen Doser; Institute for Computer Science, University of Freiburg, Germany; {tolo,basin,doser}@informatik.uni-freiburg.de


certificate based network authentication In certificate based network authentication, is the user tied to just the system the certificate has been installed on such that if he tries to authenticate using another system access is denied?

When authentication uses a certificate, the important element is the private key: the mathematical object which corresponds to the public key (the one which is in the certificate). When a certificate is "installed on a system", this means that the private key is stored somewhere within that system. The authentication protocol implies usage of the private key: the key owner demonstrates that he has access to the private key, by doing some cryptography with it, which can be verified by using the public key in the certificate.

If the same (human) user tries to do the same thing from another computer where his private key is not, then he won't succeed and authentication will fail.

However, in some types of computer systems, and in particular the Microsoft / Active Directory world, the user's private key can be stored in the user's "profile", which means in some files which really are in the AD server and travel with him. The user opening a session on any computer in the network will find his certificate and private key as part of his profile, and thus will be able to use the private key for certificate-based authentication from any computer on the network.

Similarly, still with AD, authentication (as in "session was opened") on one machine can hop from machine to machine through the magic of Kerberos, even if certificates were somehow involved at some point.


PCI Definition of "user" PCI version 3 section 5.3 states

  Ensure that anti-virus mechanisms are actively running and cannot be
  disabled or altered by users, unless specifically authorized by
  management on a case-by-case basis for a limited time period.

Is there a definition in PCI of "users"?  Or is that left for us to define in our security policy?

Strictly speaking everyone who interacts with the system is a "user" but some users will also be administrators with the ability to change the group policy for the anti-virus system.

Actively running anti-virus mechanisms in a centralized environment should and can be configured as a domain policy or AV centralized policy so that no user can alter them, including users with administrative privileges on their own stations. A good AV policy can also completely control the firewall settings of the client stations.

Only the authorized by management personnel (the administrators of the anti-virus systems) should be able to alter such a policy (and only they can do it in a proper setup environment).

So the term 'users' refers to anyone except those designated anti-virus administrators.


Is Diffie–Hellman key exchange protocol vulnerable to man in the middle attack? Diffie–Hellman key exchange protocol vulnerable to man in the middle attack? If yes, then what type of MITM is that? I believe that is a replay attack or a relay attack, not sure though.

It is vulnerable in one version. Just to be more clear, the three basic versions of Diffie-Hellman are:

Anonymous DH, where Alice and Bob simply send each other unsigned values;
Fixed DH (sometimes simply called DH);
Ephemeral DH (see below).

Anonymous DH is easily vulnerable to a MitM attack, as follows.

Alice generates a value X, Bob generates Y, Eve generates Z.

Alice sends g^X mod p. Eve intercepts the message and changes it with g^Z (her own random value) mod p, before sending it to Bob.

Bob now thinks Alice has sent him g^Z mod p, as there is no signature nor any other authentication mechanism.

Bob sends g^Y mod p. Eve intercepts the message, changes it with g^Z mod p and sends it to Alice.

Alice now computes (g^Z mod p)^X mod p.

Bob now computes (g^Z mod p)^Y mod p.

Eve computes (g^X mod p)^Z mod p, which is her secret with Alice, and (g^Y mod p)^Z mod p, which is her secret with Bob.

Alice encrypts "I love you" with (g^X mod p)^Z mod p.

That key has been agreed with Eve, so Eve can decrypt the message, change it to "I hate you" and re-encrypt it with her secret with Bob. In other words, Eve can act as a proxy by having agreed on a different key with Alice and Bob.

This can be avoided by using Fixed DH - where g^X and g^Y are signed by a trusted CA - or, even better, Ephemeral DH.

In Ephemeral DH (DHE) X, Y are changed every time, i.e. at each session. They are also signed, in order to prevent MitM. However, because they always change, and the signature changes with the signed message, how can the other party verify the authenticity of the signature?

The DHE solution is simple: use a certificate. If Alice can sign her own g^X with a private key and prove that the corresponding public key is associated to her, via a certificate, Bob can verify the certificate and, by doing so, verify Alice's identity and therefore the authenticity of her g^X.

Therefore, DHE works like this.

Alice previously obtains by some trusted Certification Authority (CA) saying "Name: Alice, PublicKey: PKAlice. Signed by CA".

More formally, the certificate is Cert_Alice=(Alice, PKAlice)_CA, which means that it contains the public key of Alice PKAlice and is signed by the CA.

The same is done by Bob, which obtains a similar certificate.

Alice generates X and computes g^X mod p.
Alice then sends two messages to Bob, M1=(g^X mod p, PKAlice)_Alice (signed by Alice) and M2=Cert_Alice.
Bob verifies that M2 has been really signed by the trusted CA (by using the known PKCA to see if the signed message matches the signature), and that it really belongs to Alice.
If M2 has passed the previous tests, it means that it has been sent by Alice (unless someone has stolen Alice's private key and the certificate is still valid). At this point, Bob uses the certified PKAlice, which was inside M2, to verify the signature of M1. If everything is OK, Bob stores g^X mod p.
Bob generates Y and computes g^Y mod p.
Bob then sends two messages to Alice, M3=(g^Y mod p, PKBob)_Bob (signed by Bob) and M4=Cert_Bob.
Alice checks the validity of M4 (see 4).
If M4 has been completely verified, Alice uses the certified PKBob, which was inside M4, to verify the signature of M3. If everything is OK, Alice stores g^Y mod p.
Alice and Bob separately compute (g^Y mod p)^X mod p==(g^X mod p)^Y mod p.

At each new session, restart from 2.

Of course, using signed messages after the DH exchange would allow to immediately detect that something weird has happened, but there's nothing in anonymous DH itself that prevents MitM attacks.


Signing session cookies The Play Framework for Scala has support for signed session cookies. In the application configuration file is an "application secret" that is set as a secure random number when the application source code is initialized. This secret is shared between multiple copies of the application running in a web server farm so that all cookie signatures can be checked on any server.

When a session is created in Play, the session is automatically signed using the application secret and HMAC-SHA1.

I am concerned that the same application secret is used for the life of the application. Is this concern valid?

I was trying to come up with a better way to sign the cookies, but I know the adage against inventing your own cryptographic techniques.

Is there some accepted way to have all of the servers share a changing secret?

I thought of the following (note that all session cookies are in-memory only and expire when the browser is closed):

Embed the signature date (UTC) in each cookie.
The signing key is randomly generated by the first signing of the day (after midnight) and stored in the database for all servers to share.
When a server needs to sign a cookie, it checks its own signing key and the date it was generated and compares that date to the current date.

If the signing date is the same as the current date, the key is used to sign the cookie.
If the signing date is older than the current date, the server checks the database for a new signing key with the current date.

If there exists a key with the current date in the database, it is used for signing the new cookie. Old signing keys are retained (for some number of days) to verify older cookies.
If there is no key for the current date, a new one is generated (how do I handle multiple servers doing this at the same time in a NoSQL database?).

As an alternative algorithm, I can generate a new secret each day using HMAC(application secret, current date). With this, I do not need to store the daily secret keys in the database, since all servers can generate the same daily key sequence. I'm not sure if this is any more (or less) secure than storing the daily key in the database. I do need to protect the application secret, but no more so than I need to protect the database. It is recommended that the application secret not be stored in source control, but loaded from an environment variable set on each production server.

Insisting on frequent key renewal is an old tradition but is not mandatory. In older times, when cryptography was something for armies and spies, keys had to be renewed because spies were spied and soldiers were made prisoners in the course of their daily operations; it was thus unreasonable to believe that a secret value known to field agents could remain indefinitely secret. Thus came the habit of regular (and frequent) key renewals. This does not map well to Internet servers, for the following reasons:

Actual intrusions on your servers are rare events. The normal situation is that none occurs. You still want to use detection mechanisms, but you can expect that, on average, no intrusion occurs for months at a time.
When an intrusion occurs, the attacker enacts his main mischief immediately. This is a computer world; within the 10 seconds following the intrusion, the attacker has installed his rootkit, downloaded all the data which he is interested in, modified some records, and left. A daily renewal of keys will "kick him out" (i.e. make obsolete all fake cookies that the attacker could come up with using the stolen key) only long after the damage has been done. The key renewal dogma has been enshrined at a time when the average processing of data was a matter of days or weeks, not seconds. The time scale has changed a lot since these days.

Therefore I would say that a long-lived MAC key is not a crucial problem. Of course, you should mind all the details on how that key is generated, stored and shared between your servers; it is an important secret element with a high value for the attacker. However, renewal is mostly pointless, and can be dangerous, since it impacts the way the key is stored and shared. With a fixed, static key, you can store the key as an OS-protected file on each server, and shared with a one-time manual procedure under controlled conditions (e.g. before the servers are actually put online). If you want to renew keys automatically on a daily basis, then you will need some shared storage or network protocol, which inherently increases the exposure of that secret value. For instance, if you use some database scheme to generate and share the key-of-the-day, then the key can become an easy prey to a SQL injection attack, whereas a simple file would have remained confidential.

For these reasons, I recommend that you abstain from key renewal. It makes the problem much more complex to analyse, with higher exposure, for a gain which is, at best of times, highly questionable.

(Note: This "signature" is more correctly named a MAC. The term "signature" is, in cryptography, reserved for algorithms of the asymmetric persuasion, e.g. RSA, whereas HMAC is part of "symmetric cryptography", meaning here that the same key is used to generate the MAC value and to verify it.)


metasploit openvas plugin not connecting to OpenVAS9-Manager I recently installed openvas9 following this guide.
I can log into the web interface on port 4000 just fine, and I ran a scan on my metasploitable VM for testing, and it seems good. Now I wanted to import the results into metasploit.

The issue is that the service openvas-manager to which the openvas plugin of metasploit connects does use a unix-socket file instead of a listening port.
If I run sudo openvasmd --port=9390 -a 127.0.0.1 -f, then msf connects just fine to that instance.
I want to add the listening address and port in addition to the unix socket.

In the file /etc/init.d/openvas-manager, which manages the service, you will see that

it includes a file with parameters
and then uses the variables from that file as arguments.

# Read configuration variable file if it is present
[ -r /etc/default/$DESC ] && . /etc/default/$DESC

# Update DAEMON_ARGS with optional settings from /etc/default
[ -n "$LISTEN_ADDRESS" ] && DAEMON_ARGS="$DAEMON_ARGS --listen=$LISTEN_ADDRESS"
[ -n "$PORT_NUMBER" ] && DAEMON_ARGS="$DAEMON_ARGS --port=$PORT_NUMBER"

So in order to start the service with the listening ports active you must simply have a look at /etc/defaults/openvas-manager

There you can simply uncomment the lines for "LISTEN_ADDRESS" and "PORT_NUMBER" and set the values to your desires.

# Defaults for OpenVAS Manager initscript
# sourced by /etc/init.d/openvas-manager
# installed at /etc/default/openvas-manager by the maintainer scripts

# For more information see `man openvasmd`

# To set listening address:
#
LISTEN_ADDRESS="127.0.0.1"

# To set listening port number:
#
PORT_NUMBER=9390

Then simply restart the service.


Why there is no SMS verification on transactions with USA debit/credit bank cards? People talk about making pins stronger, making the card manufacturing techniques stronger. But, in Russia when you want to open a debit card, for example, the banks ask you to assign your phone number by default so every online transaction would require SMS verification.

I have read that in America, there is no SMS verifications on cards, so it is really easy for hackers to steal a card number and then find a proxy and just go and shop the hell out of the card. Why is there no mandatory rule on phone assigning to the card?

A different solution is being deployed in the US for both debit and credit which mirrors to a certain degree a solution that has been in place for much of the EU. Credit and debit cards include a chip that is inserted into a card reader, generating a single-use payment credential that, if intercepted, generally cannot be reused.

Why this system and not another? Historical dynamics and inertia. The US has long had a system where the card, or card + PIN, functioned as a bearer credential. To introduce a new model where the user has to actively verify transactions using a second factor like SMS would require cooperation on the part of retailers, card brands, banks, cell network providers, not to mention users.

Of course there have long been card brands that on exceptional transactions would ask for the customer to call them, or will call themselves, to confirm. But this is the exception, far from the rule. The thing is that as much as it makes the news, fraud is simply not that common in the US, even under the card swipe system. It impacts no more than a single digit fraction of transactions.


Is scrubbing a ssd drive effective in situations where you can't use the trim command? I have a luks encrypted external usb ssd drive (Samsung T3) which is unable to use the trim command. This leaves me to search for a different way to securely erase the free space inside the encrypted ssd drive.

With photorec I was able to succesfully recover a lot of pictures and files even though I used scrub to write random data and zeros to the ssd drive.

This leaves me to the question: Is scrubbing effective in deleting free space on a ssd drive? I'm not concerned with the drive degrading in any way, shape or form.

After more intensive scrubbing with the command line scrub tool (scrub -X -p schneier test which does 7 passes) I could recover only 1/10th of what I could recover before. So I guess it does have effect.


Information Security on a lost android phone Recently, my android mobile phone was lost/stolen. I had logged into several applications such as Facebook, Paytm, etc. Thus, there are chances that my personal/ transaction details might be leaked.

I tried Google Timeline & Android Device Manager. It shows data about the last connection to the internet was before it was lost. I believe it may have been:

Switched off, Or
Not connect to the network, Or even worse
Phone is factory-reset.

I've no tracking software installed separately except for ADM.

What options do I have for remote security and tracking my device?

The only way to "remotely secure" your phone is to track it with ADM.

If you can't track the phone, while you are 100% sure you have ADM on and installed there is a chance that it has been reset. This also means they've wiped most of the installed apps and accounts. So they should not have access to your accounts connected to the apps.

But in case they didn't factory-reset your phone, your info would still be on the phone. If this is the case I would recommend you to change your passwords of all the know apps you used.


This certificate has an invalid digital signature I am trying to learn securing wcf service using ssl. I found this website and I am following the steps. http://robbincremers.me/2011/12/27/wcf-transport-security-and-client-certificate-authentication-with-self-signed-certificates/. But when came to creating certificate step I had an issue. Using below to create a certificate.

makecert –pe –n “CN=localhost” –sr localmachine –ss my –sky exchange

By default, the makecert utility creates certificates whose root authority is "Root Agency".  For some reason, my Root Agency cert has become corrupted (invalid digital signature).  How can I restore a valid Root Agency cert?

The site says when I create a certificate using above statement and double click on it I should see this

But I am seeing this:

So even If I add Root Agency to trusted root certificate authority it doesn't make any sense.

Other screenshot from my guide site:

And I have

How can I fix "This certificate has an invalid digital signature" issue?

This could be due to the length restrictions on certificate keys.

Microsoft enforced a minimum key length limit of 1024 bits in August 2012. Check that your self signed cert is created with a key length of at least 1024 bits.

For more info you can check out this blog post What does the “This certificate has an invalid digital signature.” message actually mean?

You can specify the key length when creating the cert with by using the -len parameter like so:

makecert -pe -ss MY -$ individual -n "CN=your name here" -len 2048 -r


How is compiling a program from source more secure? When downloading compiled binaries for programs it is very important to check GPG signatures, Authenticode, hashes, etc.

However, I often see people who say that compiling the code from source is the most secure way.

If they have read and understood every single line of code, then I can see how this would be the case.

However, for projects like Chromium or the Linux Kernel, I highly doubt that anybody in the world has read every single line. Even if they did read every single line, a backdoor can be as small as one character, so they'd better have read it damn accurately.

Is compiling from source really more secure than downloading the unverified binaries?

It's harder to hide a backdoor in source code than in a binary. Someone could easily add a bunch of code before compiling a binary, but leave the extra code unpublished. If you build it yourself, then you can be fairly confident (outside of a compromised compiler, or network commands in the makefile) that the code you downloaded actually reflects what is in the binary.

In theory, at some point in time every line of code in Chromium, Linux, Firefox, etc. has been looked at by at least one person. Furthermore someone definitely looks at every change made. If the source code was ever non-malicious, it would be difficult to make it malicious.

I doubt very much that someone has disassembled the binary executable and matched up the assembly to the source code. It would be comparably easy to add malicious behavior to a distributed binary file with nobody being the wiser, especially if builds are not reproducible.


Which one will give me the best VPN security when choosing Encryption algorithm in pfsense? I want to setup an VPN server in pfsense and I can choose a lot of Encryption algorithm types ,alot!!
What I have read is that the AES 256 (512 is not an option) is the best. Well even then there are a couple of option this is what I can choose from:

CBC
CFB
CFB1
CFB8
OFB

I did find this answer https://stackoverflow.com/questions/1220751/how-to-choose-an-aes-encryption-mode-cbc-ecb-ctr-ocb-cfb, but it did not include all options and there are some critic comments on the answer. Of course there is an wikipedia page: http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation , but that does not give me an clear answer on what is the most secure and gives a lot of extra info I do not understand.

Question 1: Is AES 256 the most  secure algorithm?

Question 2: If 1 is true then which one of the above list is the most secure?

Many thanks and any thought about this is appreciated!!

AES-256 is the most secure publicly known algorithm. It is however probable, that there exist more secure algorithms in the military use.
From the above list, OFB will be the most secure and also the least CPU intensive.

Here you have some explanation about these modes:

http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation


Is it a good approach to deploy a honeypot behind the firewall I am using a linux box as a firewall and router. I would install a system running honeypots like kippo, dionaea or glastopf behind it. My honeypot is on private IP and all required ports are being redirected from the public IP of (iptables) the firewall towards private IP of the honeypots machine.

Is this a good approach for deploying a honeypot? I noticed that behind firewall, dioanea capture less malware as compared to on public IP

The architecture that you're suggesting would allow you to capture potentially malicious traffic directed at services running on the ports that you forward from the public IP address.

If that's your goal then it seems a reasonable approach.  One suggestion, depending on how much you trust the honeypot software, would be to isolate the honeypot machines in their own logical network, such that if an attacker breaks out of them, they have more difficulty in attacking other systems in your environment.

The primary difference I can see between that approach and placing the honeypots "outside" the firewall is that you wouldn't need to maintain firewall rules to allow traffic to them and also if they're compromised there is likely less risk to the other areas of your network.


How to hide dns requests from ISP? I am using google image a lot. I discovered through Wireshark, any images under preview mode of google images search result actually expose the dns where that image was hosted from.

For example, my url bar shows that image was https://image.google.com/xxxxcxc

But the leak dns revealed that image was directly from www.example.com

So it gives my ISP an impression I was visiting example.com instead of google.com

What should I do to avoid these dns exposures from happening?

I am using iOS by the way.

Regular DNS traffic over port 53 is plaintext so any requests made will be visible to your ISP (For more background on DNS, check out the RFCs, start with 883 and then go to 7626 "DNS Privacy Considerations")

Therefore, in order to prevent eavesdropping between your client and the DNS service you would need to either use a secure-DNS extension or tunnel your regular DNS traffic through a VPN or proxy. However, if you are using your ISPs DNS servers than this is a moot point.

Depending on your circumstance you may want to use a VPN for all traffic or you may want to consider using something like Tor or a simple web based HTTP privacy proxy like AnonyMouse. However, if you are worried about DNS requests you might not want your ISP seeing you use privacy services.

Some options include:

DNS Over TLS (RFC 7858) - e.g., DNSPrivacy.orgs's Stubby (check out this Medium article)
DNSCrypt (as suggested by @David)

Note: DNSSEC does not provide confidentiality:

  DNSSEC does not provide confidentiality of data; in particular, all DNSSEC responses are authenticated but not encrypted.

Also consider, that if you have prefetch (see also) (predictive loading) enabled your browser will load the page and do more than the DNS lookups. You may want to disable this and due some research on the best secure browser configuration and addons to meet your needs.

If you are worried about inappropriate content you are not expecting, try enabling Safe Search.

More reading:

https://dyn.com/blog/an-abridged-guide-to-security-in-dns/


Why must I register a new phone for 2FA services? The number is the same, isn't that enough? I have a smartphone and I use 2FA to log in to several services - bank, github, world of warcraft, etc.

If I were ever to lose/destroy my phone without making prior arrangements for account recovery it would be, at a minimum, a major hassle to get my new phone linked to my 2FA accounts.

And that's if the service even allows it -- i believe github's policy is if you use 2FA and lose your phone, and you haven't previously downloaded a list of emergency account recovery codes, you're screwed.

Why is it this way?  If I get a new phone and the number is the same, why isn't that enough?

First, there are actually multiple ways how 2FA might work, the maybe simplest way is to receive a SMS with an access code form your service during each of your logins. While this is a bit less secure because it could be intercepted, this way you should not be required to update your 2FA settings if you switch your phone while keeping your SIM.
Another way how 2FA could work is by installing a token generator on your phone, an app from your service provider. For instance, a Time-based One-Time Password generator. The point here is that your phone can generate a token at anytime even without network access.
Since such a generator works the same on all phones and is a deterministic algorithm, some code or key on your phone is required to verify it was indeed generate on your phone. If the app would use some thing like your calling number everyone knowing it, might generate a valid code for your account. Also serial numbers of your SIM or hardware have similar flaws. So a better way is to have a random key only available on your specific phone and in some sort at your service (for verification). Btw this usually makes not only losing your phone an issue but also deleting just your generator app.
However, such a key means that changing your phone necessarily means that you would have a different installation of that app on your new phone with a new key (or non). And for security reason, your old key shouldn't be available to any syncing service, so there rather should be no mean to copy it over.
Reason why the recovering of your account is that complicated, is that it is by definition a way to by-pass the 2FA. That means if there were an easy way for your to recover it, there is also an easy way for the bad guys to get access to your account while you are using 2FA. By entirely denying this (like Github), it guarantees for your that once you enabled 2FA there is hardly a way for others to by-pass it.


What is the real advantage of using a "more secure" algorithm like bcrypt for password hashing? I read this article about password hashing using bcrypt as the recommended method. The advice is similar to what they're saying on hacker news about not using something like SHA2+salt. There are other answers on the infosec StackExchange about why we shouldn't use something like SHA-256. The generally accepted knowledge is:

  SHA2 is fast, which is bad (bcrypt is purposefully slow so that we can get around Moore's law)

As you know, if we use bcrypt, we to hash something with a cryptographically random salt, we might get this string: $2a$13$ZyprE5MRw2Q3WpNOGZWGbeG7ADUre1Q8QO.uUUtcbqloU0yvzavOm, and the salt is contained in that string.

My question is a bit multifaceted:

If an attacker gains access to the database with write access, they could just re-write someone's password in the table with their own hash and login to that user's account, right? Unless that's not their specific objective (for example, maybe they don't want anyone to know that they accessed the database). Or if they have read-only access, I guess that's a different story.
Aside from the fact that bcrypt is purposefully slow, is there any other advantage to storing the salt in the same hash as the password as opposed to having both user.hash and user.salt in one record if I didn't use bcrypt? Or in that case is it generally best practice to store hashes and salts in separate tables/databases (then presenting the disadvantage of multiple table/database lookups as mentioned in one of the comments)?

We also get the issue that bcrypt presents minor (yes, within the milliseconds range) performance issues (purposefully) when performing lookups, which is negligible in most cases, but it seems the only protection we really get from bcrypt is making it difficult to batch process an entire user table and covertly log into users' accounts (or sell their information, or whatever). Why not just use something like SHA2+salt then?

Gaining read-only access is a much more likely scenario than write access - after all, read access to an old backup or test server somewhere is nearly as good as read access to the real server. (since people don't change their passwords often enough)

Also though, one account nearly anywhere (unless you're a banking site) isn't that valuable. Hundreds of thousands of accounts, though - now you're talking. And while a single db write might go unnoticed, thousands of anomalous db writes - especially with every person whose account was written to now being unable to log in - generally will get noticed. Furthermore, cracking your user's password gets access to everywhere that user has used that id/password combination, which is likely to include sites more valuable than yours.

As for your record storage scheme, the main reason to store the output of your password hashing function in one blob that the rest of the database doesn't interpret (as opposed to separate salt and hash fields) is that you don't want to encode your hashing algorithm into your database. What if tomorrow you wanted to change to PBKDF2, or scrypt, or in fact bcrypt? Better to let an existing vetted password hashing function do the interpretation than to tie yourself to hash functions that fit the format of your current salt + commodity hash method. Instead, if you just have a field for algorithm and another field that is just "string to pass to the algorithm along with a password to see whether the password is good" (you might call this field hash or saltNhash), then you can even upgrade users transparently as they log in.

As an aside, salted SHA2 is acceptable password security if you're standing up a web service in 1995. Twenty years on, use bcrypt or something even better. Salted commodity hashes (such as MD5, or the SHA* family) are vulnerable to cheap GPU-based attacks, to the point where rainbow tables aren't economically efficient any more - it's cheaper to just run the dictionary attack as needed than to keep around a giant table that's trivially defeated by salting anyway.

Password hashing is something other people have already worked out in detail for you. You wouldn't write your own crypto or your own video compression algorithm; don't make the mistake of ignoring the good solution in front of you in exchange for years of discovering subtle corner cases people have already designed for.


Infected Drupal 6 website page with a php shell I have a server with Drupal 6 which was hacked and now by accessing the main page i can see the php shell. The problem is that i could not find the shell. The site files are not infected because i copied all website data on another server and it works and no files has been changed in the last week.. It might be the httpd which got pawned? if so how can i see because the logs didn't offer any clues or info.
I found that the php shell is called FilesMan but i cannot find it in any file using the command:
 grep '((eval.*(base64_decode|gzinflate|\$_))|\$[0O]{4,}|FilesMan|JGF1dGhfc|IIIl|die\(PHP_OS|posix_getpwuid|Array\(base64_decode|document\.write\("\\u00|sh(3(ll|11)))' . -lroE --include=*.php*

I see a strange file in /tmp called trolled...the content of the file can be downloaded from here

Your server itself (not Drupal) was compromised by a local Linux (root) exploit. Although Drupal may have aided in getting the exploit onto your machine, your machine was exploited with CVE-2013-2094, the "semtex.c exploit"

$ md5 fileshare.ro_trolled
MD5 (fileshare.ro_trolled) = ff1e9d1fc459dd83333fd94dbe36229a

$ strings fileshare.ro_trolled | grep -i @fu
sd@fucksheep.org 2010

Cleaning Drupal will do nothing for you, me expanding on what the exploit does would be reinventing the wheel, you can read about what the exploit does (has since been ported to perf) here

My suggestion is starting from scratch with a clean install. The only mechanism to ensure nothing else is backdoored (top, netstat, etc) would be to have been running Tripwire or something similar, where you can go back and compare checksums to trusted sources.


New DDos Attack on WordPress website Recently I saw something new (at least for me) in log file [% tools.ua.random() %] as below:

199.246.2.10 - - [21/Aug/2014:13:25:15 +0545] "POST /wp-login.php HTTP/1.1" 200 2809 "http://mywebsite.com/wp-login.php" "[% tools.ua.random() %]"
64.34.173.227 - - [21/Aug/2014:13:25:32 +0545] "POST /wp-login.php HTTP/1.1" 200 2809 "http://mywebsite.com/wp-login.php" "[% tools.ua.random() %]"
91.109.3.166 - - [21/Aug/2014:13:25:32 +0545] "POST /wp-login.php HTTP/1.1" 200 2809 "http://mywebsite.com/wp-login.php" "[% tools.ua.random() %]"

If someone has seen similar kind of log can anybody explain me what is this and how to stop it, may be by applying some rule in modsec. I think it is some kind of software used for ddos attack. I found this in web.

I think it is a poorly written robot. [% tools.ua.random() %] looks like a template that should pick a random user agent. But it does not substitute the value (the UA).
It must be a bad bot hiding behind various user agents.

To mitigate some attack against WordPress please take a look at my plugin:
https://github.com/szepeviktor/wordpress-plugin-construction/tree/master/wordpress-fail2ban
The plugin analyses the HTTP request line-by-line.

Use the "must use" (mu-plugin) version, that is the up-to-date one. I hope you understand commented PHP code. I would gladly help you to set this up. It even works without the fail2ban daemon (running on a Linux server) but it is designed to immediately block bads bot through fail2ban.


Can the government really break into an iPhone through physical code overwrite? I am currently doing some research into the Apple vs FBI controversy.

During my research, I found a Edward Snowden comment that claimed that the government can actually override a phone's data, specifically an iPhone, through physical means, as long as they can take apart the phone and use the data chips inside.

I have tried to find some certifiable website that supports this, but have been fruitless. Now I just want to ask, "Is this plausible?". Can the government really break into an iPhone through physical code overwrite?

Note

In the case above, the government is trying to access data inside the chips, so that they can break into a terrorist's phone. But Apple is refusing to give the government the key to accessing the data. Edward Snowden commented that they can selectively overwrite the code to that the OS will be easier to hack.

Links and Context

https://www.youtube.com/watch?v=o8pkUTav0mk

Skip to 2:55 for the specific comment and start from the start for greater context.

https://en.wikipedia.org/wiki/FBI%E2%80%93Apple_encryption_dispute

For the greater context.

Is this plausible?

Yes, it is. As pointed out in the comments, tampering with an iPhone (or an Android Phone for that matter) isn't that complicated when you have physical access to it. The problem is, you do not have access to the data is stored on the phone itself.
Plus: You can think about him what you want, but pretty much all of Snowden's allegations turned out to be true.

  Can the government really break into an iPhone through physical code overwrite?

The government (or whoever has physical access to your phone - and a bit of time) can "break into your" phone. This means components can be altered.
But what it does NOT mean is, that an adversary can then read the files/data that is stored on the phone, because they are still encrypted. They can get encrypted with the user's passcode/PIN, and this is - to my knowledge - not accessible through hardware tampering.


How do I securely store and retrieve a many-time use key? I am performing some symmetric database encryption/decryption in .net. I am using a single 256 bit private key.

(1) Where do I store this key when not in use?

(2) How do I securely retrieve this key?

(3) How do I securely use the key?

(4) What operations do I need to perform once encryption is finished to maintain security?

This answer attempts to guide you towards the ideal solution. Ideally, if an attacker can read your entire hard drive, it should still be impossible (in our lifetime) for him to get the key and data and decrypt without some additional interception. (for example a password). It is possible that this ideal solution is not feasible for your use case. More details required.

  Where do I store this key when not in use?

Encrypt the key, and store it on the hard drive.

  How do I securely retrieve this key?

Use a password to create a key that is used to asymmetrically encrypt your symmetric encryption key. This way, as long as the password is not intercepted, the symmetric key is unknown because the key has been encrypted. Further Explanation (The password can either be entered on boot, or it can be entered on login. More details needed.) Make sure that your key derivation routine is slow (100-1000ms) to make brute force sufficiently expensive.

  How do I securely use the key?

In the case of an SQL database related operation, perform the encryption in the application. Do not send the key or the unencrypted text into the SQL command, unless you are sure that there is no modify statement logging (binlogs), slow statement logging (slowlogs), likely intercepts using the show processlist command. Further Reading, Partially Relevant (my information is MySQL oriented)

Also note where you are storing the information. Some intrusions will only grant the attacker access to your SQL database, others will provide only non-root access to the filesystem, which means that UNIX permissions can be used to hide the data. Some attacks will provide read-only access, others will provide read-write, which means that the code could be changed to log the unencrypted information.

  What operations do I need to perform once encryption is finished to maintain security?

Perhaps make yourself aware of the heap dump possibility, swap reading. You should also make it a point to look on IT Security Stack Exchange regularly to expand your knowledge of security. (half joking, half serious)

It is possible that my answer is missing some important measures. I would suggest editing your question to provide more information.

You may also wish to examine how you are using the key, once it is made available. By this I mean, the encryption protocol that is used, as well as the algorithms used to create the stream encryption out of the underlying block encryption, may require examination. Further Reading

I trust the experts here will upvote me if I am right, or comment on where I am wrong.


Is it safe to use same key pair to encrypt and sign? Would it be easier to hack a private key by having multiple encrypted and/or signed messages from the same person than having only encrypted or only signed messages?

Should I use one private key to encrypt and another to sign?

It is not feasible to crack a private key when having multiple encrypted/signed messages. Note that:

According to the OpenPGP standard, when encrypting a message the public key is only used to encrypt a random session symmetric key, which is then used to encrypt the message itself.
Generating a new key pair each time would involve redistributing your public key, which is actually the weak point in Public Key Infrastructures.
If your PGP key pair is DSA/ElGamal instead of RSA you already use a different key for signing (DSA) and for encrypting (ElGamal).


nmap privilege escalation - is still a risk? There is a known and popular technique to leverage nmap for privilege escalation if the suid bit is set for nmap.

One can execute nmap in interactive mode and from there execute bash commands in the context of root.

nmap can be started in interactive mode as shown below:

nmap --interactive

However, in more recent versions of nmap, the interactive option is not available.

So, is it still possible to access the shell through nmap and execute shell commands in the context of root if the suid bit is set?

I came across this post: https://seclists.org/nmap-dev/2010/q1/1241

It states when the "--interactive" option for nmap was removed.

Note, even in the most recent version of nmap, it displays a warning message when its started and if the suid bit is set:

$ nmap -v

Starting Nmap 7.01 ( https://nmap.org ) at 2019-04-25 06:04 UTC
WARNING: Running Nmap setuid, as you are doing, is a major security risk.

Yes.

As the warning says, it's just not made to be used like that.

Note that there are many potential ways for nmap to make it do something other than network operations. From a quick glance at man page, these could do just that:

--script, which uses Lua scripts
-oN <file>, output to file (so you can overwrite something with root)


Can an SSH server fingerprint be spoofed? If I simply connect to an SSH server, get its key fingerprint, and immediately disconnect, does the SSH protocol ensure that the server also had the private key in order to get that far into the handshake?

That is, could this entire connection have been spoofed by someone pretending to be the server, but did not possess the server's private key?

No, this is not possible.  Depending on the key exchange mechanism in use, there are (slightly) different mechanisms for proving the identity of the server.  This is defined in RFC4253 where it requires "explicit server authentication."  In the case of RSA (RFC 4432), the server signs a piece of data provided by the client (actually a hash of several pieces) with its private key and sends it back to the client.  This signature proves that the server is in possession of the private key.  Without this, there would be no protection at all against MITM attacks on SSH.


Security benefits of hosting your CMS on localhost If I host the CMS for my online website on localhost, will that mean that no one online can access it? If not, what is the most secure way to store your CMS?

If your CMS is listening to 127.0.0.1 ("localhost") and not to any other IP addresses on your system, then yes, no one online will be able to access it.  You will be the only one able to access it, while logged into the computer it's running on.

It is unusual that this would be what you want, but hey, maybe you just want to use your CMS as a personal library.  If that's the case, have fun.

If your goal is to secure your CMS but still allow other people to access it, this is not an appropriate step.  If that's the case, I'd start by Googling "how to secure XXXX" where XXXX is the name of your CMS (wordpress, drupal, what-have-you).  Any major CMS will have guides describing standard security steps.


bettercap - arp spoofing I am new with bettercap, I am trying to do a simple ARP Spoof attack.
Reading the online doc, I tried with:

1) bettercap # launch bettercap '

2) set arp.spoof.targets "MYVICTIM IP" #example : 192.168.1.6

3) arp.spoof on

but this doesn't work, I can't see any of my victim's packets.
Any suggestion?

You're missing 2 key things here:

You need to enable full duplex arp spoofing (so the target thinks you're the router, the router thinks you're the target). Enter set arp.spoof.fullduplex true in bettercap for this.
You need to tell bettercap to sniff for traffic (assuming you're not using another tool). You can do this with net.sniff on, again in bettercap.

If that cuts off the internet for the target, make sure you've enabled IP forwarding (https://unix.stackexchange.com/questions/14056/what-is-kernel-ip-forwarding).


So I need to unzip and process user submitted zip files - how to do so securely? I am writing a system that accepts zipfiles from end users.

The title says it all - what precautions should I take to ensure my processing server does not get compromised when I need to unzip a completely random set of user files from a zipfile and process them?

The files will be run through some Python and other processes.

First of all, I would suggest to perform some kind of content inspection (e.g. antivirus / malware detection)

Second, I would read the files inside the ZIP file. Since you're using Python, I would suggest to have a look at: http://pymotw.com/2/zipfile/

By reading the content of the ZIP file, you could determine if the files are allowed or not (for example: .exe, .php or .asp(x) files)

Third, extract the user content to a folder where scripts like PHP / ASPX cannot be executed, preferably outside the web server's web directory.


How to prevent cheating (extra votes) in online contests? Mitigating Cheating & Voter Fraud in Online Contests…

We run online contests of various sorts that involve users voting on entries (usually one vote per user per day). The prizes range from hundreds to thousands of dollars. Over the last four years we have encountered a number of ways people try to cheat, and have implemented couter-measures in each case. As it stands, we use the following measures:

Authentication
A user must create an account and authenticate (log in). This rules out anonymous vote stuffing.

Email Confirmation
A user must confirm their email address by clicking a link in a system email to confirm they own and have access to their address. This rules out creating accounts en masse using random (not necessarily valid) email addresses. It also slows down the process a little for one account, and a lot if you're trying to create many.

No Gmail Address Aliases
Users cannot use instant alias addresses such as localpart+suffix@gmail.com. That slows down potential cheaters.

Additional Measures
We routinely audit our signups and voting rosters for strings of email addresses that come from the same private domain (user1@smithfamily.com, user2@smithfamily.com, etc.). We also look for similar names, usernames, and "local-parts" of email addresses across domains.

We also show voting result updates on a daily basis, so there's no instant feedback. That way, if someone is trying to cheat, it will take a day to see any results, and unless they went big, they won't know for sure if their method was successful. We try to be as much of a "black box" as possible.

Needless to say, this is all exhausting and getting harder and harder to scale up. We need an easier solution to ensure that we get a lot closer to "one person, one vote" in our contests, while not burdening the user beyond need in the process.

We have explored the possibility of using SMS to attach mobile numbers to accounts in order to verify the person; the jury is still out on this approach: https://ux.stackexchange.com/questions/15980/ways-to-avoid-online-contest-voting-fraud-is-sms-account-verification-too-much/, and Can SMS text messages be used to verify a person's unique identity through a short code system?.

Some suggestions have included using credit cards, mail-in verification, reputation points … but these are all much too onerous for our target users.

What more can we do automatically in the back end to 1) identify cheaters, and more importantly 2) prevent them from even cheating?

UPDATE

We decided not to make our fraud protection leak-proof because one of the developers pointed out "the harder you make it for people to cheat, the harder it is to detect cheating." Instead, we are utilizing a medieval Chinese hunting technique called a three-sided Battue. By making it very difficult to cheat in most ways, but relatively easy to slip through in other ways, we know exactly what to look for and eliminate before the voting results are updated.

We look for patterns in votes, such as one contestant receiving a string of evenly timed votes, then look at the accounts associated with those votes. If there's a pattern to the accounts, we eliminate those accounts, and the associated votes disappear with them.

You're attempting to uniquely identify something through a system that was somewhat designed to not require a unique identity.  Short of tying and validating to a 3rd party (usually physical) identifier, this is impossible.  Instead, your best bet is to restrict voting altogether, in a manner that discourages automation and/or quick results.
If your system supports it, see about weighting the votes based on some criteria:

'Age' of the account (since signup).  Disallow votes for anything under some age (say, since the start of the contest).
Number of entries (in other contests).
Account activity (is the account visited/used regularily?) - comments in forums or on entries, etc.
Percentage of votes by user in contests since signup (may reveal 'targeted' behaviour).  Perhaps by number of different vote recipients?
Throttle votes accepted per-entry based on total votes per-contest.  Anything above a threshold gets flagged for review.

These all should be dooable from a database/reporting side, negating the need for any fancy javascript or other client-side code (which can be tricked).


Is this an insecure implementation of multi-site sessions? I have a multi-site Magento (A PHP eCommerce platform). Accounts are shared across sites, but sessions are not, so you have to log in to each site individually. I'm interested in sharing these sessions.

I found an answer on the Magento stack exchange. Sharing Sessions Between Stores with Different Domains. The recommendation is this:

cookies.php

setcookie("frontend", htmlspecialchars($_GET['SID']), time() + 86400);

example1.com

<?php $sessionId = Mage::getSingleton('core/session', array('name' => 'frontend'))->getSessionId(); ?>
<img src="https://example2.com/cookie.php?SID=<?php echo $sessionId; ?>" style="display:none;" />

I'm trying to wrap my head around the full security implications of this. If I'm not mistaken, this URL becomes all that is needed to log in as a user.

All of our sites are HTTPS only, so I think that helps prevent anyone listening in on traffic from getting this URL, correct?

One issue I might see is that if someone is at the physical computer, they would have access to that URL and could use it to login from a different computer, which would otherwise be impossible without the password. Expiring the session prevents against that though, right? If so, sessions are currently pretty long so carts stay alive longer, so how short should the sessions be?

In short, Is this an insecure implementation of multi-site login sessions? If so, can this approach be made secure?

A lot of SSO systems work this way. But there's a bit more to it than just a couple of lines of code, specifically:

use cookies for sessions with the usual httponly and secure flags
when a request for an authenticated service is received but without a valid session, redirect the user to the SSO (this needs some special handling around POST and DELETE/PUT/PATCH if used)
if a session already exists on the SSO or the user passess authentication, redirect the user back to a special landing page in the application with a token in the URL (because that's the only polite way to get data across domains)
at the landing page, establish a link back to the session, set the sesison cookie and redirect to the originally requested page (note that some older browsers ignored cookies set in a 302 response)

  HTTPS [...] helps prevent anyone listening in on traffic from getting this URL, correct?

The key word here is "helps". It doesn't prevent the URL from appearing in the history.

  so how short should the sessions be?

Trying to fix an issue of leaking the session cookie by shortening the session timeout is not the right way to go. A better approach is to have the SSO send back a single use token which the application can then use to resolve the session or authenticate access to the session, e.g. (on the SSO)

if (authenticated()) {
    $secretsid=encrypt(session_id(), SERVERSIDEPASSWORD);
    $_SESSION['otp']=uniqid();
    $return_url=add_get_arg($app_landing_url, array(
      'secretsid'=>$secrestsid,
      'OTP='=>$_SESSION['otp'],
      'original_requested_url'=>$originally_requested_url)
    );
    header("Location: $return_url");
    exit;
}

and at the landing page....

if ($_REQUEST['secreetsid']) {
    $sid=decrypt($_REQUEST['secretsid'], SERVERSIDEPASSWORD);
    if (looks_like_a_valid_session($sid)) {
          session_id($sid);
          session_start();
          if ($_SESSION['otp']==$_REQUEST['otp']) {
             unset($_SESSION['otp']);
             header("Location: $_REQUEST[original_requested_url]");
             exit;
          } else {
             // bad OTP
             log_bad_session_transfer();
             exit;
          }
    } else {
          // might be naughtiness, might be a bug
          log_bad_session_transfer();
          exit;
    }
 } else {
    // must have got here by accident - send them back to SSO
    redirect_to_sso();
    exit;
 }

An alternative way to resolve / validate the token would be to make a direct HTTP call from the landing page back to the SSO (i.e. server to server, not via the browser) and ask it to resolve the SID based on the toekn received from the browser.


Where does a Hyper-V guest get its entropy when generating a certificate authority key pair? According to findings by the EFF's SSL observatory, there are "tens of thousands of keys that offer effectively no security due to weak random number generation algorithm."  My understanding of that problem is this: During the generation the large prime factors used by the RSA algorithm, a significant number of devices ended up choosing the same prime factors.  Presumably this occurred because insufficient entropy was used by the devices to select the prime factors.
When you install Active Directory Certificate Services, you are presented with the following screen:

Ostensibly, completing the installation causes the generation of the prime factors that comprise the key pair.
I have often heard the recommendation (here's one) to create your root certificate authority as a virtual machine to ease taking it offline and physically securing it.  In a Windows Environment, it seems natural to host your root CA using Hyper-V.
This then raises the following questions:

Where does a HyperV-hosted instance of Windows Server get its entropy when generating the prime factors during AD Certificate Services installation?

How 'good' is the entropy source?

A Hyper-V guest gets its entropy just like it would if it wasn't a guest. For Windows, an application that uses Microsoft's cryptographic service providers get its entropy from three/four main sources:

External events like network activity.
Details about the callers to the CSP functions (process ID, thread ID, various timers associated with those threads and processes, etc.).
Any entropy the application developer would like to provide (key press timings, mouse movement, etc.).
Any supported hardware entropy devices, such as RdRand in Intel processors.

All four of the above are just as available to a guest as they would be if it were a physical server.

As described in msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx:

  With Microsoft CSPs, CryptGenRandom uses the same random number generator used by other security components. This allows numerous processes to contribute to a system-wide seed. CryptoAPI stores an intermediate random seed with every user. To form the seed for the random number generator, a calling application supplies bits it might have—for instance, mouse or keyboard timing input—that are then combined with both the stored seed and various system data and user data such as the process ID and thread ID, the system clock, the system time, the system counter, memory status, free disk clusters, the hashed user environment block. This result is used to seed the pseudorandom number generator (PRNG). In Windows Vista with Service Pack 1 (SP1) and later, an implementation of the AES counter-mode based PRNG specified in NIST Special Publication 800-90 is used. In Windows Vista, Windows Storage Server 2003, and Windows XP, the PRNG specified in Federal Information Processing Standard (FIPS) 186-2 is used. If an application has access to a good random source, it can fill the pbBuffer buffer with some random data before calling CryptGenRandom. The CSP then uses this data to further randomize its internal seed. It is acceptable to omit the step of initializing the pbBuffer buffer before calling CryptGenRandom.


How to protect/mitigate IntelME (CSME) JTAG attack over USB? Two security searchers from ptsecurity.com ( Maxim Goryachy @h0t_max and  Mark Ermolov @_markel___ ) have announced on Twitter:

  Game over! We (I and @_markel___ ) have obtained fully functional JTAG for Intel CSME via USB DCI. #intelme #jtag #inteldci

With this vulnerability, an attacker with physical access to the computer (USB port) can take control of Intel Management Engine (IntelME), and the whole computer.

What are the attack vectors? (Physical access to the computer required?)
What computer (and configuration) are affected?
How to protect and/or mitigate such attacks?

This attack seems to specifically target Intel CSME (IntelME/AMT). The same security researchers disclosed a similar vulnerability targeting the main CPU/firmware in April 2017 (but this setting as disabled in the UEFI/BIOS firmware by default)

The attack works by exploiting the USG JTAG debug feature found in some PCs.

Years ago, if a computer manufacturer was debugging their motherboard design, there would be a special port on the motherboard called a JTAG port to poke around registers in the processor/chipset. https://en.wikipedia.org/wiki/JTAG

To use this port, you would need a JTAG debugger device.
https://www.sparkfun.com/products/12942?gclid=Cj0KCQiA_5_QBRC9ARIsADVww16L8y1WKfZ9aiJQttvILJoygVQd1LTmss5_MiPobTO2I9NbCziFwfQaAo0cEALw_wcB

On modern motherboards, there is often no room for a JTAG port. And in the case of something like a laptop, it may not be feasible to get to the JTAG port. So, Intel developed a way to access JTAG via one of the USB ports.

One of the USB ports on the chipset (typically port 0) is a “special” USB port that allows JTAG debugging with a special USB device.
http://www2.lauterbach.com/pdf/dci_intel_user.pdf

In the BIOS settings for a PC, there would typically be an option to enable USB debugging, and this option should be disabled by default in any production systems shipped to customers. However, there are some computer manufacturers that have not followed best practices:

They turned debug on by default during HW/BIOS development and forgot to turn it off.
They hard-coded the state of USB debug in the BIOS to enabled, and did not provide and option to disable it.

If you have access to the USB debug/JTAG function, you have “better than root” access to the system. It is intended for the hardware and firmware designer to troubleshoot low-level system issues. The exploit is really about JTAG, not Management Engine. If an attacker can get to the JTAG port, they own your computer, period. Intel Management Engine is just something they can exploit while they have control.

I will also point out that USB JTAG as an attack vector isn’t exactly brand new: https://www.digitaltrends.com/computing/intel-kaby-lake-skylake-pcs-hackable-usb-jtag/

One of the fundamental laws of computer security is that if a bad guy has unrestricted physical access to your computer, it isn’t your computer anymore.  JTAG is an example of that rule.
https://msdn.microsoft.com/en-us/hh278941.aspx

So what do you do to stop this?

Don’t let a bad guy have physical access to your computer. If you suspect this has happened, stop using your computer immediately and get a new one.
Check with your manufacturer for a BIOS update.
Disable USB debug in the BIOS if you can.
If you do not have an option to disable it, contact the manufacturer of the computer/motherboard to see if they have it enabled. If they do, you have to wait for them to provide and update, or replace the computer.


What is a pen tester? I asked two pen testers what exactly it is that they do.

One of them has told me that all he ever does is try to find exploits in the software in order to gain access to internal servers and nothing more.

The other said that it is trying to find a hole in policies/social engineer the company in order to gain access to internal computers.

So does it deal with trying to gain access through company software and install malicious software yourself or by getting the people in the company to install the malicious software for you.

I did not know of existence of pen testers until this website was made, but now that I do I was interested in the field, however I can't know if I want to become a pen tester until I know what exactly it is that they do. So far as I understand is that it is pen tester's job to gain access to the company's computers. But does it involve reading byte codes and such to try to get in or does it involve exploiting people in company to get in?

Also where might I learn some principles to look into pen testing career?

I saw this answer, but it was not detailed enough for my liking.

A penetration tester's job is to demonstrate and document a flaw in security.

In a normal situation, a pen tester will perform reconnaissance to find some vulnerabilities, exploit those vulnerabilities to gain access, then possibly extract some small piece of data of value to prove that the system is not secure.

The piece of data is often a part of the sales pitch for the company looking to fix their problems.  It's one thing to see a vulnerability and ask the boss for $10,000 to upgrade the firewalls.  It's a different thing to say to the boss "look at these results, the tester was able to get at our credit card numbers, which is a million dollar liability lawsuit waiting to happen! Please give me $10,000 to upgrade the firewalls."

Note that this doesn't say which vulnerability the tester will exploit, and the tester might be free to try anything from a social engineering attack to a WiFi sniffer to a physical break-in.

However, pen testers generally must work within limits or boundaries.  Often this is at the request of the clients:  "Please demonstrate that you can or can't get inside our network, but we don't want you to send any phishing emails to our employees."  And the security company may have a policy of never installing certain types of malware.  (There's little reason for a pen-tester to install a botnet client or to hide his tracks behind a rootkit, for example, unless he's demonstrating the need to scan for botnets and rootkits.)

Some clients will place many limits on the tests, such as "just test the security of my application server."  These clients may be under the impression that a hacker will be thwarted by the magical firewalls they bought that will protect the app server from every conceivable form of external attack.  Or it could be that they have a different team focused on firewall defenses, and a third team working on social engineering awareness campaigns.  The client may also ask that the pen tester not exfiltrate the valuable data - knowledge of the holes themselves is enough for them.

Either way, the pen tester must carefully stay within the limits given, even when the tester can identify a more effective avenue of exploitation.  The pen tester is usually only reluctantly given a position of trust, because they're often viewed as "criminal hackers".  By carefully documenting and exposing every flaw they exploited, they gain trust through professionalism.  If a tester sees a flaw he is not authorized to explore, he should point it out, but not explore it unless he first obtains permission.

Also note the goal of the pen tester is not to "install malicious software".  The goal is to demonstrate the adequacy of the security guarding information of value (credit cards, trade secrets, marketing plans, server administration, etc.)  Malware is just one technique used by hackers.

For starters, I would recommend you read, practice, and learn what you can at home and on line.  Check out the Certified Ethical Hacker books and training available.  Try to attend local, regional, or national security conferences and events.  You may have local "white-hat" groups like OWASP that have meetings you can attend and people you can meet.  You may also have a more "gray-hat" DEFCON chapter nearby, again, these would be people you could learn from.  These are all people who might be able to help you get into the business, if they see an aptitude or skill in you.


Quantify security strength from entropy and lifetime Entropy or randomness is a quantitative measure of security strength for various types of passcodes, but in current times with digital technology, breaches, and cracking tools it seems that lifetime should also be a factor in determining “strength”. For example, a low entropy password with a short lifetime may be as strong as a high entropy password that is seldom replaced.

Is there a quantitative approach to determine passcode strength using both entropy and time?

As others have noted in comments, there will not be a general answer to this. There are far too many other things to take into consideration when trying to asses the lifetime of a password of some given strength.[^1]

The major things that can vary and need to be considered include

The details of the Key Derivation Function (or hashing scheme) that is used. With some schemes, tens of millions of guesses can be made per second on ordinary machines. Other schemes can grind to just a few thousand guesses per second on the same hardware.
What hardware an attacker is willing to through at the problem? Is it a high end gaming computer? Is it a rig built with 4 GPUs specifically for cracking purposes? Is it one of the $30,000 rigs that you can buy from specialist vendors. Is it a coordinated suite of such machines?
How will prices and speeds change in the future

I helped organize an (expensive) experiment to get some idea of the cost of cracking 42 bit passwords hashed with 100,000 rounds PBKDF2-H256. Our goal was to get a sense of how expensive it is to crack these, so we offered substantial prizes.

Anyway, I still haven't done a final write up of the whole thing, but you can see information in our (1Password's) discussion forum topic. The actual contest details.

Money, not time

What we found was that at the scale of this contest, it cost about 6USD to make 232 guesses for something hashed that way in 2018. Any attempts to judge about the future will involve making estimates about how rapidly the cost of the relevant computing changes over time.

Again, that exercise only tells us about the host of cracking PBKDF2-H256 100K rounds. But I do believe that trying to put things into money terms instead of in to time estimates is more useful. We deliberately make the contest hard enough so that there would be a good mix of trade-offs between fixed costs and running costs.

So while I don't think that anyone can give you an answer to your precise question, as it depends on far too many other variables that will differ in each case, I do believe that it is useful to think in terms of costs instead of in terms of time. And, with enough incentives, it is possible to get decent estimates of those costs for certain kinds of hashing/KDF mechanisms.

[^1]: I will speak informally of the "entropy (or strength) of a password", but, of course, the strength of a password is a function of the system by which it was generated.


How to find out where CNAME had resolved to in the past? Are there any tools for this?

I am doing some research into pentesting and subdomain takeovers with cloud providers like AWS and Azure. I have a list of subdomains (A records) that could be used for this, but they are indecipherable in terms of seeing where they once resolved to. Without this information, the entire thing is redundant.

For example:

sjd-3949-af3.trafficmanager.net would have originally resolved to mydomain.takeover.com but doesn't now.

Does anyone know how to find this out?

DNS does not provide historical records. So unless it's been cached somewhere public in a way that you can access it, there is no way to know what a CNAME resolved to.


AntiForgeryToken versus Captcha I am having some question regarding captcha and AntiForgeryToken

Do I need to use captcha if I am using AntiForgeryToken  in an MVC application.
Does AntiForgeryToken prevents automated form submission?
Can I use AntiForgeryToken as an alternative to captcha?

To answer a bit more explicitly:

  Do I need to use captcha if I am using AntiForgeryToken in an MVC
  application.

If automated submissions are a problem then yes.

  Does AntiForgeryToken prevents automated form submission?

No. A CSRF token basically ensures that a user visits a page (eg. the one which contains the form) before another action takes place (eg. that form was submitted). A bot could easily obtain a valid token to submit a form.

  Can I use AntiForgeryToken as an alternative to captcha?

No. Arguably a CAPTCHA might be able to replace a CSRF token but a CAPTCHA probably isn't practical on every form which needs CSRF protection (eg. one in an admin panel).


Should admin user be visible to regular users When building a system, where all users belong to the same organisation, should regular users be able to see admin users?

On one hand one could argue that there is no need for this information to be hidden. That regular users would benefit on knowing what accounts have admin privilege since they then knows who to ask for admin help. Hiding admins is only a form of unnecessary 'security by obscurity'.

On another hand one could argue that any information about admin users should be withheld. All info on admin users should follow the principle of least privilege.

How do you reason about this?

What can you do when the only information you have is a username ? You can conduct a brute-force attack in the hope of finding the password. So you should have 1) a strong password and 2) a mechanism to detect and thwart attacks. Why not add 3) 2FA is the stakes are high enough.

One possible strategy would be to have multiple levels of access rights.
For example you could have a public helpdesk user with limited rights, and another, unpublished user account (preferably not one that is predictable/easy to guess) with admin rights to work behind the scenes.

In this setup the users will always interact with the helpdesk account and never with the admin, that they don't know. Thus, even if the helpdesk user account is compromised, the damage is contained.

That means your application has to have a feature for hiding accounts somehow. I would weigh the pros and the cons. If you have to tweak an existing architecture a lot to achieve this goal, this may not be worth it.
When it comes to security, simplicity is better than complexity. That means don't break stuff to fix a mundane problem.


Comparing allegedly identical OpenPGP keys published through different channels tldr version:
When I try to compare public keys that are supposed to be for the same entity the versions I get through different channels are NOT the same and the ones that I download as a file like somekey.sig.asc are smaller files.

I'm trying to learn the whole gpg thing and practice using it correctly. A crucial step is verifying that a public key does in fact belong to the party it is supposed to. In the absence of a chain of personal contacts, the obvious thing is to get multiple copies from different sources and verify that they are identical. I never can seem to do that. I suspect that part of the problem lies in newlines, carriagereturns, spaces, tabs, and other characters invented by the SCOPTDUI (Secret Conspiracy Of Programmers To Drive Users Insane). Here is an example where I'm fairly sure the keys ARE identical, but I can't come up with a procedure to prove it.

Veracrypt team key from the MIT keyserver:
https://pgp.mit.edu/pks/lookup?op=get&search=0xEB559C7C54DDD393

Veracrypt team key from the Veracrypt site:
https://www.idrix.fr/VeraCrypt/VeraCrypt_PGP_public_key.asc

I've downloaded both directly. I've copied and pasted both into text files. I've stripped away the preambles and the endings, leaving blocks that each begin with the same gibberish and end with the same gibberish.

I've run them through all sorts of tr filters, like:

cat file | tr -d '\040\011\012\015' > file-tred

The one from MIT is still a lot bigger file.
I've loaded them into gedit and I can copy substantial chunks of one and search for that chunk in the other and find an identical substring, but not with the whole file.

This isn't an isolated example. MIT isn't unique. The second keyserver I checked (in New Zealand, but I'm not allowed to post a third link here) has the same issue. Nor is Veracrypt a special case. I've run into this every time I've resolved to learn to do gpg the "right way" and beat my head against the same wall for a few days before giving up. Is there some reason these things aren't published in a standardised form? Is there some way to make this easy? Am I missing something obvious? What makes that MIT file so big?

Addendum:
As a practical matter:

gpg --keyserver address.like-this-with-no-protocol-prefix-and-no-trailing-slash.net --search SOMETHING

seems to be checking duplicates of keys that I already have and reporting "no change", provided I choose SOMETHING well. So, functionally, I guess this is ok. I'd still like to know why my manual comparisons fail.

A PGP keyfile is not a single key string, but contains several entries (packets). Instead of trying to compare the ASCII representation of both files, you should use appropriate tools such as gpg(1) and compare the fingerprints.

  Is there some way to make this easy?

Yes, like this:

$ wget https://www.idrix.fr/VeraCrypt/VeraCrypt_PGP_public_key.asc
$ gpg --with-fingerprint VeraCrypt_PGP_public_key.asc
pub  rsa4096/54DDD393 2014-06-27
      Key fingerprint = 993B 7D7E 8E41 3809 828F  0F29 EB55 9C7C 54DD D393
uid                   VeraCrypt Team <veracrypt@idrix.fr>

The displayed fingerprint should be equal for both files. Note, how the lower few bits of the hash represent the key ID (EB559C7C54DDD393).

  Is there some reason these things aren't published in a standardised form?

They are, just check out RFC 4880 for the OpenPGP Message Format specification.

  What makes that MIT file so big?

It contains a lot more signature packets. Again, from the RFC:

  An OpenPGP message is constructed from a number of records that are
     traditionally called packets. An OpenPGP message, keyring,
     certificate, and so forth consists of a number of packets.

You can list all packets in a file via --list-packets (or use pgpdump(1) for a more readable version).

$ gpg --list-packets VeraCrypt_PGP_public_key.asc

This will yield an enumeration like this:

# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
    version 4, algo 1, created 1403892630, expires 0
    pkey[0]: [4096 bits]
    pkey[1]: [17 bits]
    keyid: EB559C7C54DDD393
# off=528 ctb=b4 tag=13 hlen=2 plen=35
:user ID packet: "VeraCrypt Team <veracrypt@idrix.fr>"
# off=1137 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid D6BE7DAF738161CE
    version 4, created 1403950017, md5len 0, sigclass 0x10
    digest algo 2, begin of digest 08 92
    hashed subpkt 2 len 4 (sig created 2014-06-28)
    subpkt 16 len 8 (issuer key ID D6BE7DAF738161CE)
...

As you can see, the public key packet has the familiar key ID EB559C7C54DDD393, while the signature packets come with their respective issuer's key ID (which you can also look up at the keyserver).

Side note: What you call "preamble" is called ASCII armor and used to transfer PGP messages over channels that have difficulties with arbitrary binary data (e.g. e-mails). It's part of the format and you can leave it in the file.


Such a thing as too much network segregation? One of the biggest points of friction I see between networking teams, security teams, and users is around the idea of network segregation.  For instance, the network team wants to isolate everyone behind VLANs, such that, for example, users would not even be able to browse the IP address of a security tool. The reasoning is that if everything is segregated, then that limits the potential exposure of that sensitive device to attack. Conversely, users in the security team find this cumbersome, because if they need to VPN in and view events at night, they need to utilize a jump box because they cannot access the interface from the VLAN that they are a part of.

What I want to know is how people typically approach this clash between "security" and usability. To me, I would rather the application perform the authentication, rather than rely on which VLAN someone is located.

To your first point, of course there is such a thing as too much segregation. I disagree with the answers already here that network segregation is obsolete or pointless, however. It's important to segregate disparate networks, and perhaps specific pieces of the larger whole.

Consider that a network firewall is a bastion host. It typically runs a very stripped down operating system and is used for a single function. Few users are typically entrusted with access, and changes are also typically backed up automatically using something like rancid.

This affords two things. One is a papertrail of any changes made to these devices, typically done under controlled conditions. Two, it can make it much harder for an attacker to access the data they are after. If a machine is only able to contact systems in its VLAN, it may not have any direct access to your important data. If everything is in a single bucket, a single compromised host immediately becomes a pivot to use against all of your critical infrastructure. If you have segmentation this can become significantly more difficult.

As to how to approach it, you have to balance usability and implementation costs of network segmentation with the value of the data involved. If you're a large organization which can be caused significant financial harm by a breach, it may well be that network segregation makes sense. I typically recommend a jump host with 2-factor authentication to gate any access into a production environment, and a small list of roles with this access.


One year later, is Heartbleed still something the end-user needs to be careful against? I'm running Chromebleed to defend against sites affected by Heartbleed, but it's been a very long time since I've used a site that was still vulnerable. By now I would think the vast majority of the Internet has upgraded to protect against the vulnerability.

A quick Google search returns a few articles discussing Heartbleed one year after the announcement.

Fortune magazine on April 7 2015 cites a report saying that 74% of the Fortune 2000 have still not patched.

So, yes, this is still a problem.


Mitigating SSLStrip by only serving a site over HTTPS? So I just learned about SSLStrip now--I feel like I'm so late to the game. What I want to know is: If your site only serves content over HTTPS and hard fails on HTTP requests, with no redirect, are you still vulnerable? Can an attacker intercept your HTTPS request and perform the request "on your behalf", so-to-speak, and serve your browser an HTTP version, if you type  into your browser's address bar? (Using either SSLStrip or some other attack?)

The TL:DR;

Below user10008 gives the answer. SSLStrip doesn't depend on the server's behavior, it depends on the client. If you can get the client to make the request over HTTP, instead of HTTPS, you can perform the attack, even if the server only supports HTTPS. HSTS prevents the browser from performing the plain HTTP request in the first place (on subsequent requests).

Yes, without further measures, the attacker still can perform SSLStrip. For SSLStrip to work, the attacker only needs to be a man in the middle, unrelated from your behaviour regarding HTTP. On an incoming HTTP request, the attacker would open an HTTPS connection to the real server, and "strip" the SSL off the HTTPS. So, there would be no HTTP communication between the attacker and the server. Even if the server's HTTP behaviour seems irrelevant, it is better for further mitigations to disable HTTP or create a permanent redirect.

When you only serve HTTPS, and you are sure you want HTTPS in the future, you can partially mitigate by using HTTP Strict Transport Security (HSTS) to tell users you only serve HTTPS. This will mitigate SSLStrip for all users from the time they connect at least once without being attacked.

You can achieve full mitigation for Firefox and Chrome by requesting to add yourself to a HSTS whitelist. Firefox and Chrome assume HTTPS use for websites on that whitelist, but a requirement for being on that list is sending the HSTS header. More info on applying here.


Do NICs designed for anonymity exist? Are there any NICs designed specifically for anonymity that do not come with a MAC address (ie you have to set it manually) or choose one randomly every time they are turned on?

Obviously this wouldn't help you be anonymous if your traffic goes through your modem anyways, but this could help you remain anonymous when connecting to the internet at a coffee shop.

There are various ways to change your mac address with different NICs, but I would trust hardware more if it was specifically designed for anonymity. Also, having protection always enabled at the hardware level would prevent software misconfigurations/bugs from being an issue.

The MAC address of the network card can only be seen inside the local network. I think you cannot be really anonymous inside a local network anyway. But apart from that most network cards can be set to a different MAC address using software.

  There are various ways to change your mac address with different NICs, but I would trust hardware more if it was specifically designed for anonymity.

The hardware has no idea when it should change the Mac address, so this has to be controlled by software anyway. Apart from that "hardware controlled" means actually controlled by firmware on the NIC, so in reality this is software again.