OAuth 2.0 when and how to use the client id and secret

ClientID and Client Secret are basically the same idea as a username and password, though keep in mind that in some contexts they could refer to different things. Either way you will generally use it to fill a basic authentication header in a HTTP request to the authorization server.

Not using a ClientID is, to my knowledge, impossible. You are claiming an identity after all, that of your OAuth client. The client has certain permissions associated with it and any long lasting grants need to be associated with a client as well.

No Secret
Not using a secret is possible, however you need to consider the following things. If you don't use any means of authentication then anyone can use your client if they know the clientID. If there is not much risk to having an unauthorized party use the client then that is fine.

Different kind of secret
Another way of not using a secret is to use other means of authentication. For example based public-private keys or certificates. The advantage here is the you are not sending your shared secret along with your request for a token, therefore your your secret cannot be intercepted. With the public-private key scenario the authorization server would send some random message to the client to have it encrypted with the private key. The authorization server can then decrypt it with the public key and validate it, or some other variation of this crypto magic. Either way the private key is not transferred and thus stays safe.

Two authorization flows
The authentication code flow will have the user (resource owner) authenticate to provide some form of access to the client. The user will be redirect to a location associated with the client, in this redirect the authorization code is passed along. The client can now obtain the authorization code and exchange it for an access token and, possibly, a refresh token. During this exchange the client will need to authenticate. In the implicit flow the user will be redirected as well, but now the tokens are passed along immediately. So there is no need for an exchange and thus no need for the client to authenticate itself.

Possible vulnerabilities
Using no authentication at all could mean an attacker will have an easy time using your client. Creating random clientIDs and creating them on the fly to destroy them once done are ways to decrease the odds of this happening. But still someone could just guess them or otherwise figure out the clientID.

Using a client secret means a shared secret between the client and the authorization server which could be intercepted. This becomes a lot harder to pull off when you use HTTPS, which you should definitely do regardless of the options  you pick. Either way  the possibility is still there in the case of a man in the middle attack, sniffing, weak ciphers and possibly others.

Using the implicit flow the tokens will pass through the users device where they might be intercepted and used by an attacker. Though to be honest, if this is the case the user probably has bigger problems than that.

Conclusion
OAuth gives you a lot of options and freedom to suit it to your needs. What you pick is a trade-off between ease of use and security. It depends on your use case and environment what the best option will be.


While less common, requiring something to physically be in your possession is a perfectly valid form of authentication. Many two-factor login systems use SMS or phone calls as a second factor.

  I assume that many services implement a model similar to this but it
  seems fairly trivial to find a situation where someone used some sort
  of publicly accessible computer

Public computers are never to be trusted for any sensitive work, ever. With public computers keyloggers (both hardware and software-based) are likely to be your most dangerous threat, and in that case the reset email is probably worse. By capturing your email login, the attacker would get access to any account that has password reset linked to that email.

So in short, both methods have their pros and cons. Which one is better depends on the kinds of threats you want to protect against.


Transport Layer Security for multiple persons

TLS requires an out of band mechanism from which to bootstrap trust between the communicating parties.  Using an external certificate authority is one approach.

an alternate approach is PGP's web of trust, where individuals you trust sign the public keys of individuals you don't yet trust.  Here, Alice might connect to Bob. Alice trusts Bob. Bob connects to Carol, whom Bob trusts. Bob tells Alice Carol's public key and address, and tells Carol Alice's key and address . Carol and Alice can now connect to each other, based on trust in Bob.

Alternately, Alice and Carol can exchange keys and addresses in person, such as on business cards.  They can then contact each other, believing that they are talking to the person they met in person.

Or you can have a central server where each user has registered a public key. Any other user can connect to the server and ask that server to forward traffic to the recipient as known by such server.

Edited to add: please don't design your own protocol.  See the following link for a discussion of why not: Are there any holes in this security design?


How to crack forgotton KeePass password when knowing most of the password

Sounds like a combinator attack would be a good place to start.  It takes two input wordlists and tries all combinations of the two.  In your case, the "left" list would be the beginning of your known password and the "right" list would be the unknown portions.

However, Hashcat only allows two input files to a combinator attack, but you can use the standalone combinator utility to pre-process multiple files down to one.  For example:

combinator part1  part2 > part12
combinator part12 part3 > part123
...

In your case, the files would probably be split into the following chunks:

The known prefix of your password
Sequential numbers of varying lengths (1, 12, 123, ...)
The word that may or may not be included, plus one blank line

The blank line is required, otherwise all output candidates will contain the word.  Including the blank line means that half will include it and half wont.

Another sequential number section, just like the previous


Your question is a bit broad and especially does not make clear whether you're using LDAP or Kerberos for authentication.

I'm pretty sure there are tons of web pages providing information about security best practices for MS Active Directory in general.

Some important aspects regarding applications:

If you use LDAP simple bind for letting your applications check the user's password then all these applications have access to the user's clear-text password

If you use Kerberos then bear in mind that the services' keys are always protected. Because if an attacker can get a copy of the shared secret of a service he can impersonate as any user to that particular service.

In general I'd recommend to use a single sign-on method based on asymmetric crypto. At least for web applications that's not that hard anymore.


Can I improve website security by storing SSL Keys in DNS? Is DNSSec required? Are threat models available?

Is DNSSec required for public key/hash distribution?

Yes. One has to have a trusted starting point, and in this case that's the signature of the root domain. From there, each corresponding subdomain is signed so there is a chain of continuity to demonstrate that your request was not hijacked at any step of inquiry.

Are there any threat models comparing using regular DNS as a repository as opposed to DNSSec?

DNS spoofing is already a common and low-barrier method of attack. DNSSEC was implemented primarily to prevent that. Verifying the server's certificate in the same channel as an unauthenticated DNS query provides no real security enhancement.

What should be stored, the hash, or the full public key?

In theory, one could store either to the effective same level of security. However, DNSSEC is designed around storing the whole key in order to sign zones, so I would gather that one might as well stick to storing full keys and signatures for every application.

How difficult would it be for vendors to support this extra validation of a SSL/TLS certificate?

I think the code complexity would be lower than that of verifying an SSL cert (that X.509 parsing is quite a nuisance). I suspect most browser vendors could roll this out with relatively little effort. More complex plugin systems (such as Convergence.io) are regularly written.


What are possible security issue if any of automatically inserting 2FA in 1password?

TLDR: Don't use that particular feature of 1Password.

  Is 1 password the only one with this feature?

My password manager of choice, KeePass can also support this via a plugin. As for other password managers, I do not know.

  I felt a little bit icky.

It is a little icky to merge your 2 factors into one.

  The whole point of 2FA is we need two different authorization. And now it's combined into one.
  Anyone that can get into my 1password account can steal all my money.

Yes, anyone who manages to gain access to your 1Password would be able to log in. But in this case, the point of 2FA is a bit different. It is not really as much two factor as making the one factor better.

  So what's the solution?

Other then not using this feature, there is no solution. However, I believe there is no "problem" either.

I believe this feature is not meant to protect from 1Password compromise. It is rather meant to prevent the password being compromised when it is entered. Here are few examples the password may be revealed:

Keylogger or other spyware grabing the clipboard when you copy password
Keylogger grabing the password with autotype feature
Accidentaly saving the password in the browser
A malicious web browser extension grabbing the password
A malicious javascript (for example from XSS) grabbing the password
Attacker intercepting the login credentials, for example by MITM attack

In all these situations, the attacker would be able to gain your password, however if you use TOTP 2FA, he would have an old OTP. Therefore, he would not be able to log in at all in some of these scenarios and only log in once in the rest.

This feature is therefore IMO useful when you trust your 1Password will not be compromised, but you are worried about the password leaking. If you feel you need to protect your self, especially with e-Banking, you should use your phone instead. This is for lower-security applications.


Securing API keys for a Twitter account for a program to be run on other PC's

As specified, the problem is completely impossible. You can not, and should not attempt to, make a program - much less a script - do something its user can't see. There are many ways the attacker could break this. They could just read and analyze your python scripts (even if compiled, .pyc is easy to decompile). They could debug the program as it runs. They could intercept the network requests it makes to Twitter and pull the key out of there. They could replace the Python HTTPS library with one that wraps the official API and also logs a copy of the requests and responses to plain text. They could load your program as a library of another python program and programmatically examine its contents... Seriously, people keep asking about this and it just can not be done.
As @Limit's comment says, your best bet is to expose an API from your server, and have your script call that with whatever it wants to put on Twitter. You can then validate the message before posting it, rate-limit each client's uploads, prevent abuse of the account such as deleting tweets or using DMs, and revoke third-party access to the account entirely just by disabling the endpoint on your server. This isn't enough to totally prevent abuse, but it'll do a lot better than any method of trying to hide secrets in a Python script.
Another option is to use unique Twitter accounts per user. Either require the users to create/supply their own account (which your server then learns about and monitors for uploads, perhaps with specific tags or mentions), or automatically create one (well, as automatically as Twitter will let you get away with) for each node and don't use them for anything else (the user running the node would still have full access to the account in each case, but not to any other accounts).
Or you could just have the nodes send the resulting videos to your server, and your server decides what to do with them. This is basically the same as the first viable approach, except the new endpoint is not "send video here to upload to Twitter", it's just "send video here when done" and you-the-server-owner decide what to do with it then.


Is my network configuration is efficient for security?

sounds pretty solid, a MAC address filter does not add security though and you might want to disable it, as it can be quite inconvenient for home usage.

So far, this sounds pretty good. But MAC addresses can be easily spoofed in many operating systems, so any device could pretend to have one of those allowed, unique MAC addresses.
MAC addresses are easy to get, too. They’re sent over the air with each packet going to and from the device, as the MAC address is used to ensure each packet gets to the right device.

Which pretty much would defeat it as a safety mechanism.

Guest network
Use for Internet-only devices that don't need local LAN access to other electronics, enable guest isolation.

Another useful thing to do would be to add Google  DNS ( 8.8.8.8 ) and/or OpenDNS ( 208.67.222.222 )
As your ISP's DNS might go down every now and then. In terms of stopping ISP tracking it does little, as they can reverse the IP you're sending requests to.
Sources:
Why you shouldn't use mac address filtering
decentsecurity.com


How this tracking (and more) was done using an image in an email?

It's very common practice even by legit companies to track open success rates by placing a image link in the body of an email. Then if your email browser like outlook is configured to auto-load images in emails then it makes an HTTP request out to a website to load the image. That request will have a unique id in the url specific to you ... so now that web server hosting the image knows that you opened your email.

That is all done basically without any real hidden code ... just standard HTML in the body of an email.

If there was "hidden code" then perhaps things like scripts hidden in an SVG image or perhaps it was a different attachment type like .html or .js


How would rw permissions on an Apache directory actually be compromised?

A few possibilities, ordered by likelyhood:

Your django app may contain weaknesses that allows an attacker to execute arbitrary code as user www-data.
Django itself may contain a weakness that allows for remote code exection.
Apache itself may contain a weakness that allows for remote code execution.

In all three scenearios, an attacker gains access to the file system, or, in case you've chrooted your process, to the part of the filesystem in the chroot jail. An attacker being able to change your images probably isn't the biggest problem (depending on the nature and use of the images, of course). A much more dangerous problem is that he might place other code in your images directory, since www-data probably has write access to the directory. This means that

An attacker can now place arbitrary code and data on your server and
Access that code and data remotely, because it sits under the webroot of your apache server.

These two abilities are very useful for an attacker. He might start mining bitcoins on your server, or use it to send spam e-mails, or make it part of a botnet, or use it to distribute illegal material, and so on.

The image write permissions themselves are harmless in that they can't be exploited to gain access to your server, but they are a problem once an attacker has managed to breach your server, because they give him a place to stand on, so to speak.


Where is the public key of the Certificate authority stored?

The public key of the CA is stored in the certificate of the CA. And this certificate is stored in the local trust store on the clients system. It is true that an attacker which has access to the local trust store could replace existing CA certificates or add new ones. But if the attacker has this kind of access he can do lot more harm anyway, like replacing the existing software on the system with a similar one having a backdoor or other malicious behavior.

For more information see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?
.


Ensure data doesn't linger after being deleted

Destroying data properly without physically damaging the media is quite a difficult task, especially since HDDs have started coming with block reallocations. This is orders of magnitude more difficult (if not impossible) with SSDs, since there the firmware does literally magic with what is really stored in the flash. As my comment asking for more detailed information about your setup went without an answer, let's assume an SSD is involved.

Since you can't really destroy the data, the next best thing is making them inaccessible. Which is what encryption is usually rather good at (when done right). Hence your generic solution is to encrypt all the data you want to be able to forget easily and throw away the key once such a time comes.

Implementation for various services may differ a lot and may (or may not) require substantial changes to your infrastructure. In all cases however, two rules will apply:

use good encryption algorithm and configuration (mode of operation, IV generation)
make sure you will be able to discard the key (actually any sensitive plain text data for that matter!) really properly - this basically mandates storing it physically in RAM and remembering to overwrite it with something else when not needed any more1.

A simple example (on Linux) concerning users' home directories

Create a regular file - its size will determine the size of user's home, fill it with (pseudo)random data (one way to do it is to write zeroes to a dm-crypt device backed by that file)
Create a dm-crypt device backed by the file, keep the password stored only in RAM (see 1). If you used a dm-crypt device for "randomising" the backing file in the previous step, use a different password now.
Create a file system on the crypto device;
Mount at user's home;
When you decide to remove the home, unmount it, throw away the key, remove the file (possibly fill it with random data again, but remember this doesn't make that much sense for SSDs).

1Rather tricky part and your mileage may vary (as always with security). The point is, that even for a server there are case when that key (or other sensitive data) may be present in memory when it should not. In your case this can be for example when a service (database...) crashes (or is just stopped for maintenance) or, as suggested in a comment, in the case of a power-off, especially a forced one - i.e. the attacker physically removing the server from its place for analysis.

The first case could be solved by kernel wiping any memory pages belonging to an application after it frees them (thus including any form of application stop).

The second one is even trickier. You may ask why you should bother with RAM  after a power-off and you wouldn't be the first one - read on Data remanence, Cold boot attacks and check e.g. Are there volatile memory chips which dont retain data after power off?. General answer: there's not much you can do without a specially designed hardware that would erase the RAM on power-off. And even then - can you exclude a possibility of an attacker hooking onto a running the machine on hardware level?

While this sounds paranoid, it is just a hint about what you may want to consider when implementing such a service. You have to decide what makes sense, what threats you don't really want to spend resources on and what trade-offs are acceptable. For example if you want to be able to reboot the machine unattended, then you're pretty much out of luck, since that requires it to have access to at least some unencrypted sensitive data (let's say the encryption key), which in turn breaks the whole privacy chain.

Another problem is, that you need to make sure it doesn't get swapped out - at least not an unencrypted swap storage.

To sum it up: question is not whether you can make it impossible for an attacker to get the data - it is how difficult you make it. You have to specify the how much part to see what makes sense.


Practical way to communicate a pre-shared key?

This is a perfect application for public-key cryptography (ie. asymmetric cryptography).

They provide you with a public key (that needn't be a secret and can't be used to decrypt anything) which can be used encrypt what you need to send them, then they use their private key to decrypt it (which they don't give to anyone).

PGP would be a suitable implementation if email would otherwise be convenient:

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

http://www.openpgp.org/resources/downloads.shtml

https://www.mailvelope.com/

There is the issue of how do they give you their public key without the risk someone will substitute it for another. This is probably not a significant risk unless an adversary is expecting you to send a public key over a network they control. If you are concerned you could address this in one of these ways:

They could post it to you and you could read it via OCR (can the mail man be trusted though?)
You could both calculate a hash of the key and they could read it out over the phone so you could verify it (less error prone, you probably don't even need to check all characters)
Theoretically if they publish it on a page with SSL you should be safe


Is it safe to have port 443 unprotected by firewall without application?

When you open the ports to the public internet the security of your server relies on that of the application behind the corresponding port.  So if you have an application running on 443 that is vulnerable to some sort of an attack then you will now have opened up a vulnerability to the internet.  However; I'm assuming that if you are about to use that port for SSL you are confident there are no security vulnerabilities in the software running on that port.

To put it simply, opening that port before you have the SSL cert in place does not create any more vulnerabilities that what would be there when you did have the SSL cert besides the possibility of a MITM on a client using the web application.


The book, Kali Linux Wireless Penetration Testing Beginner's Guide, 3rd Edition, covers the setup of the krackattacks-scripts tools.

Deps:

apt-get install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev
net-tools git sysfsutils python-scapy python-pycryptodome

Make hostapd:

cd hostapd

cp defconfig .config

make -j2

Run the scripts. Identify which works for your hardware by reading the guides. Note that this may crash your system, especially if you are working from a guest VM:

cd ../krackattack

./disable-hwcrypto.sh

Modify the hostapd.conf file to your specifications. The default SSID is testnetwork with password abcdefgh.

Disable network manager

systemctl stop NetworkManager.service

systemctl disable NetworkManager.service

Finally, execute the Python scripts necessary

python krack-test-client.py

More information in the Vanhoef and Piessens paper, Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2.


Can a shim (a.k.a. polyfill) be installed in IE, FF, or Chrome without user knowledge, and can it read passwords entered by user on a login page?

A developer chooses to write a polyfill because it fulfills his personal need. From this personal aspect may come all problems you may imagine, namely malicious JavaScript code.

  Can a shim be installed in IE, FF, or Chrome without user knowledge?

Surely. Drive-by download attacks which consist in malware delivery without the knownledge/consent of the visitor of a given compromised web application. Such attacks exploit vulnerabilities in the web browsers themselves or those of their installed plugins. Note that these plugins can either be innocuous but vulnerable, or malicious by design;

  Does the code in the shim have access to login credentials entered by
  user on a web page?

Shim or not, as long an attacker succeeds to install and run some malicious JavaScript code within your browser, anything can happen. I have no better example to give you than the notorious ZombieBrowserPack. Which is an opensource project developed first as a POC by Zoltan Balazs, and targets some of the most used browsers (Chrome, Firefox and IE). This plugin can be manipulated remotely to steal authentication credentials, and even bypass two-factor authentication mechanisms such as the ones implemented by Yahoo and Google. It can also hijack your Facebook account, or get your bank account credentials if you perform an online purchase. You can imagine such a plugin purposed to fulfill this or that feature (shim) and doing something nefarious behind in the background.


There are many different types of backdoors which an attacker could setup on a system. These include

Adding an account with administrative privileges.
Adding a daemon to a system which listens for connections, possibly on a high port, and provides remote shell access.
It could be software running on the system which calls out to a remote site for commands it needs to run.
Modification to existing system configurations or applications such that commands can be remotely executed.
Modification or addition of code to things, possibly a website, which would then allow remote code to be executed. PHP shells would be an example of this.
Modifications to documents that when parsed or opened allow for code execution or remote requests.
Etc... Possibly hundreds of other examples.

As you can tell not all of these would need to have a script involved and also most of these could be set up via the execution of a script or program. Your question is a bit broad as currently written (at the time I'm reading it) but hopefully this helps answer it.


Academic papers on GPU password cracking?

I'm sure a lot of article can be found on the web giving a clear explanation on how to setup a GPU password cracking system, but if you are looking for an academic paper, you can take a look at those reports :

http://staff.science.uva.nl/~delaat/rp/2010-2011/p11/report.pdf
http://www.inf.ed.ac.uk/publications/thesis/online/IM100812.pdf
http://mnsu.academia.edu/KhaiTran/Papers/1559507/GPU_-_accelerated_WPA_PSK_cracking_solutions

I think this blog post (not an academic paper, I admit), is quite complex and very interesting to read : http://mytechencounters.wordpress.com/2011/04/03/gpu-password-cracking-crack-a-windows-password-using-a-graphic-card/

You can also give a look at the Google Scholar page that will list some result regarding your research.


Is creating asymmetric keys dynamically and storing in memory safe?

Amazon has a couple of services that target this kind of use-case.
Amazon KMS is a key storage platform that integrates with AWS. You can upload keys to it and have your applications sign stuff via the sign API. This keeps the actual keys off your servers. Another benefit is that it integrates with all of the security monitoring and alerting in the AWS ecosystem (e.g. GuardDuty) so you can catch potential compromises and misuse of those resources.
If you're solely using this for authentication, though, you might want to consider Cognito instead. It supports both OAuth2 and JWT. This saves you the effort and potential security pitfalls of implementing your own integration with KMS.
Regarding key rotation, that's not something you should need to worry about all that much for this use-case, and you definitely don't want to be rotating long-term OAuth or JWT keys on a daily (let alone hourly!) basis. From a cryptographic perspective there's no reason to rotate OAuth2 signing certificates any more frequently than once every few years, as long as you use sufficiently strong keys, just like you would with HTTPS. The usual justification for rotating keys more frequently than that is to minimise the attack window in case of key theft, but if you don't detect the breach then an attacker can simply quietly sit on the server and obtain the new keys every time they are rotated. Automated key rotation also introduces a greater attack surface due to the additional mechanisms required. A better approach is to use existing solutions that have been implemented by and tested by security professionals, spend your time understanding their security properties and controls, and focus on breach detection and monitoring of security-critical resources.


Why do most browsers store browsing history by default?

There are a lot of advantages. Here are some:

Auto-completion of previously visited URLs you forgot, which can speed up the web surfing process tremendously. You might have remembered parts of a URL or website title, and your browser can usually pick those up if you typed them in. I love this feature.

This can offer extra security. As mentioned by kasperd, it can greatly reduce the risk of typosquatting.

Storing previously-loaded data in a cache to speed up web-browsing. Great for slow connections. Great for reducing load on web servers.
Storing cookies so websites remember your login information, etc.


How hacker/ others get your SSH private key / stole your SSH private key?

Private keys aren't any different from any other files, so any way for an attacker to get an arbitrary file from your PC is also a way for them to get your private key - provided it wasn't encrypted. This includes, but is not limited to:

Theft
Malware
Accidental Disclosure
Insecure Storage
etc.

Each of these issues must be tackled in isolation, and they may not all be of equal importance. For example, I find it very unlikely that someone would break into my apartment and steal my hard drive - but it is much more likely that my laptop is being stolen when I am travelling.
One thing that is specific to private key is that a lot of even tech-literate people do not know what public-key cryptography is and thus think a private key is "like a password, but it's a file". As such, when they are supposed to upload their public key somewhere (which is a legitimate and necessary for the process to work), they sometimes upload their private key instead.
Even advanced users occasionally fall for malware, depending on the situation. For example, a few years ago, a friend sent me a message through steam, just with a link to a file. I downloaded and opened it. Big mistake. This wasn't because I am somehow stupid (although people who know me would disagree), but because a handful of factors played together: I was busy playing a game, it was late at night and that friend happened to often just send me random links to check out. So it wasn't any behavior that raised alarm bells for me.


How CAs verify they are issuing the certificate to the correct party?

There are a variety of methods to prove that the requester of a certificate owns a specific domain.
Usually these are based on some kind of challenge given by the CA which the requester must somehow associate with the domain in a way that the CA is able to check this association. This might be an entry on a special place on the domains web site, it might be some DNS record for the domain, it might be that the requester is able to receive a mail with the challenge to a specific account on this domain etc.
While these kind of domain validation (for DV certificates) can be automated there are additional manual checks by the CA for EV (extended validation) certificates.
And with your specific example of youtube.com the situation is different: certificate for this domain are not issued by a public CA but by Google itself. Google has a sub-CA issued by a public CA and can use it to issue their own certificates. How exactly this is done is not known to me, but I expect them to use a very different process described than described so far because there is no need for them to actually prove the ownership of a domain which they own themselves.
Note that the process of domain verification is not fully reliable. If attackers can get control over the domain or parts of it even for a short time they might be able to create valid certificates for the domain which then later can be used in MITM attacks. This actually happened in the past.
For more information including the more technical details see Let's Encrypt Challenge Types,  How does LetsEncrypt.org's ACME work?, Please help verify my understanding of Domain Validation (DV) SSL Certificate.
Please also note the role of the (optional) CAA DNS records to restrict, which CA is even allowed to issue certificates for a specific domain. This somewhat addresses the risk that any CA can issue certificates for any domain.


Security concern for Single Sign On implementation

As the colleagues have pointed out, your SSO logic is sound here.
To improve it a bit and make it faster perhaps, you may end at Step 3 as long as you use the private key in Server B to validate the JWT generated by Server A.

Of course, we are assuming a few things here at each step, for example:

Encryption => we are assuming the whole system is using a robust encryption mechanism to pass these JWT tokens back and forth and are safe from prying eyes.
Server A and Server B validates input from each other - in other words, Server B does not implicitly trust that Server A will always send JWT tokens, because requests/responses can be intercepted.
Denial of Service Attacks - the system can fend off these attacks.
Speed - sufficiently fast
Alert admin of other security attacks


DataURL Browser Cache Security Implications

This depends an what you mean by "secure".
If the provider of the website does not enforce an appropriate cache policy, your data is accessible even after logging out of that service.
Is that a problem? Well it depends. If it's confidential data, yes.
On the other hand, even if the data was not be cached, you could store the data to disk while being logged in and use it later.
Either way you should prevent a third party from accessing any of your data by using encrypted storage (e.g. full disk encryption).


"Threat: WMA:Wimad [Susp]" on .avi file, possible to remove threat and keep file?

The "Wimad" family of trojan-horse attacks operate by using a normal feature of the "ASF" container format in an unexpected but not invalid way.  Consequently, any Windows software capable of operating on these files may be vulnerable, if it uses standard Windows libraries for manipulating them.  This may include Handbrake -- I don't know the details of how it operates.

The good news is that the attack is ASF-specific.  If you convert the media file to use a different container format, it removes the attack.


Question about handling credit card info in retail program

All merchants who accept credit card information must be in compliance with PCI-DSS.  This is true even if you pass the credit card information to another service for processing.  However, it sounds like you would qualify for minimal the compliance level ("Card-not-present Merchants,
All Cardholder Data Functions Fully Outsourced", or level A).  To see how you are doing, you can fill out the self-assessment questionnaire for level A, or SAQ-A.

  if an ecommerce merchant only accepts credit card payment via their website and does not handle, process and store credit card data by using an API like ours or a hosted page, the merchant can qualify for the SAQ A, the shortest of the four.

If you meet the minimum requirements of PCI-DSS, your program will be reasonably secure.


What are the consequences of not upgrading to the latest version of java?

There are a number of them, including those that allow arbitrary code execution.

From Qualys, on January 20 (last week as of this writing):

  Java: 19 vulnerabilities addressed in Java 8 and Java 7, 13 are remotely exploitable with highest score CVSS 10. This should be high on your list for your patching efforts, at least on the desktop where most of the vulnerabilities are aimed at. Only four vulnerabilities also apply to servers.

CVSS 10 means:

  they can be used to take control over the targeted machine, working remotely through a network and without requiring credentials

Precisely how these recently-patched vulnerabilities can be exploited, and their official names, isn't mentioned - assuming they have official names, as Qualys suggest they may include 0-day exploits. Oracle isn't giving many specifics.

Another, older vulnerability from 2013 also allows arbitrary code execution, via an Applet:

https://www.us-cert.gov/ncas/alerts/TA13-051A

So, the big risk is complete control of the target machine.
For end users, arbitrary code execution on their machine may result from loading a malicious Applet.


Should police departments recommend the securit.leadsonline.com website as a secure place to store information about our valuables?

You should most certainly warn your police department this is a bad idea. We are a facility in Florida who is being told by our law enforcement that we MUST report all our customers sensitive information (including ID, fingerprint, address, phone, and more) to this company. As constitutionalists we've been researching a legal leg to stand on against this requirement. The fact that their certificates are provoking warnings is all the more reason to be concerned.


How does nmap determine if it's running HTTP service on a port? Fails here

nmap defaults to the -sS option if a scan type is not specified. The -sS flag is a simple SYN scan to check the status of the port. No advanced fingerprinting is done to determine the service running on the port. In this mode, nmap merely looks up the most common service running on the particular port using the nmap-services file and displays it under the services header.

If you want more accurate fingerprinting to be done, try running nmap with the -sV or -A flag for version detection and aggressive mode respectively. The -sV version detection flag will instruct nmap to perform more intrusive scan types like making HTTP request to the port and reading the banner information for example. The -A flag goes a step further and attempts to scan the port with NSE scripts. Both the -sV and -A flag should identify Apache running on ports 8090 and 8095.


Should you notify software vendors that their software has been cracked?

All software vendors know their software can, and always will be cracked.  Software has been cracked for as long as there's been licensing or copy protection.  Cracking groups go back to the 1980s, and copy protection schemes went as far as punching physical holes in a specific sector in floppy disks.  That sector could never be written to on the original disk, and so if it an attempt was made to write to it, and it worked, you knew the software had been copied.  This was cracked, and the software copied and distributed across the country on BBSs.  Every software protection and licensing scheme that's been tried has been cracked.  Software licensing isn't meant to be 100% secure, it's meant to keep honest people honest.  That's it.

Should you tell them?  If you care about the software in question and want it to improve more, probably not.  Either one of two things will happen.  The vendor will (quite rightfully) ignore it.  Or someone at the company will have the idea that the protection needs to be "fixed" because someone has defeated it.  Needless effort will then be expended to create yet-another-protection-scheme, and the cycle will continue.

Either way, you're either wasting your own time reporting it, or the software developers time in "fixing" the cracked software.

By all means keep cracking software. It's an interesting game to play, and many have enjoyed jumping the fence just for the challenge.  But don't be under any illusions that you've found some critical flaw, that if someone just fixes, it'll be unbreakable again.


Bypassing Address Space Layout Randomization

ASLR is a defense-in-depth mechanism.  It is effective, but can be bypassed (the 2010 PWN2OWN contest break included an ASLR bypass).

ASLR's primary purpose is to defeat "ret-to-libc" attacks which are a mechanism of bypassing DEP.  IMHO ASLR is only really effective when bundled with other protection mechanisms like DEP (ASLR without DEP can typically be trivially bypassed).


SSL Certificate in my hosting makes me change my java code?

If you enable SSL/TLS on the server side, the client has to be able to "speak SSL/TLS" too. Otherwise, the connection will end up being reset.

Just changing a web-service to use "https" does not auto-magically change all applications communication encrypted. This is a shared protocol. If I suddenly goes speaking French but you only understand English, communication won't happen. This goes the same way for TLS.

If you enable TLS server side, you will have to modify you apps so that they can also use TLS. Fortunately for you, java has the means to deal easily with TLS using some already defined classes. Just look it up.

On the other hand, you can provide both TLS/SSl enabled traffic for the web (https url) and leave the simple http open as well. So that you can have your website using TLS and your app HTTP only. Then you can proceed to migrate your app over TLS before shutting down your HTTP only channel.


As with any password guessability/strength question, likely the most important factor is "who's the attacker".

For online password guessing attacks, by an attacker who doesn't know you, the most important factor is ensuring that your password won't be guessed before the account lockout kicks in.  For that as long as your password isn't in the top couple of hundred likely picks, you are likely to be ok.  Lyrics (especially ones from a song that isn't currently that popular) are very unlikely to be guessed here.

If you think about a scenario where a website you have an account on has been compromised and the password database is being cracked, well your account on that system is likely burned, so in terms of stopping the security of your other accounts being affected the most important factor is ensuring that you use unique passwords on each site you make use of.  If you can do that with song lyrics, you won't be affected by the compromise of one password.

If your looking at a scenario where the attacker knows you, things get more risky, especially if you've disclosed the scheme you're using.  It would be relatively easy to create a database of popular song lyrics and apply that to an offline password.  But what you've got to consider is, is anyone who knows you likely to do that... That's a risk decision only you can make.

Some practical considerations with this scheme.  You may well have problems using it on sites which enforce password classes (e.g. special characters).  You may also have problems with sites which enforce arbtrary upper limits on password length.


Is it bad if somebody gets a hold of my public root CA?

A public and private key used for encrypting that communication, only
  used by the specific device.

This suggests the private key is present on the devices as well. It has to be, otherwise decryption and signatures are not possible. It does pose a security major threat. Nothing stops someone from copying the private key, and together with the public key are worth a whole lot. Now, an attacker can sign new certificates, decrypt all traffic, alter data and so on.

  Again, these two can be revoked in a heartbeat without changing
  anything in the rest of the system.

Revocation is no rescue and you should be careful relying on this alone. CRLs are (almost) never checked realtime, and can be blocked by an attacker. You'll have to setup the entire OCSP (stapling) infrastructure before you can put some trust in a revocation solution. Same is true for the VPN certificates, probably worse since an attack could easily gain access to the server as well, causing even more trouble.

Encryption can help you. For example you can encrypt the SD card, then decrypt the card once when mounted. The key is stored in memory, which is not without problems either, but prevents someone from removing the SD card and read the confidential data. Obviously this only works when the device itself is 'secure' and cannot be accessed via other ports.

As an additional security measure you could require a stapled OCSP response every so many bytes/hours/days. If this window expires without confirmation of the certificate still being valid, then destroy the private key and notify an administrator.


How does LBaaS / DBaaS or "auto-scaling" help protect from DoS?

LBaaS probably refers to Load Balancing as a Service (LBaaS).

With an LBaaS solution, the traffic to your site will reach to the LBaaS endpoint and then handed off to the server farm serving the site. In an auto-scaled environment, the number of servers(typically Virtual Machines) go up or down depending upon the traffic load.

LBaaS solutions themselves integrate DDoS prevention mechanisms by monitoring packet states and other detection mechanisms. In combination with DBaaS and autoscaling, as the load goes up (in a DDoS scenario), the backend instances scale up as well to handle the additional load.

This of course does not assume that the Anything-as-a-service solutions can handle infinite load. That is, a service supported by the cloud cannot take DDoS attacks of the scale of Tbps (as have been recently demonstrated).


What does it mean to get an email from someone with a different actual sender?

It is still easy to spoof mail, as explained for example here and here. Which means your question basically asks how the sender got the combination of sender and recipient address in the first place.
While you suspect that the spammer got this combination from a compromised client and hopefully not from compromising your server it is impossible for us to say just based on this information where the spammer got these addresses from. There is no kind of identifier in a address itself which provides this information and all what you have are these addresses. And apart from the possibilities you've mentioned it might also be possible that the addresses where collected from public mailing lists or forums.


Why can't we block DNS Amplification attack by blocking UDP packets or DNS response packet?

We can but...

At the point the query makes it to your server it's already too late. Your server will waste its resources trying to do something with the packets and the requests. Even if you have something like iptables drop all connections it's still going to use up all of the bandwidth on the server inbound. Redirecting all traffic someplace else eats up your outbound bandwidth and propagates the network failure between your server and the now new target.

It's a network infrastructure issue. Not a server issue (unless it's an open recursive resolver). The traffic needs to be handled (killed) further up the pipe. Here's a CERT advisory from March 23rd.

  Unfortunately, due to the overwhelming traffic volume that can be
  produced by one of these attacks, there is often little that the
  victim can do to counter a large-scale DNS amplification-based
  distributed denial-of-service attack.  While the only effective means
  of eliminating this type of attack is to eliminate open recursive
  resolvers, this requires a large-scale effort by numerous parties.

Additionally

  Source IP Verfication: Because the DNS queries being sent by the attacker-controlled clients must have a source address spoofed to
  appear as the victim’s system, the first step to reducing the
  effectiveness of DNS amplification is for Internet Service Providers
  to deny any DNS traffic with spoofed addresses.


DKIM signs the From: header and optionally other headers.  You can specify which headers in the DKIM header itself.  The envelope From isn't signed.  DKIM and SPF are both used as one means among many when evaluating if a message is spam/a joe job.  Bear in mind that you are trying to do exactly what spammers do - send e-mail from an address that isn't yours so you are likely to get blocked by things designed to catch spammers.


What hardware do I need to monitor mobile traffic?

There are at least two options, dedicated commercial hardware about which I know little (Nexus Telecom is one vendor) other than it's improbably expensive; and the CCC method: https://svn.berlin.ccc.de/projects/airprobe/wiki/hardware (site uses a CAcert.org signed cert).

It seems you can get off to a good start with GNU Radio and a USRP board (sub $1000).


Why does Digicert have so many Root Certificates? Which one is right for me?

Which one is right for me?

This depends on your specific but unknown use case. You need to add a new root certificate only if you need to verify certificates which were directly or indirectly issued by a yet untrusted root certificate.

Note that adding a root certificate does not help in the common case of a misconfigured server which fails to send the intermediate certificate.

  Why are there so many?

Some of these root CA come from acquisitions of other CA like CyberTrust. Some are used for different purposes - like issuing normal certificates vs. issuing EV certificates. Some have different types of keys, i.e. RSA vs. ECDSA.


How to secure android REST basic authentication credentials against reverse engineering?

The best practice is to not store the access credentials within the program. Apps do not always contain (unless they are badly designed) any specific credentials within themselves to access the API.

While adding credentials into the code may deter general attackers it will not stop attackers who can open up the package and extract the details. As something that can be cracked by a few is considered vulnerable too the right way to implement it would be as follows.

Add not credentials into the APP
When the APP is installed generate credentials and register with the server. (could be username and password or could be a client side certificate)
Obtain an access token using these credentials.
Use the access token to access the API

As you can efficiently control the registration process and can permit access to secure parts of the API based on the access token your implementation should be secure enough if you use SSL/TLS for them.


Should the password of a password protected channel be hashed?

Personally, I don't see a reason why the password should be hashed, because when setting the password, it's absolutely clear that other people will need to know it.

Then why bother storing the password at all, just let anyone in! ;)

If you are storing a secret, it's because this secret identifies a subset of your total users. Not all your potential users know it. Now, you've probably been told that passwords must be stored hashed and salted. This is a password you're dealing with. I'll let you draw the logical conclusion.

Maybe the same group uses it to access a SharePoint which occasionally contains sensitive information. Maybe they use it for their group calendar which reveals when their office is empty or when they travel away from home. Maybe the person who created an account was so out of clue she used a password otherwise valuable to her personal assets. Maybe they just can't deal with the amount of credentials they have to handle and that alone explains the reuse.

Don't be the person who's responsible for causing harm to others out of sheer negligence. Hash them (with a slow password hashing algorithm). Salt them (with a unique salt per password).


Does GRE Tunneling support the Websocket Protocol?

GRE is a tunneling protocol at the network layer (OSI layer 3) and thus will transport everything above it, which includes TCP (layer 4) and HTTP (layer 7). And since WebSockets are just some kind of tunnel inside HTTP it will transport them too.


Practical benefit of using SqlCredential vs username/password in connection string

I'm not a .net developer, but Java is very similar.  I believe the use-case of SecureString, and SQLCredential is for any password that isn't long lived.  i.e. you log into a remote SQL Server briefly, and then drop the connection and go on with anything else the app has to do.  Using SecureString would appear to remove this briefly used password from memory ASAP rather than wait for it to be removed at a (possibly much later) time.

From your description your application uses a persistent database connection, and likely a database connection pool.  So you need the username/password to be in memory all the time.  There's little or no benefit to removing the password from memory since it'll be loaded into memory again very shortly, and ultimately is stored in some config file anyway.

As far as questioning your own thinking, it's good to do this, but don't give experts ultimate authority.  They can't know your specific situation.  I'd advise caution when reading generalized advise.  It may or may not apply to you.  In this case, Microsoft has to give a broad based answer that applies to everyone, in a wide range of uses.  Microsoft has to advise anyone developing .net apps on the desktop as well, which could include a user simply typing in a password.  Desktops have an entirely different threat model than servers do.  For a desktop user who entered in a password once in the morning and dropped the connection, it would be "bad" if that password lived on for hours afterward, and the machine was then compromised by some completely unrelated security hole.

In other words, it's a "best practice" to just tell everyone to use SQLCredential rather than try to explain everyone threat models, etc.  Most people aren't going to go to the depths of understanding you're looking at.


How can I decrypt ADFS-based SAML/p or WS-Trust claims?

SAML tokens, if they are encrypted, are encrypted against the X509 certificate of the relaying party, either the public HTTPS certificate, or an agreed upon certificate between the STS and RP.

So you'd need to private key for that certificate to decrypt.


You won't see anything relevant in Wireshark because the communications between WhatsApp users happen using private and public keys. Here's how it works in practice:

A wants to send a message to B.
A firstly asks B for his public key (every user generates around 100 public keys attached to one single private key).
A then encrypts the message using B's public key and sends it.
B recieves it and, using his private key, decrypts it.

So, without breaking this scheme, you won't be able to read those packet's data.

In case you are just analyzing TCP, you will be able to see the handshake as usual with it's ACKs, FINs, etc.


Double hashing passwords between Java microservices to increase security?

I do not see a problem with double hashing per se, but there are some trade offs to doing it this way.  First and foremost, if an attacker is able to steal a hashed password as described, there is nothing preventing them from cracking that hash, and just using the password like a regular user.  Secondly, if you need another service to access the IAM service, you would have to perform the same two-step hashing.  Your solution becomes much less flexible at that point.


I believe you have an error.
Each password key is not derived by applying a function that is based on a single hash in wp/wpa2 but rather several rounds of PBKDF2 (4096) each resulting to several hash invocations.

Therefore I believe the costs should be higher.


Encryption and Signature with same RSA private key

I suppose that you are talking about SSL. A SSL server supports several combinations of cryptographic algorithms called cipher suites. In particular, a given SSL server may support either or both of these key exchange mechanisms:

RSA: the server has a RSA private key; the client generates a random value (the "pre-master secret") and encrypts it with the server's RSA public key; the server decrypts the received value to get the pre-master secret.
DHE_RSA: the server has a RSA private key; the server generates a new random Diffie-Hellman key pair, signs the public part with its RSA private key, and sends that to the client; the client verifies the RSA signature (using the server's RSA public key) and completes the DH key exchange. (Variant: ECDHE_RSA: same principle, but the DH is done over an elliptic curve.)

So indeed, a given SSL server may potentially use the same RSA private key for both encryption (when using a RSA key exchange) and signatures (when doing a DHE_RSA key exchange). Note that the server may perfectly well have two RSA keys, one dedicated to encryption (RSA key exchange) and one for signatures (DHE_RSA key exchange); people just do not do that on a regular basis because having two distinct keys implies buying two distinct certificates.

In all generality, the same key should not be used for both encryption and signatures. Note that a big source of confusion is that RSA encryption and RSA signatures are two distinct algorithms, that just happen to use private keys that have the same format, and people found it smart to call both of them "RSA".

The two main reasons for not using the same private key for both encryption and signatures are the following:

Interactions between the encryption and the signature algorithm are not well-studied. There could exist some method that leverages encryption to forge signatures, or signatures to perform an underhanded decryption. In the specific case of a SSL server, it is usually believed that there is no such interaction, notably because when the server decrypts, it does not advertise the result back to the client, and also because when the server signs, it does so over a DH public key that the server generated itself, not over data sent by the client.
Normally, encryption keys and signature keys call for distinct life cycles; encryption keys should be escrowed, and signature keys must not be escrowed (see this for some discussion on the subject). Again, in the specific case of a SSL server, you do not need to escrow the RSA private key because the encryption is transient (data is decrypted when it arrives, not stored), so it is possible to manage the server's private key in a way which is fine both for an encryption key and a signature key.


PostgreSQL exploit not loading in MSFConsole from ExploitDB

There are a couple problems with what you are trying to do to use this exploit.

First, while Metasploit is an exploitation framework that any exploit could be ported to, it requires modules to conform to a few specifications. As far as I know, all modules must be written in Ruby, and need to contain configuration parameters and standard functions so that the framework can operate on it. The "exploit" linked above was certainly not designed for Metasploit, which brings us to the second problem.

If you look at that "exploit" file, not only is it not a valid Metasploit module, but it is not even a script or code at all (hence the .txt extension). The file's purpose is to tell you how to test the vulnerability manually and is not meant to be run in any way.

So, if you really want to use that exploit with Metasploit, you would need to write your own module for it.


Is it possible to detect VPN in the network?

The OpenVPN protocol makes no attempt to hide its presence. The protocol itself is briefly described at the end of the documentation. Note that, even if you manage to obfuscate the protocol itself, it is possible for your ISP to determine that you are using a VPN using traffic fingerprinting. Not to mention, the fact that you are using some sort of tunnel can be inferred from the behavior of only connecting with an encrypted protocol to a single IP address for all of your internet activity.
Traffic obfuscation
There are two primary ways to prevent the protocol from being immediately tagged as OpenVPN traffic, however both methods do not defeat advanced traffic fingerprinting. Additionally, both of these methods require support from both client and server, so random commercial VPNs are unlikely to be compatible with this. The two main ways to limit traffic identification are:

Static keys - Normally, OpenVPN establishes a TLS connection with the remote server to exchange temporary session keys which are then used to encrypt the VPN protocol. This key exchange gives away that OpenVPN is being used. Static keys are pre-shared keys that are stored on both the client and server. If they are delivered securely to both sides, then that key can be used directly to encrypt the VPN traffic without any key exchange. Unfortunately, static keys necessarily mean you will lose the cryptographic property of forward secrecy.

Obfsproxy - Developed by the Tor Project, obfsproxy is a type of pluggable transport that transparently obfuscates traffic using a variety of methods. It is designed specifically to make it difficult to identify the protocol being used in order to hamper automatic blocking. While originally designed specifically for Tor, obfsproxy can be used with OpenVPN.

No matter what you do, you will very likely not be able to prevent someone who is analyzing the traffic from discovering that you are connecting through an encrypted tunnel of some kind. You may be able to hide that it is specifically OpenVPN traffic, and you may be able to fool automated machine analysis, but not actual human analysis of the traffic itself. Keep that in mind.
Threat modeling
You should formulate a threat model. Ask yourself why you want to hide the existence of the VPN (avoiding so-called membership attribution). A few general threat models:

Avoiding censorship - In some regimes, VPNs are blocked either voluntarily by ISPs or due to extensive government censorship. You may want to obfuscate the protocol in order to bypass the filters and gain unrestricted access to the internet. For this threat model, you need only go far enough to prevent automated detection. If simply running the VPN on a different port is enough, then do just that. If you need to fully obfuscate the traffic to avoid DPI, then do that instead. There is no need to make it hard for human analysis to discover the traffic because no one is going to be monitoring it in real time and actively allowing or blocking a given resource.

Looking inconspicuous - You may opportunistically want to give away as little information as possible to your adversary. While giving away all your unencrypted traffic is even worse, why not reduce the information even further and hide the fact that the traffic is encrypted? If your adversary is using automated logging to detect VPN traffic, the solution is the same as the one for avoiding censorship. Simply change your traffic just enough to get past the machines, and you are home free. If you want to protect against manual, human analyists, then you're out of luck, unfortunately. There is no practical way to hide that you are using an encrypted tunnel of some kind to a sapient and educated adversary with access to traffic logs.

Avoiding legal issues - In some jurisdictions, the mere use of an encrypted tunnel of any kind can be flat-out illegal. In cases where the penalties are high and the laws are actively enforced, you have a much bigger problem. You should avoid all government-run or sympathetic ISPs. This means using underground networks or wireless networks from nearby countries. You should also either hire a lawyer to get professional legal advice, or at the very least ask some questions on the Law Stack Exchange. While they do not provide legal advice, they can answer certain questions and cite relevant laws to help you improve your understanding.


Is bypassing my VPN and seeking my IP address hacking?

You used a VPN. You hoped that the effect would be that you could hide your location and IP. There are lots of ways that websites can determine your real IP, and they are not considered hacking.

What you need to do is to harden your setup to make it harder for these "de-anonymizing" techniques to work.


Distributing public keys; with or without a sub-key?

Advantage of Using Subkeys

Using subkeys has the main advantage that in case you have to revoke them, you're not losing all reputation in the web of trust do not have to exchange new keys with other participants you're communicating with.

For example, if you stored your subkeys (and your public primary key, not your secret primary key!) on a mobile phone which you lost, you can easily revoke this subkeys and create a new key pair; all others just have to fetch your updated primary key to get aware of them (and possibly don't even realize).

If you had put your primary key on your mobile, you had to issue a completely new set of keys, get everybody aware of them and start again in the web of trust (having all certifications lost).

Algorithm Choice

Another reason for subkey usage are algorithmic limitations. While RSA can be used for both signing (certifying) and encrypting, and you don't have to use subkeys for encryption, some algorithms are only capable of one of those. For example, DSA (Digital Signature Algorithm) can only be used to issue signatures and requires another algorithm for encryption, usually ElGamal is used here (which again cannot be used for signing).

Further Information

At least GnuPG automatically creates subkeys

In generally recommend reading Debian's discussion of subkeys, I also answered a slightly related question. Finally, have a look at the offline key section of this answer.


Does visiting the localhost with my Tor browser reduce my security?

It probably wouldn't work. If you told the Tor exit relay, "I want to go to 127.0.0.1" (that's the IP of localhost), it would try to connect to itself, because that's what that IP means. Unless the exit relay had a web server running, the connection would fail. I wouldn't be surprised if the Tor software checks for loopback IPs and rejects the connection.

It's entirely possible that Tor will just connect you directly to yourself. If that happens, there's no harm done because no traffic leaves your machine. (Unless you're running a malicious deanonymizing site on your computer that sends your IP to shady people.)

If localhost is somehow magically changed into your external IP before being sent through Tor, you're still fine. Unless you've made a firewall rule, configured your web server, and set up portforwarding from your external IP to your computer, the connection will fail. If it did go through, no node on the way would have any idea that you just talked to yourself, since only the entry guard knows the source and only the exit node knows the destination.


TOTP is indeed a time-based variant of HOTP. In both cases, the sequence of possible passwords is derived from a secret key, and a "changing value". With TOTP, the "changing value" is the current time, which both ends of the protocol supposedly know (current time is public knowledge). In HOTP, the "changing value" is a counter, which is incremented after usage. Both parties (client and server) remember the last used counter value.

If the client and server become desynchronized (e.g. the client sent a password and incremented its counter, but a network issue killed the connection and the server never received it), then there is a process for resynchronization: upon receiving a password, the server compares it not with the next password (according to its counter), but with the next 100 or so passwords, thus allowing for a counter desynchronization of a 100 or so.

This mechanism is well suited to car keys, which:

Do not have a common source of time (no clock in the key).
Need to work with a unidirectional communication (from key to car, not the other way round).
Have a "manual resynchronization" if they got badly out of sync (your 3 years old nephew played with the key for an entire afternoon, getting the key counter way beyond the car counter, even with the +100 offset; you can no longer open the car remotely; but when you ignite the engine, the car and the key communicate through short-range RF to reset the counters).

As for code, a simple google request on "hotp php" points to this and that.


What is the current state of author recognition software and what can be done about it?

So how reliable is this nowadays ...

Without looking at recent papers but just based on how machine learning works in general: there is no generic authorship detection method which fits all possible use cases. Instead what is possible depends a lot on the specific use case and on the available data.

If the use case is to determine the author from a group of 10 possible authors and you have sufficient training material the detection is to be expected very reliable. If you want to detect instead who of 100000 people was the author I expect it to be impossible even with sufficient training material. But you might at least be able to narrow down the field of potential suspects to a few 1000. Only, in many cases you will not have enough training material even for this.

On the other hand if the author has a very unique style of writing it makes it again easier to detect it. Or in other words: it is far easier to associate some good written essay with J.K.Rowling than the usual average quality essay with some specific 14 year old kid.

It also depends on the kinds of text: a book is different from an article in the newspaper is different from an email is different from a twitter message. Not only the length differ but also the amount of time which was used to improve and tailor the wording and style. It is probably easier to detect authorship of books than of emails since the authors unique style is more clearly reflected within the book.

I'm at least familiar with recent research where machine learning was used to determine if a specific email was authored by the claimed sender in order to detect sender spoofing or account takeover. In this case even with a large corpus of previous mails the false positive rate was very high.

  ... what would be appropriate measures to take against it?

Again this depends on the use case. But similar to transferring the style of images or of music or creating deepfakes it is possible to use style transfer with texts in order to hide the real author or even fake a specific author. And of course making only few data available for training helps a lot too.

Anyway, I think in most cases authorship attribution will not be done based on the writing style but on the contents of the text. Especially in case of government critics or whistleblowers these texts usually contain information only few know in this detail - because otherwise these texts would usually not be seen much as a problem. Thus the focus of investigation will be to find out who has this particular knowledge or had access to specific leaked information.


Is time zone information saved in files?

It depends. If you're transmitting the data over the internet, such metadata is usually not preserved. If you hand over a USB stick, the "Last Modified" and "Date Created" fields might give some indication of timezone if you know what local time the files were modified / created - just a simple subtraction will work. The same goes for RAR archives, which preserve that metadata in the file table.

I'm not aware of any archive formats or filesystems that store the timezone as part of the timestamp metadata.


Would 'zero-knowledge' requests be an secure extension of SOP/CORS?

No, they would not be.

Your assumption

  CORS exists to prevent authentication to trusted domains

is wrong. Why? See my answer on this question


Is it okay/safe to mention/display information about the example format of user Login ID on the website?

The short answer is that yes, an attacker would benefit from knowing the format of your usernames if they are going to attempt to launch an online guessing attack of likely username/password pairs against your system.  But this may not be a risk you should worry about.

The long answer is that you need to judge the value this practice provides you against the risk.  Our industry has generally embraced the idea that while usernames should not be easily disclosed to attackers, knowledge of a username alone should not grant access to user accounts.  Accounts should primarily be protected by a password or other authentication factors. There is a faction that believes the username should be more secretive to further decrease risk, but this idea hasn't been embraced by most system owners.

So by disclosing the format of usernames you are merely giving an attacker seeking that knowledge a slight advantage.  They still have to take the info that usernames are in a certain format and apply it to their guessing process.  Hopefully the username format itself isn't risky (e.g. not 'user1', 'user2', etc.) and you aren't trying to obscure that fact to avoid attacks against it.

Presumably you ask because you or someone else sees a benefit in publishing this information on your site to begin with.  Whether it's to help users through the account creation process or something similar, you may need to communicate your standard to them.  If not, then you can easily decide to remove this info from your site.  But if so, you should weigh this benefit against the low risk incurred from the practice and decide if it is worth it.

I see similarities between this and disclosing your password policy.  Yes, knowing passwords must contain uppercase, lowercase, and numeric characters can help attackers.  But it doesn't tend to help them very much.

Personally, I wouldn't worry about disclosing the username format.


I believe you are referring to this vulnerability:
https://www.cvedetails.com/cve/CVE-2004-0339/

If we look at the details of the advisory, we see that the payload is slightly more complicated than the way you're trying to exploit it:

http://marc.info/?l=bugtraq&m=107799508130700&w=2

In this advisory, the (URL encoded) payload is:

'"><script>alert(document.cookie)</script><'

This is because the payload will be pasted inside of href="[your payload here]" in an a-tag. So if you try to inject javascript:alert(1), it will result in href="javascript:alert(1)". Maybe if you click on the link you will see the pop-up box. However, you can also break out of the href like in the example from the advisory, executing code the moment someone visits the page.

Do note that you need to use a browser that doesn't automatically reject xss, like Nipun suggested.


public key distribution from a central server

It's not possible to exchange public keys over an untrusted channel without the help of a trusted third-party. Even STS assumes that either: a) the public keys were exchanged in advance; or b) certificates are used to help establish key trust (so either a CA, Web of Trust or similar is needed). In your scenario, you're acting as the trusted third-party, asserting to each user that a given key belongs to him/her, and that you're not secretly performing a man-in-the-middle attack (sometimes called institutional MitM). In other words, you're correct in your assumptions.

I'd suggest looking at this answer for some insights on the subject of public key trust. I'm afraid there's little I can suggest you in order to improve over the existing models though...


Could a workplace install a custom bios that gives them access to the system?

Absolutely. Some corporate systems come pre-installed with BIOS-level access that is not dependant on the hard drive at all.
Computrace by Absolute is one such example.
If you try to enter the BIOS, you should have an indication of whether that's true and what type is being used.


Apache Access Log Indicates DOS Attack? Or any other attack?

That's something what you have to expect when you run own server. Those logs are normal in a way that attackers are trying to find those directories and furtherly gain access to the server or running web application.

If your server is properly configured & secured, you don't need to worry about those logs.


Can a usb drive infect a hard drive without an OS

It depends on what stage of the boot loading or fresh new installation point you are on in the BIOS.  From what I am reading, it seems you are only at the "reboot and select proper boot devices" screen.  This is typically a BIOS screen that is part of the BIOS which is typically located in the small boot partition or a BIOS flash chip.  The BIOS on many modern day computers, especially those that are designed to come with Windows 10, usually are called UEFI and are different than BIOS from the past.  Modern day computers  also have a TPM chip on the motherboard.

From an external memory interface like a USB, the UEFI can be infected although the likelihood of that happening depends on where the USB came from and where did the image of the OS on the USB came from.  As long as the first two came from legitimate means of obtaining, I do not think there is any need to panic.

If TPM is already activated on the system, then any attempt to infect the UEFI would be useless as the computer will not be able to start.  The TPM is an embedded chip on a computer that has a purpose of security, where everything is signed via a RSA key that is not accessible and is only stored inside the TPM module.  Any changes done to the system firmware that causes the signature to be faltered will cause the TPM module to stop the computer.  However many manufacturers have TPM disabled by default, this is because it delays the boot/startup process as everything has to get checked by the TPM module.

Regarding the SSD, because it is a fresh SSD there is no data on it at this time.  If it does get infected, as long as the BIOS is not infected, doing a clean install from an external drive in BIOS can clean and thus remove the infection on the SSD.

From your question, I am not sure if you are just asking or you really feel that your USB is infected.  Is the USB device showing in the selection list?  Doing a misstep in the burning an installation image via official steps recommended by Microsoft, in my opinion would not cause the USB to have a virus.  Just the image on the USB may be corrupt.  A corrupt OS installation image is not a virus.


Shared floor space, cameras and HIPAA compliance

It's a HIPAA violation if the tech support team can even see the monitor screens. The cameras make it even worse.

What makes it worse is that they are separate companies using a shared work space.  I think auditors would have a field day with this situation.


Can Restarting An Infected Computer Make It Worse?

It depends on the type of malware.

If it is ransomeware shut it down as fast as you can preferably by hard reset this way it may not have been able to encrypt some files and you can grab any files you need off of the hard drive.

If it is a rootkit, shutting down is a horrible idea because the rootkit has set hooks that allows it to climb through rings on the next reboot. Theoretically a rootkit cannot reach ring0 (kernel level) without a restart. (Contrary to some comments above. You'd have to be crazy to try to modify a kernel while it is in use.)

Use how the malware works to determine if it is safe to power off/reboot.


Should you use SecureRandom.getInstance() with or without a provider?

This is a question inherently about trust of a cryptographic API, and is not really specific to SecureRandom. I will still formulate my answer around SecureRandom as it makes a good illustrative example.

Who do you trust more, the people who wrote the code of the API and documented it, or random comments on the web ? The developers made choices so you do not have to make them, because they have a better understanding of the stakes and issues than the common user of their API. For the sake of flexibility of their API, the developers allowed users to override their implementation decisions. You should do so only if you are sure to know better than them.

SecureRandom tries to use the best source available, usually one provided by the OS. Since you do not have the expertise to make a better choice (otherwise you would not have to ask your question), you should roll with the default, and handle exceptions appropriately (for example by refusing to provide an insecure service).


How to protect ourself to divulge information

Any setup where you actually don't know the passwords works to achieve this. The most commonly used way is to have a password manager like LastPass, 1Password or KeePass which generates long random passwords for each unique service and store them in an encrypted file.

Of course this encrypted file requires a password but it also requires the attacker to have the password file which, as mentioned in the comments, could be destroyed or securely hidden.


Yes, it's a good plan, but there are still a number of potential vulnerabilities.  Really, the only attack that you're mitigating is the attack you mentioned, the ability to grab the cleartext data with an arbitrary SQL statement.   You're not mitigating any other attacks, for instance, a malicious user who uses SQL injection to elevate their privileges within the application so that they can view a pages where the application expects to display this date in cleartext.

So, the real solution is defense in depth.   This is a fine part of that solution (and indeed sensitive data should be encrypted at rest) but in order to effectively protect it you also need additional safeguards, such as:

General SQL injection protection strategies such as only allowing access to the application user via parameterized stored procedures and denying access to the underlying tables completely.
Protection against attacks relying on arbitrary code upload and execution
Protection against XSS and session stealing attacks that might allow a malicious user to capture authentication cookies from an administrator.

The data is only safe as the weakest link in the overall application security, so remember that direct attack on the data itself via SQL injection is not the only thing you need to think about in order to protect it.


You can generate a session key and store it in a cookie client side which is contains a session token to authenticate the client to the Proxy (yes proxy!). (do make sure it's sent over HTTPS as otherwise it's completely useless)

The proxy does bring a limitation when it comes to other types of traffic such as SSH (taking out of scope that your users know how to tunnel traffic over HTTP). To solve this problem you can step away from the whole 'captive portal' story and try another authentication method like PEAP.

Note that setting up a good way of authentication is not easy as there are many ways of bypassing captive portals. Some are for instance:

DNS Tunneling
ICMP Tunneling
HTTP Tunneling (if you want to disallow
...

Securing these is not easy and not all captive portals can be secured equally well. My preference is EAP-PEAP or EAP-TTLS.


Is it secure to have an iPad app run a webDAV server on localhost without authentication?

This is mostly secure.

To intercept localhost traffic an attacker would need root privileges and at this point you've already lost as the attacker can also read and modify memory at will - no amount of cryptography will help you as the attacker will get your confidential data straight out of memory.

The only issue I see is that you can't prove it's indeed your app that you're talking to. What if another app suddenly starts a server on the same port ? To mitigate this you'd need to generate a key and a self-signed certificate on the first run of the app, and make whatever other browser/app that talks to that first app trust the cert. If some malicious app starts a server on the same port, it wouldn't be able to impersonate your real app.

Finally this seems like a crude way of doing IPC between apps - why not rely on what the OS already offers like App Groups - if you're the developer of both apps you can make them share the same group so they have some way of doing IPC as well as having shared storage :

  Use app groups to allow multiple apps access to shared containers and allow additional interprocess communication between apps. To enable app groups, in the Capabilities pane, click the switch in the App Groups section. You can select existing app groups from the table or add app groups.


The Change Cipher Spec message means: from now on, records will be encrypted with the newly negotiated cipher suite and keys. So all subsequent records will be encrypted, and that's what you observe: an encrypted record. Of course you cannot see the contents: that's the point of encryption.

Right after the Change Cipher Spec follows a Finished message, which serves as confirmation that the handshake worked properly. The raw contents have length 12 bytes, and are computed as a sort-of hash of all previous handshake messages. These 12 bytes will be encrypted, which entails adding the record MAC value, then possibly some padding (if using a block cipher in CBC mode).

For instance, if, in your example, you used a cipher suite with 3DES in CBC mode as block cipher, and SHA-1 for integrity, then 20 bytes are appended for the MAC, then between 1 and 8 bytes for padding, so that the total length is a multiple of 8 (3DES uses blocks of 8 bytes). This yields 40 bytes, and that's precisely what you observe.

See the standard, in particular section 7.4.9 for the Finished message; see also this answer for a walk-through of SSL/TLS.


Can CVE-2015-4852 be exploited against WebLogic servers after a load balancer?

Ok, Let's get to the point: vulnerability CVE-2015-4852 is not about the T3 protocol. The problem lies in the serialization/deserialization routines used by WebLogic and the underlying libraries that compose the java classpath.

So, just to make a few points clear:

The T3 protocol is cited because it is a point of entrance to
user-provided serialized data.
WebLogic is cited because it comes bundled with the affected Apache Commons
library and it is loaded in the classpath when WebLogic is run. It needs to be updated so that the affected bundled library can be updated too. Or you could update it yourself.
The real problem lies within the Apache Commons library itself.

Therefore answering to your question, yes, your application still might be affected by deserialization vulnerabilities if the attacker is able to find somewhere else to enter serialized malicious data. Some Java applications rely heavily in serialization. Lots of them also send it through HTTP/S connections being base64-encoded or with some other type of encoding. Java JSP applications also make use of Viewstates (base64'd too, although it uses a structure that differs from ASP.NET Viewstates).

I've even seen Oracle's HCM (Human Capital Management) module use base64-encoded serialization to define a page title (yes, i was able to change it to whatever i wanted, but by the time a examined it, i wasn't much aware of the inner workings of deserialization flaws)

UPDATE:

There has been some development on this issue. Not in this CVE itself, but some folks found out that there are more libraries (very common ones also) that are vulnerable to the whole serialization/deserialization matter.

http://www.theregister.co.uk/2015/12/07/java_deserialisation_research_library_vulnerable/


Integration with CCAvenue payment gateway

PCI DSS 3.1:

  PCI DSS also applies to all other entities that store, process or
  transmit cardholder data (CHD) and/or sensitive authentication data
  (SAD).

So, if your web application is accepting credit card details from a customer, and then retransmitting them to your payment gateway, then you are subject to the PCI DSS and must fill out a Self Assessment Questionnaire (SAQ) or be audited (depending on volume).  It does not matter if you are not logging the card details; if they are transmitted via your server then you are in scope.  Even if your web page merely has an iframe so that your customers can enter their data directly into the payment gateway, you're still in scope.

There are different SAQs depending on how much you deal with card data.  The simplest is SAQ-A (used for the iframe solution mentioned above) or SAQ-A-EP for other types of redirection.  If the card data flows through your server you're looking at SAQ-D.  Here's a good link describing the nuances of what setups lead to which SAQs.


Best way to secure Wi-Fi Direct connection

The simple answer is do not use WPS as it is vulnerable to the reaver attack.

This greatly reduces the amount of time needed to bruteforce your passpharse.


Session fixation attack, cookie based sessions over https

For every session fixation vulnerability the attacker must know the session identifier. There two ways to ways to obtain it – by stealing it from victim’s PC and through brute-force attack.

Httponly attribute protects your cookie against XSS attacks using browser same-origin policy, but there are many other ways to access victim’s PC and steal the cookie, including vulnerability exploitation in victim's browser.

Unfortunately I’m not familiar with CAS and do now know for how long the session id is kept unchanged. If your server keeps using the same session id for a significant amount of time, then it is possible to brute-force/predict it. This is where the session fixation becomes dangerous.

My advice is to generate new session token every 15-20 minutes for active sessions as well. This way it will be extremely hard to brute-forced it and your application will be protected against session fixation attacks.


Most websites intended for a general audience will want to select TLS versions based on security and browser compatibility. If you have guarantees that the clients used to connect to your website will be reasonably up to date, you may be able to depend on TLS1.3 alone.

The optimal configuration for your website will depend on a number of parameters, and the configuration will need to change over time as support for stronger protocols and ciphers is added to browsers. Likewise, you will want to disable less secure protocols and ciphers as vulnerabilities are discovered or they become disused.

Security Considerations

Newer versions of TLS provide fixes for known vulnerabilities in older TLS versions.

Specific vulnerabilities in TLS1.1 have already been discussed. For instance, a countermeasure to the Lucky13 attack is to use AEAD ciphers which became available in TLS1.2.

TLS1.3 removes support for a number of weaker ciphers and hash algorithms while adding stronger ciphers.

Compatibility Considerations

At this time, TLS1.3 is supported by the browsers of ~81% of global users, which is likely not enough to rely solely on TLS1.3.

You will likely want to additionally enable support for TLS1.2, which is currently supported by over 97% of global users. Depending on the specific demographics and requirements of your websites, you may want to disable support for TLS1.0 and TLS1.1 at this time (as many websites have already done).

Client Support

According to Can I Use, current global support as a percentage of users (as of January 2020):

| Version | Global Support |
| ------- | -------------- |
| TLS 1.0 | virtually all  |
| TLS 1.1 | 97.43%         |
| TLS 1.2 | 97.35%         |
| TLS 1.3 | 81.08%         |

Most popular browsers are phasing out support of TLS1.0 and TLS1.1 in 2020. (Source)

Server Support

Server support, as measured by Qualys SSL Labs (as of December 3, 2019):

| Version | Server Support |
| ------- | -------------- |
| TLS 1.0 | 63.4%          |
| TLS 1.1 | 73.7%          |
| TLS 1.2 | 96.2%          |
| TLS 1.3 | 17.0%          |

Many websites have already disabled support for TLS1.0 and TLS1.1. Some users with outdated clients that do not support TLS1.2 are likely receiving error messages when viewing such websites.

Other Notes

Newer TLS versions also add features that you may want to take advantage of.

TLS1.2:

HTTP/2: TLS1.2 is the minimum TLS version for HTTP/2, which provides additional features to speed up page load time.

TLS1.3:

Faster handshakes: TLS1.3 will reduce latency in establishing a secure connection.
Forward Secrecy: In TLS1.3, all ciphers support ephemeral key exchange. This helps to maintain security of previous connections even if your server is compromised (or, in this case, your CDN is compromised).

For optimal security, you will want to tune additional parameters for your websites. Qualys SSL Labs can help you discover and tune these settings for additional security. To name a few, consider configuring HSTS, downgrade prevention via TLS Fallback SCSV, and forward secrecy. You may not be able to control all of these settings via your CDN - some may need to be configured on your servers.

Also, do not neglect the TLS configuration of your own servers as your CDN will establish an independent TLS connection to your servers.


Are the iPhone "connect the dots" passwords secure?

It's a simple way to keep honest people honest, but I wouldn't rely on it to stop a determined attacker.

It's not even secure against holding it up to a light and looking for smudges.

By looking at smudge patterns, you can figure out a few edges that are involved which reduces the search space to significantly better than brute force.

There is a pause built into it after a failed check though which offers some protection.


Distance Education Programs in Digital Forensics

Boston University Looks like it has what you are looking for.
http://www.bu.edu/online/programs/certificate-programs/digital-forensics.html

Also Champlain College has a program as well.
http://www.champlain.edu/Graduate-Studies/Programs/Master-of-Science-in-Digital-Forensic-Management.html


What is preventing us to start using scrypt in production ?

If we want to look for rational reasons not to use scrypt right now, we can find mostly these three:

It is unclear whether a "memory-hard" function is what is needed, with the parameter configurations supported by scrypt. Scrypt was initially designed to support local encryption, particularly whole-system encryption. This means that the password must be hashed during the system bootup process; at that time, the computer has nothing else to do, so the whole CPU and RAM is available for a single scrypt; and since bootup already takes a non-negligible amount of time, a password hashing extending over 5 or 10 seconds is no hardship.

A typical server will need a distinct configuration, that uses less RAM (a server cannot afford a gigabyte per password hashing, if it has to serve several clients and not crumble under peak load) and less CPU (a Web site authentication should be done within less than 1 second, because users are not patient; and, there again, we must account for peak load). Whether scrypt is better than bcrypt when configured for "server usage" remains to be seen; in fact, if you need to put CPU usage down to about 1 ms per hash, then scrypt uses less RAM than bcrypt, making the latter a superior option.
As far as memory hardness is concerned, scrypt turned out not to be as optimal as it could be. Some GPU-based optimization is still doable with time-memory trade-offs. The attacker's gain is not devastating, but if we are to change our password hashing function then we may as well try to find one that fulfils its promises.

Such issues, and other information, can be found in this presentation. To summarize: while the ideas expressed in the scrypt design are quite interesting, the general feeling of cryptographers is that there should be more research; and, indeed, it prompted the PHC: an open competition, in the spirit of past efforts such as AES, SHA-3 or eSTREAM, where new candidates are proposed and reviewed.

If you deploy scrypt right now in production, then it should be reasonably strong, although it depends on the parameters you choose. That is the main conclusion of 5 years of research: the cryptography is sound, there is a time-memory trade-off which is not damning, but we don't have a lot of guidance on how to configure it in ways that will work well in typical servers.


group_concat is the wrong function. Try this:

'UNION ALL SELECT CONCAT_WS(0x3a,username,password) FROM users--

(note also the order of the arguments. If you want more columns, you can just append them: CONCAT_WS(0x3a,username,password, moreColumns, canBeHere)).

This works for MySQL and PostgreSQL. SQL Server doesn't have CONCAT_WS, but it does have CONCAT (without separator) or you can manually concat: username + ':' + password. Oracle also does not have CONCAT_WS, but this should work: username || ':' || password. This is also how it would be done with SQLite, which also does not have CONCAT_WS.


Browser Unable to Fully Authenticate HTTPS

The reason you're getting this is because you load certain resources over HTTP. When you look at the page source code, you'll see this:

<link rel='stylesheet' id='google-font-body-css'  href='http://fonts.googleapis.com/css?family=Open+Sans+Condensed&#038;ver=4.1.1' type='text/css' media='all' />
<link rel='stylesheet' id='google-font-heading-css'  href='http://fonts.googleapis.com/css?family=Abel%3A300%2C500%2C600&#038;ver=4.1.1' type='text/css' media='all' />
<link rel='stylesheet' id='google-font-third-css'  href='http://fonts.googleapis.com/css?family=Indie+Flower&#038;ver=4.1.1' type='text/css' media='all' />

Meaning that your fonts are loaded over HTTP (possibly there are more resources that are loaded over HTTP rather than HTTPS)

In order to solve this problem, you could use the following code:

 <link rel='stylesheet' id='google-font-third-css'  href="//fonts.googleapis.com/css....">

This means that the resources are loaded over HTTP(s) if the page is loaded over HTTP(s)

Hope this helps.