In any sanely managed company, a developer usually gets full access to the sourcecode of any project they work on.

The reason is that the benefits of releasing parts of the code on a strict need-to-know basis isn't worth the bureaucratic hassle and the huge work impairment it creates for the developers.

Developers can't work without seeing the whole picture. I am a professional software developer who works in a team which maintains a huge system. Most of the problems I get tasked to fix are bugs which could be in any part of the system. I need the full sourcecode in order to figure out where the bug originates and how to fix it. I wouldn't be able to do that job if I would need to fill out a form and wait for management approval before I can look at some of the modules which could have something to do with it.
Good software developers don't grow on trees. They are hard to replace and they can easily get a job somewhere else. To get and keep the best talent, you need to treat your developers well. If my company would start to hassle me with unreasonable access restrictions to sourcecode, it would frustrate me because I can't work efficiently and it would insult me because it means they don't trust me. I would be gone in a few weeks.
Most code isn't actually that valuable. Most code which gets written in the world is only useful for solving the problem of one specific client. For anyone else, the code is completely worthless.
Even if the code is valuable to a larger demographic, you have the law to protect it. Copyright and non-disclosure clauses in work contracts allow you to sue the pants off of anyone who tries to sell your intellectual property to someone else.

Technical measures to prevent sourcecode leaks on a network layer (like proposed in the comments to the question) are not an effective solution either. Developers are smart. They solve computer problems for a living. If they really want to get some information out of your building, they will find a way to do it. Not even the NSA was able to prevent Edward Snowden from leaking gigabytes of confidential data.

Besides, a malicious developer can do far more harm than just leak your sourcecode. There isn't much you can do about that, because the more you try to monitor and limit your developers, the less efficient they will be and the more unhappy they will become.

So what can you do to prevent your developers from turning against you? It's simple: Don't hire developers you can't trust and treat them well so they won't form a grudge against you. That means if you are a manager suffering from paranoia and trust issues, then software development is not the right industry for you (you might want to give retail a chance).


Cert Pinning on mobile app - does it really require a public SSL cert on the server side?

A certificate is used in TLS for making sure that the client talks to the correct server and not some man in the middle. To check the certificate the client either has to know exactly which certificate to expect or has to find another way to trust the certificate. In a typical setup with web browsers as clients it does not scale to distribute the expected certificate in a secure way to all clients and thus a PKI is used instead where the browser does not trust the certificate directly but it trusts the certificate because it trusts the issuer and the subject of the certificate matches the URL.

But in your case of a mobile app you actually can distribute the knowledge about the certificate with the application. In this case it is enough to have a self-signed certificate and pin to this certificate or its public key. But note that you cannot simply revoke the certificate in this setup in case it gets compromised. If you need this it might be easier to use the existing mechanism with public CA in addition to pinning.


Is random data inserted into an encrypted stream easy to retrieve?

If the intended receiver knows "how it was hidden", but not the attacker, then this means that there is a "secret convention", shared between the sender and receiver, and applied to the piece of random data which you want to keep confidential. Regardless of how you want to call it, this is encryption (both legally and mathematically, that's what you are doing). You would have better luck actually using a proper encryption algorithm rather than a custom game of hide-and-seek.

Possibly, you may want to have the software use by the receiver "know" where to seek for the random data, hardcoded in the executable. This is still encryption, with a hardcoded key embedded in the software (so really not very secure, because attackers tend to have a copy of the software, and to know how to reverse-engineer code). Still, using AES with a hardcoded key (if you do not want to bother the receiver with key or password management) would still fare better (not good, but better nonetheless) than mixing your random data at "discrete" emplacements.

For the question you actually asked, properly encrypted data is indistinguishable from random bytes -- otherwise, this would be felt as a weakness of the encryption system.


I'm assuming that you mean for logon (or unlocking).

I believe three factor is supported natively in Windows 7 with:

Windows Biometric Service (requires attched device)
PIV-compliant smart card (requires attached device)
Password (Kerberos V5 for AD, and NTLMv2 for local)

Windows Vista and Windows 7 have the same interactive logon architecture. They use a Credential Manager which interfaces to Credential Providers.

The Credential Manager can support four types of credentials:

"user name and password" (keyboard based something you know)
Certificate (something you have)
Smart Card with PIN (something you have + something you know)
Biometric (something you are)

Windows XP and Windows 2000 share a slightly different logon architecture. They use a Graphical Identification and Authentication (GINA) module. The module is responsible for collecting credentials and authenticaing the credentials. Microsoft provides a standard module: MSGINA.DLL. Microsoft provides three ways to modify the GINA module's behavior, and also allows replacement with a third party GINA. The three modification methods are: pre or post-processing, hooking, and registry settings. The Microsoft provided standard GINA supports Smart Card with PIN login. For biometric authentication, it seems common to have an administrator install a third party GINA module. It appears to me that this architecture would support three-factor authentication.

I also found evidence that Windows NT supports three factor authentication.

"Windows NT supports two and three factor authentication, including tokens, smart cards and biometrics." Stephen Cobb


Adding a new user: email temp password vs link with token

If the end user is the one who initiates the account setup and they provide a password, the use of a temporary password that they will have to change upon first logon provides no benefit. And will only serve to annoy the user.

Temporary passwords are useful when someone else initiates the account set up. As an example, a new employee coming into a company is typically provided with a domain account. You wouldn't want to let users self-register and create whatever domain account they wanted. You would typically provide them a temp password so you could control the accounts being created and to ensure that it was only them who could configure that account.  With a temporary password the end user, and the administrator know that no one has used that account if upon authenticating, they're required to change the password the first time. If the user tries their password and it's incorrect, you have the suspicion that the account may have been compromised or used by someone who acquired the temporary password and can investigate as necessary.

The non-temp password option is the most secure. Because it takes anyone other than the end user who knows the password out of the equation.


Why does OAuth 2.0 specification recommends the use of "application/x-www-form-urlencoded" Media Type?

Interoperability. The OAuth standardizes format and names to ensure different implementations can work together out of the box as much as possible.

Why do you have a situation where you can't use this format? All major programming languages have libraries that implements this format, many as part of standard libraries.


Is there reliable information on the prevalence of debug backdoors in software?

I don't believe there is a reliable, scientific study as to the prevalence of backdoors in proprietary devices or SCADA/industrial control systems.  A search of JSTOR turns up nothing interesting (although, if someone else wants to double check, please let me know if you find something!) Thus, the number you reference is likely just speculation or based on anecdotal evidence.

That said, I do not believe this number is without some justification.  When using closed-source products, there's always the risk of a backdoor.  As the article points out, many are unintentional and are a result of developers wanting to quickly test the system without dealing with access controls.

However, the main theme of the article has to do with international intelligence organizations inserting backdoors into products intended for vital roles in another nation, in this case, SCADA systems in China meant for use in the USA.   In those instances, it can be assumed that such backdoors are in place.  When the USA ships Boeing airplanes to China, for example, they have famously come laden with numerous and redundant bugs throughout the chassis.

So, my short answer is, one can never be sure about backdoors in closed-source products.  On the home router, it may be best to flash to an open source firmware if you share these concerns.  But as to scientifically quantify the rate that devices are backdoored; I believe that hasn't been done and would be challenging to do in a statistically significant fashion.


Possible attack via Netflix; what action should I take, if any?

First, this is not an attack via Netflix, is an attack spoofing the email sender. It could be anything: Apple, NASA, whatever. Spoofing an email sender is as easy as writing any name and address on an paper envelope and sending it.

The PDF file is protected so some antivirus software and automated scanners will not be able to detect malware on it.

What you do? Ignore it.

Someone will probably tell you to send it to Netflix, but they have nothing to do with it, and cannot help but tell you this email is not from them.


Using cryptography is it possible for offline devices to reliably communicate via QR code?

While it is generally possible to create a lightweight data structure that can be signed by the payment server (using an internal CA for example which is preloaded on the accepting devices) - and you could work against the reuse problem by having the accepting machine “cross off“ the previously accepted IDs, there are some things that are simply not possible without communication.

You would have to define the accepting devices ID on time of purchase to make sure it gets only used on that device to prohibit reuse on other devices. From your question I can not see that that is acceptable.

And then there’s a practical problem: having a data structure that holds enough information for the payload and the signature will make it hard to convey via optical codes. You suggested QR codes, which get hard to read with about 20 bytes of data - your signature alone will exceed that by far.


Is there something insecure about storing secrets in plain text on the host FS?

OWASP comments on this in Cleartext Passwords in CATALINA_HOME in the context of managing Tomcat's web server database credentials.  Their view can be summarized as

  best practices is to never to store clear text passwords, but it is
  very difficult to avoid

Their primary recommendation is to use file system security to secure the credentials file and limit the database user permissions to the minimal required.

If you have heard the expression, "it's turtles all the way down", it nicely summarizes the OWASP view that hiding the password in another place isn't really resolving the key issue and may provide a misplaced trust that the issue has been solved.

Enterprise security teams are sometimes humorless and likely lacking in  appreciation for philosophical arguments involving turtles and the problem of infinite regression. Therefore, there are several password vault solutions with integration for web servers including Tomcat Vault, OracleWallet, CyberArk, etc.


Great question.

In bash, when you use "read" to get a password from standard input, the password is of course stored in plain text in memory.  However, this is often the case for passwords in general -- something has to be storing them in plain text to use them.  If it was encrypted, a way to decrypt it would have to also exist in memory -- thus the encryption wouldn't be very helpful then.

In this case I can offer two sets of best practices:

1)  Use another method of authentication than password entered by the user.  This could take the form of:

For MS-SQL databases, using a "trusted" connection for authentication rather than a user-entered password.  Other databases offer a variety of systems for logging in without a password.
Join the computer to the domain and have the user login with Active Directory credentials. Then have the script use this authentication to login to sql. MS does publish sqlcmd and an ODBC driver for Linux that I've used successfully.

2)  If you must use a password supplied by standard input, turn echo off in the bash script.   Of course, bash scripts still need to be checked for possible exploits.  If your script sources a file that is writable by any user, then of course that file could be altered to send the password to an attacker.

You may want to consider use of a passphrase file which is chmoded so only a single user can access it. Then simply read-in the password from this file.  This is probably comparable in security to using the stdin password. While the user doesn't constantly type the password so some vulnerabilities (e.g. keylogger) would not exist; it would increase the ease of a password grabbing attack if someone just hacked the server.


Found fake Facebook profile with my name and education history, what to do?

One reason scammers may do this is to gain trust with and get close to other people so they can then scam then. Once the scammer is trusted, people who know you are more likely to divulge their own information to them, or more trivially, click on links that they think you are sending to them. There's probably a lot of other things they could try to use the identity for, but it would just be speculation to guess further.
If this is the case, your course of action should be to simply report the profile as fake to Facebook, and possibly encourage others to do the same, as more reports will make it more likely to come under investigation.
Alternatively, it could really be a coincidence. Even if you have a rare name, it's possible that you don't know everyone else with the same name.
Things like this could almost justify keeping a real placeholder Facebook account active but with privacy settings maxed out, so at least your friends know which is your real profile.


Is the server certificate taken into account during the cipher suite negotation phase?

Your cipher says *_ECDSA_* which means that the authentication is done using ECDSA which requires a certificate with an ECC public key. But you have a certificate with a RSA public key only. Thus, this cipher and this certificate will not work together. If this is the only cipher configured at the server or client the handshake will fail with no shared ciphers.


Key identifiers are extensions meant to help with certificate path building, but a mismatch does not imply a validation failure (at least as far as X.509 / RFC 5280 is concerned -- what implementations do is another matter).

However, the subject/issuer DN must match in a valid chain, and a mismatch implies immediate rejection. If you have a certificate whose "issuer DN" is "C=US, ST=New Jersey,...", then the immediately preceding certificate in the chain (the certificate for that CA that issued your certificate) must have that exact name in its "subject DN". From what you tell, none of the certificates they sent you fulfils this property.


How hard is it to distinguish between remote access to a virtual machine vs a piece of hardware?

It depends. If it attempts to hide that it's an VM, it can be hard. This can be the case with for instance VM's used for analyzing malware.

This paper from Symantec goes into some detail. In short, it's usually possible to detect, even if the VM, is trying to hide it, by running instructions to put the CPU in a specific state, and then run some instruction that forces the hypervizor to execute, and check the state of the CPU afterwards.

Timing attacks can also detect a hypervizor, but may be difficult if you have no baseline.

A stock VM from for instance Azure will not attempt to hide that it's an VM, and it will be obvious that it is a VM, from descriptors as you say.


What are the MitM implications of a stolen client-side private key?

If the client accepts any certificate as a valid server's certificate, then an active attacker can impersonate the server when talking to the client.

If the attacker can steal a copy of the client's private key then he can impersonate the client when talking to the server.

If both conditions hold, then the attacker can run a successful Man-in-the-Middle attack, by definition: a MitM attack is nothing more than simultaneous double impersonation. The attacker poses as the client when talking to the server, and as the server when talking to the client; he relays traffic in both direction, inspecting and modifying data at will.

If the client can make sure that it uses the genuine server's certificate (either through validation from a known trusted root CA, or maybe because the client remembers the server's certificate from a previous connection), then the client will reject the impersonation attempt, and the MitM won't work. The attacker, who has stolen the client's private key, will still be able to replace the client, e.g. hijacking incoming calls, but that won't be a true MitM (the attacker will have to imitate the voice of the normal client's owner).

Note that if the attacker does not have a copy of the client's private key, and the server validates the client's public key in some way (e.g. the server remembers the client's public key after an initial configuration step), then the attacker will not be able to impersonate the client. Client authentication in SSL is such that even if the attacker impersonates the server, he cannot reuse the messages from a gullible client to fool the true server. Technically, the client uses his private key to sign a "challenge" which is a hash value computed over everything client and server have sent each other so far, and this includes the server's certificate; so, in case of MitM, the client will sign messages containing the attacker's public key (the fake server certificate sent by the attacker), not the certificate sent by the true server, and the signature will not match what the true server expects.

Therefore, if either the client can make sure that it uses the true server's certificate, or the server can make sure that it uses the true client's certificate, or both, then a complete MitM attempts must fail. However, even without a MitM, impersonation (an "half-MitM") is still possible:

If the attacker steals the server's private key, or the client fails to validate the server's certificate, then the attacker can impersonate the server.
If the attacker steals the client's private key, or the server fails to validate the client's certificate, then the attacker can impersonate the client.

Finally, if the attacker has a copy of the server's private key, and the SSL/TLS cipher suite is one of the non-DHE RSA suites, then the attacker can decrypt all the data after purely passive interception, and can also hijack the connection at any point after the handshake, which allows, again, a MitM. The same does not hold for a stolen client's private key; in SSL/TLS, the client certificate and private key are used only for authentication, not for the key exchange, and have no influence whatsoever on the resulting secret used for actual data encryption.


Unexpected TLS extension reply in server hello

In the TLS 1.2 RFC Section 7.4.1.4 it says the following:

  An extension type MUST NOT appear in the ServerHello unless the same
     extension type appeared in the corresponding ClientHello.  If a
     client receives an extension type in ServerHello that it did not
     request in the associated ClientHello, it MUST abort the handshake
     with an unsupported_extension fatal alert.

For TLSv1 and TLSv1.1 look to RFC 3546 which applies to both versions.

Section 2.3:

  Note that for all extension types (including those defined in
     future), the extension type MUST NOT appear in the extended server
     hello unless the same extension type appeared in the corresponding
     client hello.  Thus clients MUST abort the handshake if they receive
     an extension type in the extended server hello that they did not
     request in the associated (extended) client hello.

Section 4: Error Alerts

  "unsupported_extension" - this alert is sent by clients that
        receive an extended server hello containing an extension that they
        did not put in the corresponding client hello (see Section 2.3).
        This message is always fatal.


Sharing oauth2 token with AJAX request to be sent to resource server

There are different solutions possible.
1. Allow CORS requests on authentication server
The purpose of the authentication server is namely to provide tokens for other servers. That's why it is normal to allow CORS requests on the authentication server. Thus you can implement any additional logic in your application, including requests to the authentication server. Browser will not block them as CORS violation. If you want to make sure that the application code does not see the password in the plain form, you may want to use PKCE. See details in RFC 7636.
2. Redirect, or implicit flow
CORS requests on authentication server are not allowed. You send request to the resource server. It sees that authentication toke is missing or is expired. Then it redirects your request to the authentication server. The authentication server requests credentials and, if they are valid, redirects request to the resources server, and adds a valid token to the URL. The resource server validates token and returns you the requested resource.
3. Cross-domain messaging
In such case you don't need to allow CORS requests on authentication server. One should be careful: The code that sends the token from the authentication server to the resource server part should not use broadcast (because the token can be stolen by the script from malicious domain). Instead, one should send the token to the resource script window/frame only.


How to prove that some action was taken by client in the presence of a malicious server?

Assuming the platform knows the user's details, this is almost certainly not possible without massively inconveniencing your users.

The easiest solution would be to just not store any user details. If the user can't place an order without entering their payment card, shipping address, and so on, then anybody can be reasonably sure that, if you have those details, the user was placing an order. However, that doesn't cover things like "what was ordered in what quantity" or prevent a malicious server from logging those details after all and using them to place another order later.

For non-repudation protection like that, you typically need some sort of attestation (on every client action) that only the client can provide. A simple example would be a digital signature (of the order details) using a private key that the client has but the server does not; the signature could be verified by anybody with the public key but couldn't be faked. This is basically the digital equivalent of requiring a customer to sign a receipt or enter their PIN, proving that they approved the transaction.

However, any kind of cryptographic scheme runs into key management problems (where does the client store the private key? Does it move between client systems following the user, and if so how? Remember that the server needs to never be allowed to use it). Additionally, for a web site, the signing would have to be done in JS, which means the server could just serve modified JS that takes the user's key and signs the order anyhow. You could tell the user that their order won't be accepted unless they use an external openpgp app to sign it (echo "I am purchasing 43 widgets" | gpg -sa) and copy-paste the signature, but it's a rare set of users who'd stand for that.

On the server side, there's no "traces" you could find that couldn't have been planted. Logs, file or database accesses, tickets in an ordering system... you control all of it, so you can fake whatever you want so long as it doesn't require knowing something that the client knows and you don't (like a private key).

The entire connection to the client is encrypted (at least, it had better be!) so even if there's a trusted third party (such as an ISP) between you and the client, they wouldn't be able to tell what was said. They could tell if there'd been no communication at all... along a particular path.

Client-side, the client could plant (or delete) any trace you might look for, and that's assuming there's anything to trace in the first place. Browser history might say what pages the user viewed, but the browser doesn't store the details of what requests it sent (unless you sit there with the dev tools open and recording) and order pages are usually dynamic anyhow. Besides, your site could contain script that quickly navigates through those pages, and then they'd be in the user's history even though no order was actually placed.


Is CN/Hostname verification against SSL certificate required for non browser software using openssl & why?

When you connect to a server and the server returns a valid certificate, then you "know" (subject to the vagaries of PKI) that you have connected to a "valid" server, whose identity is contained in the certificate. However, there is more than one SSL server on this planet. You still have to decide whether the server you contacted is the one you wanted to talk to. That's what the name check means.

This is the distinction between authentication (verifying who you are talking to) and authorization (deciding whether who you are talking to is indeed who you should be talking to). You need both. If you remove the name check then you must implement some other mechanism which allows your client to distinguish between the genuine server, and some other server with another name.


SQLMAP and DBMS credentials, how do you use them?

You can connect to the database using the credentials unter some conditions

1.) The MySQL Daemon needs to run on the external IP-Address of the server. MySQL can either be configured to be used over a unix socket or a network interface. For security reasons it's advisable to bind the daemon only to the loopback so it cant be attacked from an external offender (like you in this case). You have to check if your frind did configure it secure. By running a portscanner like nmap for example

nmap -sS -p 3306 you.hostname

the -sS tells nmap to perform a SYN scan which is more inconspicuous than a CONNECT scan and -p 3306 tells which port to scan. Port 3306 is the default port of the MySQL Daemon.

2.) The user needs to be unlocked for external access. MySQL gives the adminsitraor the possibility to only allow a specific user to connect from a specific host like the localhost for example. You can check this by having a look at the mysql.user table through your SQLi.

When these conditions are fullfilled you can connect using the mysql command or using the mysql workbench if your not so into terminal based work.

mysql -u yourusername -p -h your.hostname

The -u yourusername tells the username the -p tells the client to prompt you for a password and the -h your.hostname is the hostname of your target.

Before you do this you should also check the /robots.txt on the webserver. This file conaints urls blacklisted for link crawlers like the google bot. Often these files contain the pathes to administrative interfaces. So maybe you find the login page this way...


Importing an expired certificate into my jks

Certificates are nothing but public keys signed by a certificate authority. If it is a server-side certificate you're trying to import, the certificate would need its corresponding private key as well. You probably need to import the contents of the entire jks file shared by your teammate because I assume it has the renewed key also. If you only import the certificate, it might try to match it with the old key and throw the error you are seeing.


A hash can be copied by brief access to the smart card. This approach is basically the same as comparing strings; crypto adds no real benefit in your scenario - only obscurity, as anyone with access to either the private key or the hash will be able to authenticate. It will also be vulnerable to simple replay-attacks.

Modern RFID cards acts as smart cards. Store a private key in the smart card, and ask the smart card to authenticate to the reader, using these keys. Smart cards are commonly set up not to hand out their key, only use it for processing.

By using proper crypto you'll essentially make a system that is secure, as long as there is no security problems in the smart cards, allowing copying of keys. It will typically protect against replay attacks as well, as the data the card manipulates will change for every contact.

It's also worth reading about zero-knowledge proof on wikipedia. In brief, there's several methods within cryptography to prove that you know a secret, without ever revealing the secret to anyone. PKI is one obvious way; by signing you prove that you have the private key, but not the content of the private key.


How to spoof file extension when it is appended to the file name every time?

In situations like these where you have full control over where the files get output, it might be best to turn your attention towards potential LFI vulnerabilities. It's unlikely you'll bypass the extension suffix, but if you're able to get PHP code into the JPG EXIF data, you can use LFI to include that PHP.

The next suggestion I would make is to check and see if Javascript is adding the .jpg extension. If it is, just disable it and try uploading again.

Lastly, double check the request in burp and make sure that your NULL byte payload is actually getting through to server and that the filename is correctly stated in the request before you send it. It may be that when you select the file that there is an intermediary process in between that you may be able to also intercept that's adding the .jpg extension.


The manufacturer of the card may be printed on the carrier card.  When SIM cards are made, they're produced in a standard credit-card shaped plastic card, with a punch-out slot that contains the SIM itself. This outer plastic card may have printing on it that shows who the manufacturer is.

Also, the shape of the circuit pads is proprietary to each manufacturer.  Gemplus, the predecessor to Gemalto, used to embed their company name in tiny letters in the copper, at the top of the center area which they shaped like a lozenge.  However, I was unable to find a definitive site that shows a catalog of each manufacturer's circuit pad shapes.

You might be able to figure it out by examining pictures yourself.  I searched Google Images for "gemalto sim cards" and found a lot of pictures of the circuit pads.  Look at the shape of each of the contact pads.  Notice how the center pad can be shaped like an O, an 8, a J, it can be rectangular or rounded, squared, or even elaborate diamond shapes.  Different card makers have different shapes.

Be careful not to believe every picture you see associated with Gemalto, as many are generic pictures of SIM cards that are being added to articles associated with the current news event.  But if you see a picture of a card that has the name "Gemalto" (or other chip manufacturer) printed on the plastic, you can be sure that's the design of their pads.

Regardless of who made your card, you have no way of knowing if the Ki was compromised.  Gemalto is just the biggest player in the field, so it's unsurprising they were hit. But that doesn't mean other card manufacturers weren't hit.


Different SHA256 checksum of same version of ssh binary on different machines

The SSH version alone does not say anything. The build can be different. Even a recompile with a different compiler versions, different compiler options or maybe a different time can lead to changes. But in this case the change is much bigger and more obvious:
On Mac OS Catalina (19.6.0) the ssh binary has a size of 2142352 bytes and file reports Mach-O 64 bit executable x86_64 as architecture. On MacOS bigSur (20.1.0) the binary has a size of 4303584 and is an universal binary with support for x86_64 and arm64e. Because the size differs also the content differs and thus the hash differs.
Note that the version is the same (OpenSSH 8.1p1) on both systems.


Can an attacker extrapolate future codes based on past codes and their timestamps from a TOTP device?

It depends on the implementation of the token.
There is 3 types of implementations, and only first one is "vulnerable":

1: Some tokens are delivered where the seed can be calculated from the hardware serial in a determistic way. This can happen if you order a token where you can "use it with your own server without any need for API" or something similiar to that, something like a "universal TOTP token" or "universal HOTP token". You are then supposed to remove the sticker with the serial after having received the token, and usually the serial will be harder to guess.

In this case, someone with the knowledge of the serial will be able to calculate future codes.

2: You have ordered the token from the cloud service in question:
Then its no issue, as when your token is manufactured, a file with its serial numbers and secret seeds, are created and sent to your cloud provider. (Some token models even allow the cloud provider to "reinitialize" the token with their own seed)
Then, your cloud provider creates a database out of this file.

When you enter the serial on the cloud provider's site, they just look up the seed for that particular token and store that seed inside your account.

3: A token system with a API is used, where you order the token from a "token provider" that also provides a authentication API for third-party relying services to use:

Other token systems, like the Symantec VIP, instead relies on a API, where you only register the hardware serial with the cloud provider, only the serial is stored inside account. When a authentication happens, the cloud provider will send a request to the Symantec Server, asking if the code "xxxxxx" is a correct code to the token serial "xxxxxxxxxxxx". This is why a compromise cannot happen even if the same token are registred to multiple services.

And why you are asked to provide 2 subsuquent codes when registrering the token:

The reason you are asked to supply 2 subsuquent codes, is to ensure that the token is useable, so you don't accidentially lock yourself out of account. This process also works as a resync process, where the service will find the "initial sync" of the token, by searching for that particular window where these 2 codes exist, and the search could go through like tousands of codes to ensure that even a heavily desynced token can be registred with the service.
If only one code is supplied, theres a chance that the particular code exist somewhere else as 6 or 8 digits are pretty likely to repeat, and the server could accidentially set a wrong initial sync value to your token, leaving you locked out.

When you do a resync process, which can either be administrator/helpdesk initiated, or it can be a automatic process that is initiated by a number of invalid codes, you are aswell asked to provide 2 subsuquent codes. This time, its not to prevent a invalid resync as it is very unlikeable, but to increase security as the server will usually search about 50-100 codes forward, and also 50-100 codes backwards (configurable), which would make it likeable that a attacker could guess the code if only one was used, but of course the server will never go backwards past the last used code as this would allow reuse of token codes.

However, bottom line, is that you shouldn't share token serials anyway, because sometimes, the token serial can be partial authentication data for account recovery, so with the use of token serial, a attacker might be able to convince helpdesk personell into disabling 2FA for your account with like "My token have gone black, something is wrong with it" and such, and the helpdesk personell are just trying to help, and falling for the social engiinering trick.


local environment development and HTTPS: interaction with Chrome requirement of CT logs

From Announcement: Requiring Certificate Transparency ...:

  This past week at the 39th meeting of the CA/Browser Forum, the Chrome team announced plans that publicly trusted website certificates issued in October 2017 or later will be expected to comply with Chrome’s Certificate Transparency policy in order to be trusted by Chrome.

Thus, the requirement for CT is only for certificates issued by public CA. CT is not required for certificates issued by private CA.


Is it possible to exploit PHP unserialize without classes?

It depends on your version of PHP.  Using unserialize to find weaknesses in the application is dependent upon the application having vulnerable classes.  If they don't have any classes, then the application is not vulnerable.

However, you may be in luck!  I don't actually use the PHP serialization myself because in the past it has been very buggy, with severe security vulnerabilities from PHP itself.  I'm not personally familiar with the exact details, and it does depend on the PHP version (which obviously you don't know), but there is a high enough risk that for someone performing security auditing, the answer is legitimately "NEVER pass user data into unserialize".  For the wrong versions of PHP, the result can be a serious disaster.

You have to really know what you are doing to take advantage of said vulnerabilities, but what you end up with is a remote code execution vulnerability in the PHP interpreter itself, which gives the attacker a much bigger prize.  Here is a very detailed run-down of the vulnerability in PHP 7.  This obviously isn't directly applicable to you, but it shows that the vulnerability is real and it doesn't depend on the user having defined classes:

https://blog.checkpoint.com/wp-content/uploads/2016/08/Exploiting-PHP-7-unserialize-Report-160829.pdf

Also some very basic information:

https://www.cisecurity.org/advisory/vulnerabilities-in-php-unserialize-function-could-allow-remote-code-execution/


I think you are referring to certificate pinning in the context of client authentication, where the server not only checks that the client can successfully establish the SSL handshake with the certificate (which means the client knows the private key) but that the certificate is exactly what the server expects (or one of the expected certificates).

The check that the certificate is exactly the expected is useful if you deal with self-signed certificates or if you want to add an additional protection on top of the existing validation to make sure that no attacker was able to get a certificate for the same subject from a trusted CA. It is typically not done by comparing the whole certificate as binary (although this is possible) but by comparing the fingerprint of the certificate or of the public key inside the certificate. In the latter case this is known as public key pinning.

This technique is more commonly used in the other direction, i.e. to make sure that the server certificate is the expected. This is used in today's browsers to protect important domains like google.com by embedding the expected fingerprint of the public key into the browser. With the HTTP extension HPKP any other sites can do public key pinning too.


Detecting code removal reverse engineering

There's no way to ever know for certain if someone is reverse engineering your code, an attacker can take your APK file and pull it apart manually or with tools.

If you are really paranoid and willing to experiment a bit you could work in a system of phone-home calls which are triggered by events and modified by parts of your code. A change in parts of your code could change the values sent as part of the phone-home calls. You could also use APK checksums, there'a a Stack Exchange question on this very topic which may help. None of this is a sure-fire way to know frankly, and you could sink a lot of time into it just to know if someone's tinkering.


Is there an advantage to using hardware 2FA over SMS when both are available?

SMS is not as intrinsically secure as a locally-run algorithm like HOTP; there is always the possibility of a compromise in the network.  For most people, though, this isn't within their threat model.

Personally, I don't use SMS as a second factor, because it isn't in my setup.  I've long used Google Voice, and now use Google Fi, and so my text messages can also be accessed through my Google account.  This no longer makes it a "something you have", but just another "something you know".

Hardware-based tokens have an additional protection over phone-based tokens (even HOTP/TOTP apps) because they're operating on much simpler hardware: it's much more difficult to compromise a Yubikey than an Android phone.


The common inherent possible security issues from adding Unicode support (not specific to UTF-8) come from the increased potential for visual spoofing, and issues coming from normalization mismatches.

Visual spoofing: say you have a forum with a user named "admin" that everyone knows to trust. Someone else could register a user account named "аdmin" (the first letter is the cyrillic letter a), and trick others into thinking they were the site admin. This is mostly a technique for social-engineering: it's unlikely that any software will mix up the users. (This specific example could be partially addressed by having the site add special formatting or flair near the admin's name, making profile names be links to profile pages which show the user's activity history and join date, etc., so users could identify others in ways besides their visible forgeable name. This is a more general issue that isn't exclusive to unicode support: users could also name themselves other misleading names like "<site> Support", "admin " with a space, "admim", etc.)

Normalization: certain characters like "ö" can be represented in multiple ways. It could either be the single character U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS), or the two characters U+0061 U+0308 (LATIN SMALL LETTER O + COMBINING DIAERESIS). Normalization is the process of converting all text to the combined or decomposed form. If you consistently never use normalization or always use normalization, then you won't run into issues. However, if you sometimes do, you can have security issues:

For example, OS X normalizes unicode in filenames. Say you had a website without any normalization-related code running on an OS X server where whenever a user registered, a file was created with their name, and you used a database without any normalization to keep track of usernames that were already registered in order to prevent names being re-registered. If you had a user named "foö" (using U+00F6), then someone else could register an account named "foö" (U+0061 U+0308), and the site would allow it but would overwrite the file created by the first "foö" user. To solve this, you would either need to make your application normalize consistently throughout the whole application, or you would need to check for collisions whenever you cross some boundary that does normalization differently (when a user registers and you need to make a file for them, open the file in exclusive mode so that it will fail if the file already exists, and you can block the new user from being registered).


One option is to just blacklist residential IP ranges. Other option is packet inspection. An SSH tunnel can be distinguieshed from standard https


Is zeroing out values on the stack and arguments overkill?

The C standard specifies the behavior of code in terms of an abstract machine.  This specification does not know about concepts such as "the stack".  It knows variables with "automatic storage duration", meaning variables which are "gone" when the scope they've been defined in is left.
From the perspective of the C standard the code local = 0; has only the effect that subsequent accesses to local will yield the value 0.
Now, even though it's not explicitly called like this in the standard, C has an "as-if rule".  This means that a compiler is free to implement the code however it likes as long as the "observable behavior" remains the same as that of the code when "run" by the abstract machine.
local = 0; has no observable behavior (assuming there's no code using local in an observable way after the assignment).  Therefore, the compiler is allowed to discard that assignment; regardless of optimization settings.
Thus, "zero-ing" like this is a sin because it is not guaranteed to actually do anything and adds clutter to the code, making it less readable.  Note that this also applies to dynamically allocated memory!
edit It's questionable if it's even possible to make sure the compiler doesn't optimize the zeroing away, see this blog post, linked post and comments
/edit
To really zero a variable You need to make this assignment "observable".  The C standard luckily includes means to do so: via an assignment to an object of volatile qualified type.
So with a function like ...
void zero_out(unsigned char volatile * memory, size_t size)
{
  while(size--)
  {
    *memory++ = 0;
  }
}

... You can be sure that after calling zero_out(&local, sizeof(local)) the memory region (if any) where local is/was kept is zero.  This disables any smart optimizations by the compiler, though, so for larger memory regions it might be slow!
Even better than my above function is to use a function provided by either the standard or the compiler to achieve the same (because it might be optimized):

C11 has memset_s which won't be optimized away.  Problematic because memset_s is only optional, and currently not available on e.g. GCC and Clang.
MSVC has SecureZeroMemory

There are also other (potentially better) ways to implement my zero_out from above:

A volatile function pointer:
 void * (*volatile memset_here_to_stay)(void *, int, size_t) = memset;
 void zero_out(void * p, size s)
 {
   memset_here_to_stay(p, 0, s);
 }

An "external" function, implemented in assembly (or generated by another translation unit).  Attention! Link time optimization might make this ineffective ...


Does appending data from a form to a URL with encodeURIComponent safely sanitize user input?

Yes, encodeURIComponent() is the correct way to safely fill a query parameter with untrusted data.

  The encodeURIComponent() function encodes a URI component.
  This function encodes special characters. In addition, it encodes the following characters: , / ? : @ & = + $ #

(from w3schools)

  is there something additional I need to do to sanitize textThatUserEntered?

No, if you just use it to encode a query parameter value as in your example, you don't have to take additional measures. An attacker will have no way of introducing a new parameter or change the URL in a way that directly creates an XSS vulnerability or similar.

But that does in no way mean that the parameter is safe for processing on the target site. It just means that it's safe for the requesting script. The parameter could still trigger an injection vulnerability on the target server.

Also note that some characters are excluded from escaping (!'()*). That's why Mozilla proposes a wrapper function that also escapes these characters although they don't pose any immediate threat as they don't have an assigned meaning in the query syntax:

function fixedEncodeURIComponent (str) {
  return encodeURIComponent(str).replace(/[!'()*]/g, function(c) {
    return '%' + c.charCodeAt(0).toString(16);
  });
}


Setting httponly secure cookies in microservice architecture

One cannot set a cookie to a different domain, except for a different subdomain.
But in your specific scenario the users browser only connects to mygatewayproxy.example and does not see any of the internal domains in the first place. This means the browser will only accept a cookie for mygatewayproxy.example or subdomain. If no domain is explicitly set on the cookie this current domain from the perspective of the browser will be implicitly used as cookie domain.
This also means that any cookie set by login-service-1.example will also be send to different-service-1.example since from the perspective of the browser all these domains are only visible as mygatewayproxy.example.


When generating a 4096 bit RSA key pair, do both the private and the public key always have exactly 4096 bits?

As a preliminary, in RSA the public key is the pair (N, e) and the private key is d. Like it has been stated, the bit size of the modulus N is what the 4096 refers to. N only makes up part of the public key, along with e. There is no requirement for what bit size e is. The only requirement for secure encryption in RSA is that exponentiating the message m to the eth power "wraps the modulus", i.e. m^e > N. So in practice values of e as small as 3 (2 bits) have been used. The most common current value for e is 65537 (17 bits) in fact most SSL certs that you see have this value e.g. google.com

The bit size of d, the private key, is not set and can vary greatly as it is simply the multiplicative inverse of e in the group phi(N) where phi is the totient function. In most cases it will be much smaller than 4096 bits.


Why are common services using implicit SSL not considered obsolete in the way that SMTPS is?

tl;dr:

Because neither implicit nor explicit TLS is technically that bad;
Because changing ways the Internet works takes time.

This is essentially not one, but two different questions, and I'll address them separately.
1. Why are common services using implicit SSL not considered obsolete?
As you may have already noticed, in recent years, large corporations such as Google or Facebook have put a lot of effort in securing HTTP communications, and largely succeeded at that. But one of the main drivers for that seem to be ISPs replacing Web ads with their own, which severily harms Google's and others' business models.

By the way, the implied consequences of this are huge, the very structure of the Internet is going to change a lot as the result. Geoff Huston from APNIC has summed it up in his excellent blog post and related presentations (slides, video), so I'd better just refer to that without explaining it further here.

There are, of course, other drivers as well, but a lot of them are still heavily bound to securing someone's business models (e.g. PCI SSC activities and so on).
What's most important here is though those achievements in HTTP area raise a bar pretty high, many other ways of communication, including e-mail, seem to lack that sort of commercial drivers HTTP luckily has, and this is probably one of the main reasons their security stays rather obsolete, compared to what we have currently in HTTP. As the result, in 2018, it's still necessary to support a great number of outdated mail access servers, user and transfer agents which are only able to communicate in cleartext.
Hopefully this will change, but I personally can currently offer no clear estimations for that.
Both implicit and explicit TLS approaches are better than cleartext, as securing communication either way is better than not securing it at all. Some MUAs and MTAs deployments out there only support either implicit or explicit TLS, and deprecating any of the concepts leaves those deployments without any countermeasures against MitM attacks. Deprecating protocols and methods that are used actively on the Internet — and are essentially better than nothing — in favor of nothing is a bad practice.
As you can see, deprecating SMTPS alone haven't done us any good: it's still there in the wild. This is an example that a widely used Internet protocol couldn't be just shut down at will. Right, sounds funny, but back in circa 1998 when it happened it might have been less clear than it is today.
Moreover, declaring one of the concepts outdated in favor of the other must be supported by the Internet community, and though most people agree there should be only one of two options left as preferred at the end of the day, it's not that easy to reach consensus on whether explicit TLS is better or not (more on that below). The Internet draft you're pointing to is a fundamental initiative towards bringing a piece of sanity in all this mess without bringing up a common standards dilemma:

Once it's finalized, a process of explicit TLS deprecation would start at some point in future, but it will take time.
2. Why explicit STARTTLS should be considered a better option?

A disclaimer: this is simply an outline of current approaches towards the Internet protocol design. I'm not taking sides here, the right places for objections against those approaches are IETF working group mailing lists and meetings.

Implicit TLS is great for protocols which are designed from scratch, with contemporary threat models in mind, and which lack the requirement to support cleartext communication. However, implicit TLS is somewhat a controversial approach with regard to securing old cleartext protocols. It seems to be working fine for HTTPS, but it required some effort, including allocation of a different port (443) for secure HTTP communications.
The downside of this approach is that for each remaining cleartext protocol, you'll need to allocate another TCP/UDP port, while the global TCP port space is severily limited. At some point, IETF working groups generally considered wasting ports this way a bad practice, and even port 465 (originally SMTPS) was later reallocated for a different purpose (this actually happened about 20 years ago, which as well sheds some light on how slowly the Internet adopts changes).
Again, as you can see in draft-ietf-uta-email-deep, this consideration might be withdrawn in the near future.  Note also that this draft originally dates back to year 2013 and is now only approaching the final state, which gives you an idea of how hard this choice is overall.
The general idea of opportunistic (or explicit) TLS is to somehow inform a client in advance (using a different communication channel, already verified before and thus trusted) that a particular remote server supports STARTTLS, so the client must only use STARTTLS for data transfer towards that server, thus preventing STRIPTLS attacks. Originally DNSSEC was supposed to provide this separate channel, however, its worldwide deployment has somehow stalled, and as the result, working groups are considering other ways (e.g. TOFU) to do that.
Note that the implicit approach itself is not downgrade-resistant as well, as a man in the middle is able to strip implicit TLS. Approaches like HSTS depend on TOFU themselves. A common argument is that a user can force their software client into secure communication by explicitly specifying a port number in client preferences, but a software client can also provide user with an ability to explicitly enforce STARTTLS on an old port, so from the user's perspective the difference between two approaches is subtle.


Can someone explain me the DNSSEC NSEC3 output?

First, have a look at http://dnsviz.net/d/gggg.icann.org/WVLgMg/dnssec/ it may help to have things displayed graphically and over your mouse on top of the NSEC3 record at bottom to see all details.

NSEC3 is far more complicated than NSEC (and NSEC5 is far more complicated - but not yet deployed anyway - than NSEC3), and the behaviour will not be the same.

Basically you have 3 NSEC3 records because you are seeing here the authentication of the denial of existence of a wildcard record.
The gory details are in §5.6 of RFC7129, but you will need to read the previous sections to first learn about the "closest encloser" concept.

In short, the problem is explained by this snippet:

  The short answer is that due to the hashing in NSEC3, you lose the
  depth of your zone and everything is hashed into a flat plane.  To
  make up for this loss of information, you need an extra record.


How to securely store 3rd party API keys directly on web server

One recommendation would be to specify the API keys in the script running your application server. Ensure permissions of the script is execute only, owned by a dedicated user. Your application can read those keys via environment or system variables.


How to deal with "Session resumption (caching)" warning?

This isn't a security warning at all. It is more an indicator of a misconfiguration which is bad for performance but not relevant for security: The server issues session ID's for resumption but if the client tries to resume a session using the server provided ID it will not work. For reasons this might happen see this discussion.


Pictures saved to computer without owners knowledge and/or use of comp in a week

A simple explanation is that a cloud backup app is set up on the PC and will sync files which are loaded to the cloud (such as dropbox, box, onedrive, google drive, etcetc) by also copying files down to the PC.  If you want a more detailed answer you are going to have to provide more info, though.  Was the PC turned on or off? Why do you suspect it wasn't him? What is the source of the proof that the files were placed without his intervention?


What is the difference between an SYN-Flood attack and an SYN-ACK-Flood attack?

An explanation of how each attack works, it is really helpful if u have a small background knowledge of TCP protocol

SYN flood :

1)The attacker sends multiple SYN packets at all server-victim's port forging his IP address

2)Server replies at all SYN requests with a SYN+ACK for each open port and a RST for closed ports.The connection is now "Half-open" and the server expects a ACK response from the client to establish the connection into an "open" one

3)The attacker never responds to the SYN+ACK leaving the connection at a "Half-open" state (usually 75 seconds until server terminates the TCP connection). The server has built in its system memory a data structure describing all pending connections. This data structure is of finite size, and it can be made to overflow by intentionally creating too many partially-open connections, then the system will be unable to accept any new incoming connections until the table is emptied out.

Reflection attacks are used on challenge-response authentication systems using the same protocol in both directions, tricking the target system to provide the answer to its own challenge and i don't think there's a SYN reflection attack

SYN-ACK Flood :

The attacker sends spoofed SYN-ACK packets that do no belong to any current session within the server.This can lead to resource exhaustion of any state-full mechanisms, like firewall,ips,ids or the server, which will try to do a look-up for every incoming SYN-ACK request .

This attack can be amplified with a botnet sending SYN packets to servers on the internet with the victims IP spoofed as the sender. Each server will respond with a SYN-ACK redirected back to the victims server generating large numbers of SYN-ACK packets.


In order to trace back the source you first need to figure out which device is generating the traffic. The best, in my opinion, would be to set up a flow collector of some sort. There are generally two ways to do this,

Exporting flows from the device
Software analysis to generate flows

Most high end network gear will generate some kind of flow record, such as sFlow, jFlow, or NetFlow. These are produced directly by the router and sent to a collector. You'll then use some kind of analysis tool like flow-tools or nfsen/nfdump to process the records.

Using other devices will involve getting a copy of all the traffic somehow, typically using a tap or setting up a mirror/span/monitor port on you border device. A tap is a physical device that you place inline with a connection and it will electrically duplicate the signals. The mirror port is configured on the network device itself and will send a copy of all packets from one switch port to another. Most "enterprise grade" devices support this, but for lower grade equipment a tap may be required.

Once you have a copy of the data you'll need something that will take the traffic stream and turn it into flow records. There are a number of commercial products, but I am most familiar with the open source product Argus, produced by Qosient. It will process the packets on an interface, much like tcpdump, and produce data files that consist of flow records.

Whether you go with exporting flows, commercial products, or Argus you now have everything you'll need for your analysis. Any of those collection tools will contain all the necessary tools to produce bandwidth reports like you want. Or just about any kind of report you want, really.

I'm sure this sounds like a massive overkill, but the results are fantastic. These types of records are invaluable for network troubleshooting, incident response, forensics, billing, etc.


Can I prevent my ISP from accessing my network if I change my router config?

I would be very surprised if your ISP can change the settings of your router. I suspect that they changed the settings of their router that you rent. If you are unhappy with this, use your own router after changing all default passwords and enabling other appropriate security settings.


How to find the vulnerability of my server after attack?

I'd strongly recommend imaging your disk and then wiping it securely and re-building the server. Ensure the compromised server is disconnected from the network immediately to stop any compromise spreading. Work on the disk image not the compromised server if you want to check the possible source and extent of the compromise.

Don't rely on restoring data to overwrite a virus or backdoor - you need to securely wipe the disk and rebuild the server. Scan and check backups as well before using them.

Presumably you have anti-virus running on the server? If you have then either it's not updating regularly, it's a zero day virus, or a direct hack that gained access to some level of interactive login. If you haven't install one and scan the image/disk - it may tell you what is going on. Scan all backups too.

If someone malicious has gained access to your server then, with sufficient permissions, they could move files wherever they wanted to. A full forensic investigation is needed to find out the cause and extent of your compromise.

You can start by checking access logs for interactive logins - tie up recent login access with specific accounts and check with the account owners to discount those logins - or not!

You can't trust timestamps on files - they can be changed easily. Do you have any intrusion detection system with file integrity checks? What does that system say about changed files and dates?

There are so many steps to take to try to track this down but if you're not prepared for a breach then it's very likely you'll not find the source of the issue easily if at all.

Also consider what data was in the database in terms of sensitivity and confidentiality. It's possible that the compromise has leaked some, or all, of the data from your database - if someone can wipe it they can almost certainly transfer the data out of the network (depending on your firewall egress rules).

Finally don't forget to check all servers and devices that this server has access too i.e. can connect to from services or accounts on this server - the compromise may have spread.

There's plenty of information on line on how to investigate breaches to find possible causes and how to clear up - don't just restore some data and hope for the best though if you don't know precisely how the compromise occurred and what damage/changes has taken place.


Is this method of managing storageless session management secure?

First off as always why are you trying to roll your own? As pointed out in the comments something like JWT performs the same job.

A brief look suggests this should work. Although i'd suggest making it more transparent. You could instead for the cookie value use -

username:[Username]&tokengeneratedat:[GenerationTime]&Sig:[Signature]

This makes development, debugging and user inspection far simpler since the underlying details are in plain-text.  This approach is also more flexible seeing as you can do things like cycle keys - just use the Generation Time to identify which key to use.

I would suggest verifying the user exists in the table at the very least on token refresh / ideally every request to support instant access revoke.


What needs to be done on a Citrix Netscaler to protect from SSL Renegotiation attacks?

Here is an explanation of what this "renegotiation hack" is all about.

An SSL/TLS session begins by a procedure called the "handshake": right after connecting, the client and the server exchange a few administrative messages in which cryptography happens, and afterwards client and server have a shared session-specific secret with which subsequent data is encrypted and integrity-protected. The secure tunnel is established.

The renegotiation is the ability to perform a second handshake within the tunnel. The administrative messages are then encrypted and integrity-protected (with the shared secret which has been established through the first handshake), and they result in a second shared secret, which then replaces the previous one.

Why would anybody want to do that ? Mainly to circumvent the combined shortcomings of HTTPS and Web browsers, in particular Internet Explorer.

It so happens that during the handshake, the server shows his certificate (by which the client authenticates the server), and may request that the client does the same, i.e. present a certificate and use the corresponding private key. The client is free to deny the request (i.e. not to send a certificate) and this is not nominally fatal to the handshake (the server may elect to continue the handshake). Client certificates are rare, but are considered nifty, notably because they avoid the issues with user-chosen passwords (they have their own issues, but not the same). Some banks use client certificates, which they issue themselves to their customers.

Now HTTPS is HTTP-within-SSL. The client (browser) connects to the server, establishes a SSL tunnel, and then, within the tunnel, sends an HTTP request (or several successive HTTP requests, with keep-alive). The tricky point is that the server knows the target URL only at that point, because it is part of the HTTP request; and that's after the handshake. So the server should decide whether to ask for a client certificate or not before knowing the actual target URL.

Unfortunately, requesting a client certificate triggers some inconvenient behaviour in some browsers. In particular, Internet Explorer 6.0, upon receiving a request for a client certificate from the SSL server, displays the following "helpful" popup:

This screenshot is for a French version of Windows, but you get the point: a technical-looking popup asking to select a client certificate within... an empty list. Indeed, IE 6.0 scans the certificates in the local machine for one which matches the request from the server, and shows the popup even if there is none. This kind of behaviour is apt to confuse users, in particular a bank customer who does not have a certificate yet, since he is coming to the bank Web site for the first time, and may opt to register for the certificate-based client authentication system. That is, if he has not been scared away.

IE 9.0 appears to be better behaved in that respect, but the idea remains: client certificates are not well handled by Web browsers with regards to UI, so servers wish to request client certificates only for specific parts of the site which only "trained" (registered) users will try to reach. But since the handshake happens before the sending of the target URL, we need a renegotiation. Things are supposed to happen that way:

A client connects. A handshake is performed, and the server does not ask for a client certificate. The client is not authenticated yet.
The client sends the HTTP request within the newly established SSL tunnel.
The target URL in the request is part of the "registered area" (it is a "GET /registered/index.html" request). The server says Aha! The user must be registered, let's do the SSL thing again, this time with a client certificate.
The server asks for a new handshake (a renegotiation). This time, the server asks for a client certificate. The client complies. Note that this renegotiation happens at a "lower layer" than the HTTP request; the HTTP request is still pending at that time.
Now that the server has positively authenticated the client, he may grant the request, and send the HTTP response within the second tunnel, which has replaced the first.

Now let's have a look at the hack. The important characteristics of SSL renegotiation are the following:

The new handshake can be initiated by the server or the client at any time (the scenario explained above assumes that the server triggers the renegotiation, but in SSL the client could trigger it too).
The whole handshake business happens at the tunnel level, regardless of the applicative data (the HTTP requests and responses) which are transported in the tunnel.
The handshake messages for a renegotiation are byte-to-byte identical to what they would be for a first handshake (except that for a renegotiation, the messages go through the encryption layer established by the first handshake).

So, now, the attack. We assume a server like the one described above. Moreover, some requests that can be sent to the server have an "effect" which requires client authentication, and is valuable to the attacker (e.g. a request for a fund transfer). So the attacker first puts himself in a Man-in-the-Middle situation: he can intercept, and modify at will, the bytes exchanged between client and server. The following scheme illustrates how the attack goes:

The attack steps are thus:

The honest client wants to connect, and thus sends the first handshake message (dubbed "ClientHello").
The attacker temporarily blocks that message. Then, the attacker establishes a SSL tunnel of his own with the server, as if he was a normal client. Since the attacker is in the MitM position, he can mimic the client in all its details, including alleged IP address. The server does not ask for a client certificate yet, so the tunnel can be built successfully.
Within his tunnel (that's the red part in the schema above), the attacker sends an HTTP request, for a funds transfer.
The server says: "hold that thought, client, for a funds transfer I need to authenticate you with a certificate". And the server initiates a renegotiation, by sending (to the attacker) an "HelloRequest" message.
The attacker then forwards, encrypted in his tunnel, the initial ClientHello sent by the honest user (who is still waiting at that point).

At that point, the client believes that he is doing his first handshake, and exchanges handshake messages as cleartext. The attacker intercepts them all and encrypts them within the tunnel he established with the server; the attacker also decrypts the handshake messages from the server and sends them to the client. From the point of view of the client, this is the first handshake ever for this connection; from the point of view of the server, this is a renegotiation. But since the handshake messages are identical for both types of handshakes, this works. The honest client successfully concludes his handshake with the server, even though the messages have been transported by the attacker. The server is now content with the authentication from the client...

... and the server just assumes that the client authentication is valid for everything it exchanged since the first handshake, including the POST request made by the attacker. And that is the security issue.

So, who is to blame and how to fix ?

The trouble is that while the TLS specification describes the notion of renegotiation, it does not detail the actual security properties which are achieved in such a situation. Roughly speaking, the renegotiation establishes new cryptographic properties which have a forward effect. Notice that in all of the above, the fundamentals of SSL have not been violated: the honest client does a handshake with the server, with authentication, and whatever the client and server send after that handshake is protected and authenticated.

But in our attack scenario, the server wishes to transport the client authentication, obtained through the renegotiation, over data which was received before the renegotiation (the POST request). That's a backward effect, and, as shown above, this is not part of what SSL renegotiation provides.

So we can blame:

the TLS specification, for not being clear about what renegotiation actually does;
the server designers, for just assuming a backward transport of authentication;
the HTTPS designers, for putting HTTP within a SSL tunnel instead of integrating SSL into HTTP with a STARTTLS command;
the Web browser implementers, for their terrible handling of client certificates.

Blaming is fun but not constructive, so let's see to the fix. For the specific scenario described above, the fix is RFC 5746. It consists in modifying some handshake messages so that messages for a first handshake and for a renegotiation are distinct from each other. Coupled with the cryptographic binding inherent to handshake messages (a handshake message ends with verification messages which are computed over a hash value of the previous messages, so our MitM attacker cannot alter the contents of the handshake messages), this fixes the issue described above. For a more generic solution, the biggest difficulty is defining what we really want; but we know that it entails making the upper layers (e.g. HTTP) aware of the cryptography which occurs underneath. One can have a look at RFC 5056 for a discussion on the subject.

Another possible fix is to modify the application protocol so that the server does not try to transport the authentication in the backward direction. In an HTTP context, this would entail responding to the first request (the unauthenticated request which urged the server into making a new handshake) with an HTTP temporary redirect, so that the client sends the HTTP request again, this time after the new handshake (so the server would first make the new handshake, then send the redirect response).

We may note that the same issue does not raise with client authentication with passwords (HTTP "basic" authentication within a SSL tunnel) because with such an authentication, the server asks for a password, and the client sends it after repeating the target URL. So the issue is not applicable to many Web sites.

Apparently, Citrix found it fit to publish fixes, but without much details. They do not say whether they just changed the way the server asks things (a server-only fix), or whether they implemented RFC 5746, which is a fix only as long as the client supports the extension too. Firefox has supported RFC 5746 since February 8th, 2010. For Internet Explorer (actually Windows, since IE uses Windows' SSL/TLS code), this was part of a patch published on August 10th, 2010.

Possibly, Citrix Netscaler was not affected at all, but the people at Citrix found it smart, as part of Public Relations, to show that they feel concerned about security issues, and added a "fix" which would be more psychological than technical.

My advice would be: apply the patches published by Citrix, and make sure that the client software (OS, browser...) is up-to-date (something which you already want anyway). Then you should be safe from that obscure TLS renegotiation issue.


This depends on the protocol used for your VPN - this is not nearly enough information.  If PPTP, yes, likely - PPTP is definitively broken.  If something else, well, it depends.  A well crafted VPN protocol is not susceptible to replay attacks - look up your protocol and see its current status.


JInitiator is obsolete and I should reject it on grounds of security, right?

JInitiator is based on Sun (now Oracle) JVM implementation, so it is a safe bet that every single vulnerability which was in Sun/Oracle JVM before 2008 (when the last JInitiator version was produced) but discovered only afterwards applies to JInitiator. Lack of CVE only comes from disinterest on the part of people who fill CVE (there is no glory in pointing out security flaws in a product which has been discontinued five years ago).

Note that some vulnerabilities are novelties, e.g. the one described on this page uses a feature introduced with Java 7 -- it would not work on JInitiator. You may want to go through this list: vulnerabilities which were discovered after 2008, but impact JRE 1.3 and later, have a high probability of impacting JInitiator as well. You only need to find one working exploit demo to have a convincing case that JInitiator should be rolled out ASAP.


The first step would be using a secure facility that carefully controls access.  Beyond that, locking the rack is probably one of the best bets.  Super glue in control ports works well too as long as you know you won't need to use or change the port. Chasis locks, etc.  A lot of it really comes down to trusting the data center to provide that outer layer of security though.  Unattended hardware in a room someone else has access to can be broken in to if someone really wants to.

While it won't prevent physical access, you can also do thing like log chasis intrusions (if you have the sensor for it) and any changes in hardware state.  These can also be worked around by a careful attacker with knowledge of your hardware though.

If you really need full control, then you need full control of the physical environment as well.


What utilities exist to brute force a username and password?

THC-Hydra might be helpful here.

Also Bruter.

I have not used them for VPN or TS testing, but they are the 'standard' Windows password brute force tools.


Does a self-hosted VPN (openvpn) at home encrypt traffic for my ISP?

Your setup is not fully clear. But given the description I assume that you create your own OpenVPN server and use it as an VPN endpoint when you are outside of your local network. Any connection to the internet from the client will then send protected by the VPN and invisible to the ISP to your home. At your home the traffic will then leave the VPN (since your home is your VPN endpoint) and will be send without further protection from your home to the internet - i.e. the ISP can see where on the internet your traffic is going and in case of unencrypted traffic can also see the contents.


My company is considering collapsing from multiple independent domains to one trust network

Nobody can tell you what exactly you have to do, unless you give more details about your infrastructure, your business processes, used software etc.

What I would advise is:

Set up a network plan for your hypothetical new infrastructure.
Put together a security analysis, including (at least):

2.1. an IT-Infrastructure analysis (what assets will be involved in your new     infrastructure and how will they interact)

2.2. a vulnerability report

2.3. a risk analysis

2.4. a managerial report
Especially 2.1. - 2.3. will help you find those "unknowns" you are worried about. Also interview other experts in your company, read accompanying documents, look into other security documents.

You can check up on how all this is done in the various standards and norms. Just look around at nist.gov and look into the ISO/IEC 27000-27005.


Securing a network attached storage on the internet

The answers will be protocol/application dependent. Basically, if you can use a secure tunnel or a VPN solution, you will have pretty good security. Someone might be able to knock on the port, but they won't be able to connect without credentials (and certificates if you can).

You could try to setup a simple VPN using something like Hamachi, TeamViewer, or OpenVPN. Once this is setup for your family with the certs and passwords, you could allow them to use any existing protocols or to access a network share (though for performance reasons I would not recommend just using a network share over Internet/WAN).

One solution that makes this relatively easy is to use any of a number of software which allow you to mount a drive locally via SFTP. They have free and commercial solutions for various operating systems (e.g., SFTP Net Drive, OSX Options, google for others). If you just want them to be able to drop file, this is a good lightweight solution because you can just make it another drive on their network and since its SFTP there is less overhead then other solutions. The caveat of course is that they either need to type a password each time they load the file or you need to store it on their system, but that is likely a concern with anything user friendly. You could also script something.

If you have passwords and certificates at your VPN level and let your firewall manage your VPN that would minimize exposure, but may be unnecesary (just because people scan my SSH sever, they don't get on because they don't have a cert + credentials).

For a pure automated backup, I would look at some of the free P2P features of CrashPlan. Other backup tools usually have an SFTP connection option as well, where you can do a traditional periodic file backup with incrementals, differentials, deltas, etc.


Use Tor when testing on web apps that allow testing & have bounty programs?

Websites with bounty programs allow live exploiting, to some extent. Be sure to read up on their guidelines on this before proceeding. I think it's better to not use Tor, since Tor usually signifies malicious intent, especially when coupled with attempts to exploit the system. And they may not take kindly to that (especially if you are using things which link you to your real account while trying to exploit the system like an API key). Just use your normal browser, and if they come a-knocking, show them the details of the exploits you tried.

Sites like Google block most Tor exit nodes, so this is usually a moot point.


For PCI compliance, is a central Auth required for domain and non-domain security principles?

The most direct way to understand their claim would be to ask them to provide you with specific references to this requirement in the PCI Data Security Standard (DSS).  Otherwise we're taking shots in the dark to try to confirm or deny their statement.

I'm not aware of any requirement for having a single authentication system, let alone single server, in a DSS compliant environment.  I did review the requirement 7 & 8 sections of the DSS and confirmed those two in particular don't say anything about needing a single authentication system.  Requirement 7.2 does say "Establish an access control system(s) for systems components ...", but that doesn't support their argument even if you consider 'authentication systems' and 'access control systems' to be interchangeable.

Section 10 does talk about centralized logging, so that could be their reason for concern if their goal is for all user authentication to be logged in the AD.  But centralized logging doesn't require you to use a centralized authentication store either.  Your LDAP server could log the relevant security events to a central store if needed.

Finally, they may not be requesting consolidation due to any specific requirement in the DSS but instead their business requirement to keep the environment as simple and limited as possible.  Since each new server or component needs to meet compliance requirements they may not want to be responsible for yet another authentication system.  With your SaaS offering already in place that doesn't seem like reasonable restriction, but you'd have to negotiate with them to hopefully come to that conclusion.


SMS based authentication, handling recycled phone numbers?

SMS authentication works well as part of a 2-factor authentication scheme, on it's own? Not so much.

If the phone number and the value of the code sent in the SMS are the only things required to login then this is vulnerable not just to recycled numbers but anyone who knows the number and can read SMS's sent to it.

Since you were specifically asking about recycled numbers then really the only ways to defend against this threat model are either for user to ensure that they deactivate the link between the account and the phonenumber of for the operator of the site to use a service which provides phone number deactivation information such as PhoneID:

https://www.telesign.com/products/phone-id/

This uses data from telco providers to indicate when a number has been dactivated or changed hands etc.


Can a website see if I'm surfing the web via remote control?

No, Paypal should not be able to figure out that you are accessing the account from Pakistan if you are using TeamViewer to access it "from Dubai."
This is provided you do not login to Paypal from Pakistan again, or within a short time period of accessing it "in Dubai."


Does TLS 1.0/1.1 server sign the message digest with its private key?

There is no signing involved when using a HMAC. The protection offered by the HMAC comes from the secret used inside the HMAC  which is derived from the master secret which itself is the result of the key exchange.
See TLS 1.0 RFC sections 6.2.3.1 and 6.3 for the details.


Difference between Zeek (Bro) and Snort 3

Snort is more a traditional IDS/IPS which does some deep packet inspection and then applies signatures on the traffic in order to detect (and maybe block) attacks.
Zeek does not claim to be an IDS: instead it claims to be a network monitor and traffic analyzer. From their own description:

Zeek is a passive, open-source network traffic analyzer. It is primarily a security monitor that inspects all traffic on a link in depth for signs of suspicious activity. More generally, however, Zeek supports a wide range of traffic analysis tasks even outside of the security domain, including performance measurements and helping with trouble-shooting.

As far as I know (i.e. what I got from discussions with others) Zeek is therefore more used to capture the details of the traffic and forward these to some analysis system. The analysis regarding attacks is primarily done outside of Zeek and the focus for Zeek is on collecting detailed information about the traffic.  Sometimes custom protocol dissectors are added which are specific for the protocols used in the environment. I think Bro/Zeek is for example used in Darktrace to get the traffic details.
Classical signature based IDS like Snort or Suricata are instead more used as actual IDS, i.e the focus is on matching specific attack signatures. For example Cisco provides its subscribers new signatures when new attacks emerge. But I also know several cases where Snort or Suricata are used to only collect information about the traffic and feed these traffic details into a larger system, similar to how Zeek is typically used.
In other words: there is overlapping functionality. But the primary goals of these tools are different and thus are also the use cases.


Should we release the security issues we found in our product as CVE or we can just update those on weekly release notes?

You can do either, but I recommend applying for a CVE so that customers who get threat intelligence feeds are more likely to notice the issue and expedite a patch. Assigning a CVE also makes it easier to reference a specific vulnerability in general communications if you need to later. It's also a signal to your customers that you take security transparency seriously.

CVEs are assigned and managed by MITRE, and you can use the CVE application form to make a request.


How to remain 100% anonymous on the internet?

There is a geeky possibility to use a prepaid card (SIM) and connect
it with a mobile HSDPA dongle i.e Huawei_E220 and also you can check the section Privacy rights and prepaid mobile phones for Prepaid Mobile Phone. If you buy everything without registering you can have access to the world wide web anonymously. Because this is a known problem against cyber crime and other criminal activities it is not allowed in some countries to use such an unregistered prepaid card.
Another possibility is to use an open WI-Fi. For example in an
internet café. The operating system must be available without any
registration like Linux. The MAC-Adress of the Network-WiFi card in
the computer which is visible in the WI-Fi network must be changed
(this is easy possible in Linux)
If you want to do some research about the Tor network you can try the Linux distribution Tails where everything is setup right (for example the flash player would use another channel which goes not through the Tor network.) Which means if you are using the flash player while browsing with Tor, the data packages for the flash-player will communicate with your real IP address and goes not through the Tor-nodes. Tails Webiste


WIN 10 hardening: Importance of "Allow system to be shut down without having to log on" policy

That policy may source from the CIS Benchmarks, but is intended for servers, not for user workstations.  To quote §2.3.13.1 (and note the Profile Applicability and Impact sections):

  2.3.13.1 (L1) Ensure 'Shutdown: Allow system to be shut down without having to log on' is set to 'Disabled' (Scored)

  Profile Applicability:

  Level 1 - Domain Controller
  Level 1 - Member Server

  Description:

  This policy setting determines whether a computer can be shut down
  when a user is not logged on. If this policy setting is enabled, the
  shutdown command is available on the Windows logon screen. It is
  recommended to disable this policy setting to restrict the ability to
  shut down the computer to users with credentials on the system. The
  recommended state for this setting is: Disabled.

  Rationale:

  Users who can access the console locally could shut down the computer.

  Attackers could also walk to the local console and restart the server,
  which would cause a temporary DoS condition. Attackers could also shut
  down the server and leave all of its applications and services
  unavailable.

  ...

  Impact:

  Operators will have to log on to servers to shut them down or restart them.

The idea being that a user might not have privileges to log into a server, but with physical access, they would be able to shut it down.  Consider the HVAC guy working in your server room, etc. etc.

It is reasonable for you to allow your users to shut down workstations.


How do I configure Azure Web Apps so that the only access is via CloudFlare?

One idea I had is to add an Azure Firewall, and set it to white list the CloudFlare IP Addresses, but I wondered if there is an easier way (and anyway I am not sure how to configure it)

I'm afraid this is the only option: otherwise anyone could send a direct request to  example.azurewebsites.net using your domain in the HTTP headers:

GET / HTTP/1.1
Host: www.example.com


If I find or create a 0day exploit, can I be held liable for releasing out to the public?

First, I'm not a lawyer. Second, this completely depends on your local laws. I can only speak for my limited experience with UK and US law.

In most countries, you're covered by free speech laws, assuming the information you're releasing isn't protected by some form of non-disclosure agreement, and isn't classified as a military secret. If you found the 0day as part of a test you performed whilst hired by the company, you're likely to be restricted by contractual obligations (e.g. an NDA). Any form of information that is classified by a government as secret will be covered by a statute (e.g. the Official Secrets Act in the UK, or the Espionage Act of 1917 in the USA), which makes distribution of that information illegal. For private cases where you have no affiliation with the company that produces the software, you're usually not liable. You're releasing investigative information about one of their products, which you should be entitled to do as part of standard free speech legislation.

However, this isn't to say that you'd be 100% off the hook in private cases. Depending on the situation, a company might decide to proceed with a civil suit to claim for damages. I'm not aware of any such successful cases, but it's something to consider.

In the end, it's always best to follow Wheaton's Law: "Don't be a dick!" - practice responsible disclosure and maintain a good relationship with the vendors that you contact. It could end up being very lucrative from the point of view of both rewards and employment prospects.


Is it necessary to force a newly registered user to login?

This is a perfectly reasonable thing to do.
If you don't require a user to verify their e-mail address before using your service (or perhaps you only require a username and password to sign up in the first place), then granting a user a session upon completing registration is a reasonable thing to do.
However, if you require the user to verify their e-mail address first, then you should only  grant a new session upon verification, not upon sign-up.


Is it safe to expose bcrypt password hashes?

No, it's not ok, but that's not a matter of the bcrypt hashes, but because you moved authentication from the server you trust (because it's your server) to the user's device (which you can't trust). It now takes a simple debugger to change the result of the "is this password valid?" check from "no" to "yes".

Also, it gives an attacker a persistent access to a list of hashes. So, the attacker can brute-force that list for as long as they want on any computer that they want to use.

Simply put, that is a very bad idea.

The right thing to do would be to cache the actions of the user who claims to be a coworker of your authenticated user, and let that coworker properly authenticate with your server as soon as they are back online to actually commit whatever they did to the server. One way to do that is simply to store the password the user entered and then send it to the server, in whatever shape you use during a "normal" log in. If that works, fine, the user has authenticated itself, and the stored actions can be carried out. If not, well, tell the user that he entered a wrong password and his actions cannot be committed unless he enters the right one.


is it possible for an attacker to change a csr in x509?

Imagine someone evil is eavesdropping on your communication in the exact moment that you submit the CSR to the CA (signer):

The attacker will attempt to impersonate on you by submitting the CSR and obtaining a certificate for your site. However, the signing entity will perform additional identity checks to assure that you own the site specified on the CSR (i.e: contact by email, challenge-password, upload x file ...). Then the attacker should control more than just the obtained CSR.

Note that the CSR carries a digital signature of the certificate request information, so the attacker can't just embed Google's public key, since it can't create valid signatures, thus CA will know that the public key owner isn't the requester.