How a risk assessment impacts information security policy? I usually do the technical part of security, so I'm not familiar with security policy area.

Risk assessment (measurement and evaluation) is always taken in an organization, such as to identify vulnerabilities, threats, the impact of threats, risk treatment options, and so on.

I want to see how this risk assessment methods/procedures/results will impact the organization's information security policies. To summarise:

How can risk assessment improve the information security policy?
What are the implications of risk assessment for IS security policy?

I prefer some formal explains/descriptions instead of an oral summary.

Risk assessment should not affect information security policies.  Policy should be a statement of goals/objectives, and should normally not change.  Policy should define the limits of risk management.

Multiple different organizations provide different risk assessment/risk analysis methodologies, but I think those are too detailed for your question (I'm not sure if you're asking about ATO, C&A, ISCM, RMF, etc.).  If I understand the question correctly, the answer is that Risk Assessment & risk analysis are intended to start a constructive suggestion about the response to the risk.  When you complete a technical assessment:

There are generally more findings than there are resources to fix findings. Risk assessment prioritizes resources against risks - if you have $N dollars and 10x$N problems, it makes sense to spend the first $ on high probability, high impact problems, and defer solutions on low probability/low impact problems. Technical findings may reveal that you don't have a fence around your facility, leaving you vulnerable to physical infiltration; that is not a problem if you are a ship at sea.
Many of the findings are the result of the instant when the technical assessment was conducted.  Risk Assessment can discuss the urgency of the problem.  If my patch half life is 7 days, then at any instant technical assessment will find that I have unpatched machines.  Risk assessment allows me to compare the cost of an emergency configuration control board against the fact that those patches should be resolved within 7-10 days.
Many findings are unresolvable.  I worked on one assessment that found a flaw in network devices that would have required tens of millions to fix - we would have had to replace relatively shelf standard network devices (that could be administered by normal network admins), with specialized network devices that required specialized training and exclusive support.   The unit cost was high, the support costs were higher and the number of units were in the low thousands. Replacing shelf standard equipment with custom crafted equipment is very expensive. There was an alternate solution that could be done using maintenance spares, and the resulting environment was actually more secure than the custom equipment.
Sometimes the technical finding is not the problem; the underlying procedures/governance is the problem.  I've managed a number of assessments where the technical problems mount up because the relevant manager hasn't bothered to ask for the money to solve the underlying problem.  Risk assessment is the framework for the discussion that begins, "If you ask for $X now, you'll get it next year, but if you wait for the incident to happen, it will cost you 100$X. Here is how to do it..."*
Sometimes the finding is not worth the effort.  It doesn't make sense to implement two factor authentication on a SCADA control panel.  If it costs thousands of dollars to stop processing, log out of the system, log back into the system and start processing again at the end of every shift, there are other ways to ensure accountability.

Technical assessment compares an abstract ivory tower set of principles to a system that is in place to perform a mission function.

Risk Assessment is the start of a dialogue, "How do we accomplish our mission with our resources in our environment, knowing that we have these vulnerabilities?".


Is it Safe to Send an Invalid Password Back to the Client? It is common for websites to remember the username input value after an invalid login attempt but not the password input value.

Take SE for instance. When I attempt to login with an invalid password:

The response contains my username but not my password:

Is this a security feature or does it relate only to user experience design?

I am not sure because some login forms, particularly those who send the credentials asynchronously, do remember the password.

When the credentials are wrong, the server sends you back a page containing the filled username and perhaps also the password. That should be done with https, and caching headers asking not to store it, but there's the possibility that the error page that was sent with the provided password in the source is stored somewhere (browser cache, an intermediate proxy…).

When there's an asynchronous login, the page itself is not reloaded, and thus this issue doesn't happen.

With a login form, you pretty much always want to blank the password, as the user will have to retype it anyway since it was wrong (and is unlikely to know which was his typo).

The debate on whether to-blank-or-not-blank the password field usually arises  when dealing with the registration form. There it is likely that an unrelated field is rejected (eg. username taken) and the user needs to provide a new username (which may turn out not be available, either) and the password and password confirmation. That makes an unpleasant UI. And there there are different opinions on which should wine.


BEAST mitigation on a Cisco ACE 4710 load balancer We are looking to mitigate BEAST (and similar) on our Cisco ACE appliance (running version A4(2.0)), which is the 'endpoint' for a handful of load-balanced services.  Some of these service still run with SHA1-signed certificates (although we are working on having our clients test with SHA2-signed certs).

The ACE allows us to create a parameter-map to prioritise the ciphers it supports (with priority 10 being the most-preferred and 1 being the least-preferred), but I am not fully aware of the intricacies of each cipher suite.

Would the following be a reasonable mitigation (essentially prioritising CBC-based ciphers lower, so as to prefer the non-CBC ciphers)?  Are there any on this list I really shouldn't be accepting?  We are obviously aiming to still be as compatible as reasonably possible.

Note that we are not trying specifically to meet PCI compliance, just attempting to 'do the right thing' (although if any of the below would violate such, it would be helpful to know in case it comes up in the future)

parameter-map type ssl PMAP_SSL_CIPHERS
  cipher RSA_WITH_RC4_128_SHA            priority 6
  cipher RSA_WITH_RC4_128_MD5            priority 6
  cipher RSA_EXPORT1024_WITH_RC4_56_SHA  priority 6
  cipher RSA_EXPORT1024_WITH_RC4_56_MD5  priority 6
  cipher RSA_EXPORT_WITH_RC4_40_MD5      priority 6
  cipher RSA_WITH_AES_256_CBC_SHA        priority 2
  cipher RSA_WITH_AES_128_CBC_SHA        priority 2
  cipher RSA_WITH_3DES_EDE_CBC_SHA       priority 2
  cipher RSA_WITH_DES_CBC_SHA            priority 2
  cipher RSA_EXPORT1024_WITH_DES_CBC_SHA priority 2
  cipher RSA_EXPORT_WITH_DES40_CBC_SHA   priority 2

The simplest way to mitigate BEAST is to do nothing at all. BEAST is a client attack. Servers can "protect" clients by enforcing the use of RC4-based cipher suites even if the client states that it prefers some CBC cipher suites. However, all recent Web browser versions include workarounds which make them immune to BEAST, namely the 1/n-1 split; and the server has never been vulnerable to begin with.

Also, BEAST relies on the ability to inject in the client some hostile Javascript which can send arbitrary binary requests to an external host; this requires a hole in the Same Origin Policy. The two holes which were used in the original BEAST demo have been patched (one used a bug in Java, the other an old draft version of WebSockets).

Therefore, is BEAST is still a concern for you, then your browser is madly out-of-date and has quite a lot of other, more urgent vulnerabilities. Update it ASAP. As a by-product, it will fix any BEAST-related worries.


Where do you store your personal private GPG key? So, I want to start using pass, but I need a GPG key for this. This application will store all of my passwords, which means it's very important that I don't lose my private key, once generated.

Hard disks break, cloud providers are generally not trusted. Not that I don't trust them to not mess with my key, but their security can be compromised, and all my passwords could be found.

So, where can I safely store my GPG private key?

I like to store mine on paper.

Using a JavaScript (read: offline) QR code generator, I create an image of my private key in ASCII armoured form, then print this off. Note alongside it the key ID and store it in a physically secure location.

Here's some that should work for you no matter what operating system you use, as long as you have a browser that supports JavaScript.

For Windows users:

Click here to download the JavaScript QR code generator: https://github.com/davidshimjs/qrcodejs/archive/04f46c6a0708418cb7b96fc563eacae0fbf77674.zip

Extract the files somewhere, then proceed edit index.html per the instructions below.

For MacOS or Unix users:

$ # This specific version is to avoid the risk that if someone hijacks `davidshimjs`'s
$ # repository (or he goes rogue), you will still be using the version that I vetted.
$ # For the truly paranoid you don't trust GitHub either, and you will want to verify the code you download yourself.
$ wget https://github.com/davidshimjs/qrcodejs/archive/04f46c6a0708418cb7b96fc563eacae0fbf77674.zip
$ unzip qrcodejs-04f46c6a0708418cb7b96fc563eacae0fbf77674.zip
$ cd qrcodejs-04f46c6a0708418cb7b96fc563eacae0fbf77674/
$ # We need to edit index.html so that it supports pasting your PGP key
$ # Open the file in a text editor like Notepad, vi, or nano
$ vi index.html

Change line 11 from:

<input id="text" type="text" value="http://jindo.dev.naver.com/collie" style="width:80%" />

to:

<textarea id="text" type="text" value="http://jindo.dev.naver.com/collie" style="width:80%" /></textarea>

Now navigate to the directory you get here with Explorer, Finder, or Nautilus, etc.

For example:

$ pwd
/Users/george/Documents/Code/qrcodejs/qrcodejs-04f46c6a0708418cb7b96fc563eacae0fbf77674
$ open .

Now, double click on the index.html file you just edited and saved.

You will most likely need to break up your PGP key into quarters or even smaller to create nice big QR codes that you can easily scan later. After pasting in the text area, click away from the text box and your QR code should appear. Save each one as you go and name them appropriately so that you know their order!

After you've created all the codes, scan them with, for example, a mobile phone QR code scanner app. For the paranoid, keep this device offline once you've installed a barcode reader and then perform a full wipe and factory reset of the device before putting it back online. This will prevent the QR scanner app from leaking your PGP key.

If you have a large key or lots of keys I recommend paperbak, although be sure to write down instructions on how to recover the data later. Just as important as how you back it up is how you restore it from a backup. I'd probably try this with dummy data just to be sure you know exactly how it works.

Worth noting you can protect your private key with a passphrase, so even if it's hosted with a cloud provider they can't see your private key, but then all your password security is reduced to that passphrase rather than the full private key, not to mention cloud providers can disappear overnight.


Booting into Live USB Linux If I have a Live USB Linux stick and I plug it into a computer which is not connected to the internet and boot the computer using the Live USB stick.  How secure is this interms of not leaving any traces of work I do via the Live USB stick?  i.e. will any traces be left on the host computer once the computer has been switched off and the Live USB stick has been removed?

I basically want to store passwords on the USB stick Live USB.  If it's possible to encrypt the  Live USB and store passwords on it.  That should mean that I can use any computer to check my passwords by first disconnecting the computer from the internet?  I understand I can do this with a spare computer which is never connected to the internet, but that would be a whole computer, and I'd rather not carry a full computer with me.  If it's a usb stick, then I can use any computer which I know is disconnected.  So I just wanted to make sure that no traces are left of my passwords on the host computer.

(Quick answer, I don't have the time to research all I remember and double-check my facts.)

There are multiple things to consider here:

USB sticks may carry payload that you do not know is there, e.g. a virus to infect the computer it's plugged in to.
Things like BIOSes, network cards, etc. can often be flashed to upgrade the firmware. You could also install viruses on here and they often have full memory access.
USB sticks are rewritable. There are very few that actually implement hardware write locks, e.g. by using a physical switch. I think Jacob Appelbaum (from The Tor Project) looked into this, he mentioned it somewhere... I forgot where. Such USB-sticks are basically unobtainium as far as I know.
RAM memory is not off and gone: it fades. Off the top of my head, it's gone after about a minute in room temperature. You can google this, search for cold boot attacks.
Be sure to power off the computer (if you aren't sure, pull out the cable and battery), in standby mode memory is obviously retained.
The data is only as secure as the host. If your offline computer contains a hardware keylogger that someone then later retrieves when you are out of the house, well, being offline didn't help much in this case.
I think it was with a microphone inside the same computer, but some chips on the motherboard may leak data. There was some sort of side channel attack to extract private keys... I don't really remember, but you might want to keep a bit of distance between the computer and other systems. This Google search seems to give some info.

So it depends what you want to protect against. Are you hiding state-secret information, or are it love letters that you are trying to keep private?

In theory you're right: under normal circumstances all data will be gone when the live USB-stick is removed and the computer is powered off. In practice, there are a lot of things that (powerful) adversaries can do to all parts of the system.

If you buy a USB-stick, assuming it's not backdoored to start with (which is a reasonable assumption under normal circumstances) and you only use it on your offline computer, then I don't see how it could get infected without someone physically touching it. Same goes for the computer. The problem is: how do you get your OS while offline? Somewhere you somehow need to connect to the internet to create the live boot. Perhaps this would be safest on a computer of a friend that is not tech-savvy and has no clue what you are talking about, and who is preferably not a close friend either. For bonus points, pick another friend and use his computer to verify the checksum. I think as individual, this is about as close as you can get to protect against extremely powerful adversaries.

By the way, lots of stuff in this post may be tinfoil hattery, but I'm trying to talk in terms of "what would be provably secure." For example one would normally assume that "of course a computer that you just bought is not backdoored", and it would be tinfoil hattery to assume otherwise, but how do you know? If you are not trying to protect against powerful adversaries like a government though, much of the advice in this post can be disregarded.

Edit: This answer is only about the first paragraph of the question, not the second that the asker added in an edit.


Implementation of an IDS I am starting my final year project and I have decided to make an Intrusion Detection System,  but I am a little confused where to start.  I have read some papers and those have been pointing out the different features (like distributive nature of IDS etc.)  instead of  pointing out a real start. I just want to know from where I could start and what platform would be suitable for the same...

If you are reading academic papers, then it is likely you are going to be reading about esoteric features, distributed problems, and otherwise interesting OPEN issues in the ongoing battle of IDS.

If you are looking for (a) specific paper(s), then I would suggest looking for a SURVEY of existing systems.  Surveys usually give some historical review with emphasis on the current state of the art.  They are generally easy to read and light on hard-core analysis.  I googled for "survey of intrusion detection systems" and got so many viable hits I won't even bother linking to any of them.  You can try to focus purely on academia by hitting the major academic CS research websites such as CiteSeerX.

Since this is a term project, the nature of the system needs to be scalable.  Don't try to go all out -- maybe try creating a host-based IDS instead of trying to tackle otherwise more difficult issues.  You may also want to focus on something easy like a signature-based approach rather than a heuristic-based approach.  Remember: the core problem you are trying to solve is that of Intrusion Detection, rather than, say, distributed systems.

Of course if you find yourself with more time on your hands at the end, then augment.  Software development is an evolutionary process.  Start with something simple and build out.


How to pentest Flash file on webapp with alowscriptaccess=samedomain? In the course of a pentest I found a Flash movie file (swf) that loads another Flash movie through loadMovie. The HTML is this:

<embed width="388" height="350" src="http://www.domain.com/first_flash.swf?
videoload=http://www.domain.com/videos/second_flash" quality="high"
pluginspage="http://www.macromedia.com/go/getflashplayer" align="middle"
play="true" loop="true" scale="showall" wmode="window" devicefont="false"
bgcolor="#ffffff" name="interior" menu="true" allowfullscreen="false"
allowscriptaccess="sameDomain" salign="" type="application/x-shockwave-flash">

As you can see, there is the directive allowscriptaccess="sameDomain". Also, if you access the Flash file directly I understand that recent Flash plugins use this setting as default.

In the first_flash.swf, I found this code that loads the second movie:

_root.videourl = _root.videoload + '.swf';
video.loadMovie(_root.videourl);

I have tested I can actually change the videoload variable to load swf from other domains. But I can't seem to execute javascript with getURL on a second_flash.swf controlled by me.

So my question is, what can I do to exploit this poor design? How can I show that it is, in fact, dangerous?

Original source -- http://my.safaribooksonline.com/book/networking/security/9780596806309/inside-out-attacks-the-attacker-is-the-insider/content_ownership

2.4.1. Abusing Flash’s crossdomain.xml

The same origin policy can often be deemed too restrictive, causing application developers to clamor for the ability for two different domains to work interactively with each other. One of the first popular browser plug-ins to support such cross-domain interaction was Adobe’s Flash. Adobe understood the dangers of allowing arbitrary cross-domain access and implemented a security measure to determine whether Flash would allow for cross-domain interaction. This security measure is implemented via the cross-domain policy file.

Flash’s cross-domain policy file defines the “rules” for cross-domain interaction. The cross-domain policy file is simply an XML file named crossdomain.xml. Here is an example of a crossdomain.xml file:

<?xml version="1.0" encoding="UTF-8" ?>

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

    <allow-access-from domain="*" /> </cross-domain-policy>

This crossdomain.xml policy file must be hosted on the server that wishes to allow for cross-domain interaction. Before allowing cross-domain interaction, Flash will check for the presence of a cross-domain policy file on the target domain. If no policy file exists, Flash defaults to the restrictive same origin policy and disallows cross-domain interaction. If a crossdomain.xml file exists on the target domain, Flash reads the “rules” contained within the policy file and allows cross-domain interaction based on the established rules. Once again, the entire premise is based on the fact that the cross-domain policy file must be served from the domain that wishes to allow the cross-domain interaction. By default, Flash will check for the presence of a cross-domain policy file named crossdomain.xml in the web application’s web root (http://www.example.com/crossdomain.xml).

Beginning with Flash 7, you can make Flash check for crossdomain.xml in arbitrary locations (not just the root of the web root) when the Flash component invokes loadPolicyFile() with a URL as the parameter (containing the location of crossdomain.xml on the target server).

NOTE

You can find more information on System.Security.loadPolicyFile() at the following website:

http://livedocs.adobe.com/flash/mx2004/main_7_2/wwhelp/wwhimpl/common/html/wwhelp.htm?context=Flash_MX_2004&file=00001098.html

The concept of Flash’s cross-domain policy is based on a few simple premises. A simplified version of the logic is as follows:

The cross-domain policy file must be located in a web-accessible path of the web server to allow for cross-domain access from Flash to that server.

The only way someone can put an arbitrary file into a web-accessible path of the web server is if he has administrative access to the web server.

Therefore, if the web server has a cross-domain policy file in a web-accessible path on the web server, an administrator must have placed it there.

This logic is inherently flawed because many web applications allow users to upload content to the web server. If the application subsequently serves that content under its domain name, that web application has unknowingly put itself at risk because of Flash’s cross-domain abilities. If an attacker is able to upload a crossdomain.xml policy file, the attacker can use an evil Flash applet on her web server to attack the vulnerable application. This evil Flash applet will be able to make cross-domain requests to the vulnerable web application and those requests will be made with the session cookies of any unfortunate users who happen to stumble upon the attacker’s website. To make matters worse, the cross-domain policy file need not have the .xml extension. Flash’s security criteria will honor any file extension.

NOTE

Adobe Flash 9.0.115.0 allows for the specification of “meta-policies.” These policies define which policy files on the server should be honored. You can find more information on meta-policies at http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security_03.html.


Are these claims about public WiFi accurate? I received the following message from my bank:

  Be careful when using wireless networks. Some wifi networks are unsecure, meaning that they may allow someone else to access information or files stored on your device. When you're out in a public place, it's best to stick with known sources for your internet connection, such as the Starbucks wifi, and not a random home network that happens to be open. It's always best when you're on the go to turn off your wifi, unless you absolutely need it. It's safer to use up some of your monthly data instead of connecting to a wifi network that could potentially allow hackers access to your device.

This seems like a really bad analysis of the risks of public WiFi to me. I've never heard anyone recommend using Starbucks WiFi for security reasons.

As a security-minded person, my advice to friends who ask has been to never connect to WiFi networks where you don't know the person responsible for it and all the other people who are connected without (1) a well configured firewall and (2) tunneling all traffic through a trusted, encrypted VPN. (Starbucks WiFi would of course fail this test.)

I understand that these might be out of reach for less tech-savvy people, but is it really good to suggest using public WiFi from "known sources"?

Some other thoughts:

It seems like it would be relatively easy to set up a fake Starbucks access point.
Attempting to contrast "unsecure wifi networks" (presumably unencrypted?) with "known sources" seems to be missing the whole point of the risks of public WiFi, as well as comparing orthogonal concepts.
The one thing I agree with is their last recommendation to use cellular data rather than connecting to public WiFi.
Overall, this seems like a rather self-contradictory recommendation.

Is my analysis of public WiFi completely off base? Does my bank have a good reason for making these recommendations to (presumably lay) users?

Is my analysis of public WiFi completely off base?

TL;DR - You analysis is not off. You are correct.

  Does my bank have a
  good reason for making these recommendations to (presumably lay) users?

In my professional opinion, your bank is in error. While using Starbucks is safer than connecting to someone's home wifi, this can lull a client into a false sense of security. WPA-2 encryption has been proven to be vulnerable, and WEP and WPA encryption are child's play to crack. Once on a wifi network, a simple packet sniffer can capture all sorts of information unless other hosts are using a VPN.

  It seems like it would be relatively easy to set up a fake Starbucks access point.

You are correct. They're called evil twin AP's. Besides hiding the hardware, they're relatively easy to set up and the kind of person who could detect it is not the kind of person to use free/public wifi.

  Attempting to contrast "unsecure wifi networks" (presumably unencrypted?) with "known sources" seems to be missing the whole point of the risks of public WiFi, as well as comparing orthogonal concepts.

The only difference between a known and unknown network is familiarity. Technically speaking, knowing the barista does not make one's network more secure. Again, you are accurate. Your neighborhood friendly barista probably doesn't know if his/her network is compromised, so having the warm fuzzies about connecting provides no security.

Finally, your point (which was not chronologically last but an excellent summation anyway)

  As a security-minded person, my advice to friends who ask has been to never connect to WiFi networks where you don't know the person responsible for it and all the other people who are connected without (1) a well configured firewall and (2) tunneling all traffic through a trusted, encrypted VPN. (Starbucks WiFi would of course fail this test.)

You are correct in your advice. Always use a VPN on Wifi, and ensure you have some sort of AV if you're running windows. (Linux machines, like the one I'm writing this on, have different set of "rules" for firewalls and you can simply change iptables).


openssl - generating rsa key pair - public key I am trying to generate RSA 1024 key pair (public/private) using the following command

openssl genrsa -des3 -out server.key 1024

In the server.key file, only RSA private block is there, so where does the public key go ?

The RSA private key format includes all the public elements. When you get the private key you really have both the private and public key.

This is described in PKCS#1 (the leading RSA standard); private key format is an encoded ASN.1 structure which contains:

  RSAPrivateKey ::= SEQUENCE {
      version           Version,
      modulus           INTEGER,  -- n
      publicExponent    INTEGER,  -- e
      privateExponent   INTEGER,  -- d
      prime1            INTEGER,  -- p
      prime2            INTEGER,  -- q
      exponent1         INTEGER,  -- d mod (p-1)
      exponent2         INTEGER,  -- d mod (q-1)
      coefficient       INTEGER,  -- (inverse of q) mod p
      otherPrimeInfos   OtherPrimeInfos OPTIONAL
  }

The public key really consists in the modulus and public exponent, which are both in the private key structure, as shown above.

Now your question might be: "what if I want the public key 'alone' ?"

OpenSSL lives in and by the X.509 world. In X.509, public key don't exist as stand-alone values; and there is no standard file format for lone public keys. An application is supposed to use public keys that it found in certificates. This is quite apparent in the SSL/TLS protocol (which is the primary support goal of OpenSSL): when the client sends its public key, it sends it as a certificate. Therefore, if you want the public key in a file, arrange for it to be stored in a certificates (possibly self-signed). The OpenSSL req sub-command, with the -x509 flag, can help.

Of course, every rule has exceptions, so there is also a method to get the public key "only" from the private key; this is what @uwotm8 shows in his answer. However, the resulting public key, which will look like this:

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDzYY+BpIuKouSnoemSwHwC25uW
Xc0zX1gl8NtG5UQP2U4Lda0s5XbBJm4O2W+RkOgR1f1d5cGOXRPd6Q9ntw3MYQv6
ubsMRZUaOT4vCpykWfPi/VfsQEPlWHw2pulYAyumx/sw8tX5i9NC2e2bY4eWwo22
BELyXpNdoGozSje8PQIDAQAB
-----END PUBLIC KEY-----

is not really usable anywhere, because this is a non-standard format.

(Technically this is a SubjectPublicKeyInfo element as it appears in an X.509 certificate, but it is not supposed to appear outside of an X.509 certificate.)


Why does Google cripple the 2FA Google Authenticator PAM module? If you enable 2FA for Google Apps the shared secret is 160 bits. The google_authenticator PAM module on the other hand seems to use 80 bits for the shared secret.

According to RFC 4226:

  R6 - The algorithm MUST use a strong shared secret.  The length of
  the shared secret MUST be at least 128 bits. This document
  RECOMMENDs a shared secret length of 160 bits.

Note "MUST" not "SHOULD". So that makes Google Authenticator non compliant.

What's the rationale behind doing this?

The initial commit for this code already includes the "80 bits" secret key length. It was not changed afterwards.

Now let's analyze things more critically. HOTP is specified in RFC 4226. Authentication uses a "shared secret", which is the value that we are talking about. What does RFC 4226 says about it ? Essentially, there is a a requirement in section 4:

R6 - The algorithm MUST use a strong shared secret.  The length of
the shared secret MUST be at least 128 bits.  This document
RECOMMENDs a shared secret length of 160 bits.

And then section 7.5 explains at length various methods for generating the shared secret.

Now the google_authenticator code generates an 80-bit shared secret with /dev/urandom and then proceeds to encode this secret with Base32: this encoding maps each group of 5 bits to a printable character. The resulting string thus consists of 16 characters, which are written "as is" in a file, with ASCII encoding, meaning that in the file the shared secret has length... 16 bytes, i.e. 128 bits. It is thus possible that the initial confusion comes from that: what is stored has a length which can be seen, in a way, to comply with requirement R6 of RFC 4226.

Of course, the RFC talks about the "shared secret" by calling it "K" in section 5.1 and then proceeds to using it as key for HMAC (section 5.3, step 1). With the shared secret generated with the command-line tool in google_authenticator, what enters HMAC really is a sequence of 80 bits, not 128 bits, even though these 80 bits happen to be encoded as 128 bits when stored (but they are decoded back to 80 bits upon usage). Thus, this 80-bit secret cannot really, in a legalistic way, comply with requirement R6 of RFC 4226. However, the confusion on "length" (after or before encoding) may explain this feature of google_authenticator.

Note, though, that this is just for the command-line tool which can be used to generate the secret as an initial step. The rest of the code supports longer secret values.

(Another theory is that the author wanted to test his code, and, in particular, test the situation in which there is no QR code. In that case, the user must type the code, and an 80-bit secret is easier to type than a 128-bit or 160-bit secret. Possibly, the author first used a short secret to ease development, and subsequently forgot to set it back to its nominal length afterwards. This sort of mishap happens quite often.)

Is it critical ? With my cryptographer's hat, I must answer: no. An 80-bit secret key is still quite strong against brute force, because even with a lot of GPU, 279 evaluations of HMAC/SHA-1 will still take quite some time (with an 80-bit key, average cost of brute force is that of trying half the possible keys, i.e. 279 evaluations). Indeed, HMAC/SHA-1 is deemed "cryptographically strong", meaning that the best known attack is brute force on the key. Let's put figures on it:

HMAC/SHA-1 uses two SHA-1 invocation. So the attack cost is, on average, the cost involved by calling SHA-1 280 times. This page shows benchmarks at 2.5 billions of SHA-1 calls per second for a good GPU. If you are mounting a cracking farm, you will usually use a "middle range" GPU, not a top-notch model, because you will get more power-per-dollar that way. Let's assume that you use 100$ GPU that can do 231 SHA-1 per second (that's a bit more than 2 billions). With a budget of one billion dollars you can have ten millions of such GPU, and they will run the attack in an average of... 652 days.

Of course, 10 millions of GPU take quite some room and, more importantly, use a substantial amount of power. If we suppose that each GPU can run in 50W (a quite optimistic figure), then each attack run will need a bit less than 8 TW.h (terawatt-hours). I live in Canada, province of Québec, where electricity is known to be very cheap due to huge dams and substantial government subventions, resulting in a price of about 0.05$ per kW.h (see the prices). With this price, each attack run will cost around 400 millions of dollars on electricity alone. This does not include cooling prices, because all this energy will become heat and will have to be dissipated (to some extent, a Canadian winter can help). Also, notice that all the GPU will collectively draw 500 MW, a non-discreet amount (that's about half of a nuclear power plant...).

What this amounts to is the following: in practice, an 80-bit key is strong enough. I would be nervous if an 80-bit key protected the launch code for nuclear missiles; however, if the strategic dissuasion was protected by Google's 2FA, I would also be quite nervous for... other reasons.

So we can say that while this 80-bit secret is non-compliant and academically "a bit short", it still is quite strong and does not mandate immediate and drastic actions. It would be cool if the code was fixed; the World won't stop spinning if it is not.


Does the ATA Trim command irrecoverably delete data on an SSD? I occasionally see people reference the difficulty of deleting data from an Solid State Disk.  Because of the nature of SSDs (wear leveling, etc), simply writing to the same sector of the disk doesn't guarantee that it's deleted.

But modern operating systems support the ATA Trim command, which informs the SSD that the sector is no longer used by the operating system.

Does the trim command actually delete the data on the disk, or do you have to wait for the disk to do "garbage collection".  If so, how long do you have to wait before the data has been cleared?

The trim command does not delete the data but simply marks a block of data as currently unused by the OS. It will probably return the block as zero if asked by the OS (although I don't know if this is guaranteed) but internally the data might be still there and could be extracted when accessing the flash storage directly, which is usually not possible by the OS but can often be done by computer forensic experts. When (and if at all) the block gets reused, i.e. overwritten with new data fully depends on the logic in the flash controller and how much data get written at all and how much this block was written already. Since a block of flash will wear out after too much writes the controllers usually prefers to write "fresher" blocks first and thus it can take a long time before a block gets reused for writing.


can a power bank be used to plant malware? A power bank has some sort of circuitry, but I am not sure if there is any software on a power bank or if they are only pure batteries, but people are connecting their mobile phones and laptops to them by USB and historically USB sticks represent a medium to transfer malware.

A pure power bank likely cannot - most of them have the data lines not connected to any chips, but rather to resistor networks.  However, someone could easily make something that appears to be a power bank but has nasty firmware on it.

You can get data disconnected (power only) USB cables that you could use to plug into a suspect power bank.  However, since phones use the data lines to decide how much power they can draw, in disconnected lines they draw the minimum and will charge slower.

You could make up a cable to match your phone, but it gets complicated.


How can the ISP block Sarawak Report even if I am entering Sarawak Report from google search? Sarawak report is blocked in Malaysia.

I  think that by doing a Google search on relevant keywords, and then click on the relevant link, I can access the website, because from what I know, the searches and clicks on Google are encrypted, and hence my ISP won't know that I am accessing Sarawak Report.

Apparently this is not the case; my ISP can still block me. How does it do that?

If you click on the link of a search result you simply get a redirect from google to this site, i.e. your browser is still accessing the site by its own directly and not through the servers of the search engine.

If you don't want to get this you would need to try the cached version of the site, which is sometimes offered within the search results. This cached result is then served from the search engine itself, although it might include the images on this site in a direct way again.


Got a call from "skype-resolver" on Skype. Should I be concerned? This morning, I found out that I received a call from "skype-resolver" in the middle of the night on my phone. When I went to Skype, the call was nowhere to be found, presumably because the account had already been deleted. iOS however, kept a record of the call listing the name as "Group%20Maker" and username "8:guest:abab0b31-f32b-...".
This was surprising, because I've never been called by a scam contact in my decade of Skype usage. The furthest it would extend to is a contact request.
I have experience with Skype resolvers, having experimented with them many years ago. I tested it on myself, and it would spit back my IP. Only it would never call you in the process. Ever since these were apparently patched, the websites would never work, and few people speak of them any longer.
That's why I thought it was so strange to get a call like this. I searched the Skype directory for similar contacts and found dozens of active "Skype Resolver" accounts, all with the "guest:xxxxxxxx-xxx..." usernames. But that's as much as I've been able to find out about my caller. Is this just some new scam, or was someone actually trying to get my IP in 2021?
Update: Notification cache on my phone says the caller was actually named "skype-resolver.net". This website just leads to a "Coming soon" screen. A whois lookup says this website was created yesterday.
Update 2: Received a second call from them about 18 hours later, with a different username. Wanted to answer but did not do so out of security for my IP. Thoughts?

There is now a working Skype resolver in 2021. It is skype-resolver.net, and it will call you if you try to look yourself up. Either the old security flaw has not been fully patched, or a new one has been found. It is not clear whether the site calls you automatically, or only when someone is trying to look you up. It doesn't matter whether you answer--if you try, the call will instantly end.
There seems to be a simple fix for this. On each of your active Skype devices, go to your settings, and enable the option "Only allow Skype calls from contacts to ring on this device". While you will still see a missed call notification from the guest usernames, the site itself will output "Could not resolve user", and there will be no current IP listed. That being said, past IPs you've had may still be visible.


How much information about the reason for an unsuccessful login should a web application give? After an unsuccessful login attempt, should I inform the user about its reason? Or more generally, how much information about the reason for an unsuccessful login attempt should a web application give?

It's kinda obvious not to inform the user about an incorrect password alone, but to couple it with login - such as 'Email or password is wrong' (or isn't it?). But I started to wonder about informing the user that the account was suspended/banned. Is it too much information? If I give away this information, what I'm giving also is 'this account is registered with this service'. Consequently, if users' emails are used as the login, 'this email is valid'.

But all of this information an attacker could pull out of the registration form trying to register different emails/logins - unless the application would obfuscate the reason for unsuccessful account creation (just 'Couldn't create account with given data'), which is not the best idea from a UX point of view.

With that in mind, lets go step back to unsuccessful login - if an attacker can pull out information about registered email with certain service isn't it just plain stupid to say 'Email or password is wrong'? Malicious/power users will have this information either way, and an unskilled user has to check the login/email and password all over again.

In the end it looks like a Lose-Lose situation ('No security Win - UX Flaw').

UPDATE:
I rethought giving out information about a blocked account - of course this information should be given after providing correct credentials (and then it's not a problem to give even more info about reason for blocking the account, date due and so on...), so it's out of the question.

UPDATE2:
Please consider this question as a question about a design flaw in wepapps. I'm not asking about counter measures to take to prevent brute force attacks (CAPTACHS after a few attempts, blocking a certain IP for few minutes after another few attempts, and so on...)

Ok, let's walk through the several possible scenarios here.

1) Display exactly what is wrong with the login attempt

This is obviously a stupid thing to do. By displaying exactly what is wrong with the login attempt, you are helping an attacker narrow down his attack. This is the reason why people recommend displaying a more generic message like Invalid username/password.

See: "Username and/or Password Invalid" - Why do websites show this kind of message instead of informing the user which one was wrong?

2) Display a generic error message

You display a message like Invalid username/password. People correctly suggest that an attacker can simply pull username information from your registration form. A possible counter to this is simply having a CAPTCHA on your registration form. While CAPTCHA's can be broken, this is not trivial if an attacker is simply running an automated script against your website. A CAPTCHA on a registration form is also way less annoying than a CAPTCHA on a login form.

If your username is public information, such as Facebook, this is obviously invalid advice.

3) Display information about blocked accounts

I don't see a valid reason why this should be displayed to a user attempting to login. Send them an email informing them their account has been locked out if needed. Don't bother showing them that information on the login screen.

You can use that to your advantage against bots hammering against your site by blocking IP addresses that repeatedly attempt to login to blocked accounts.

Remember, nothing you do can prevent an attacker from attempting to attack your site. What such measures do is simply make it a lot more difficult for a successful attack to be carried out. If your users have ridiculously weak passwords, their accounts will be compromised by a determined attacker eventually.


How can I be sure that my browser does not exfiltrate my passwords to some server? This is my first question and I dont even know if it is the right place. If this is an off-topic just mark it as off-topic, don't go crazy and downvote. :P

But how can I detect if my browser is not storing my passwords in some server, for later use against me. :D How can I trust my browsers privacy policy?

And also I am seeking something like lsof in linux.

P.S. I must be looking too paranoidy, but I am too curious :)

In theory, in order to be 100% sure, one would have to either read the browser source-code entirely (in case of open source software) or reverse-engineer it to understand what it does (in case of closed source software).

More realistically though, major browsers (e.g. IE, Safari, Firefox, Opera, Chrome) are probably the most studied software by security researchers, scrutinized in every way to find vulnerabilities and understand their behaviour. If one browser was capturing and sending user passwords to remote servers, this would have been detected.

Another reason why you should not be scared of that is: why would they do that? No matter what the benefit would be, can you imagine the risk they'd be taking by doing so ? If you're a browser editor and you get caught doing that, you can say goodbye to your business.


GnuPG + Yubikey 4: How to manually check that all keys are where they belong (on the Yubikey only)? I created a GnuPG RSA master-key and 3x RSA subkeys (sign,encrypt,authenticate).

Of course I want all key material to be stored solely on the Yubikey 4 - as they are only my 3 subkeys. Since I use the master-key only for certification of the subkeys, it should be kept only offline with the backups of the subkeys.

How do I check that all 3 subkeys and no master-key is on the Yubikey 4?
How do I check that no sensitive key-material is on the Computer?
How can I use the same Yubikey on my 2nd machine (Linux) - do I have to import any certificates to GnuPG/GPA there?
I first tried to create the keys with a live-cd as suggested from various sources, but back in Windows Kleopatra didn't let me use my Yubikey. So I used Windows to create the keys and it worked - now I'm worried that secret-keys are on the harddrive somewhere. lol If someone can point me to the right direction how to get it working with key-creation on live-cd and using on normal system, would be awesome.

I'm using 2 computers with the same Yubikey:

Windows 7 - Kleopatra and GnuPG
Ubuntu 15.04 - GPA and GnuPG

If you put the subkeys on the YubiKey, you still should keep the primary private key around somewhere -- it is the only entity that can be used to revoke the keys, create new subkeys, modify user IDs, certify other's keys, ...

  How do I check that all 3 subkeys and no master-key is on the Yubikey 4?
  How do I check that no sensitive key-material is on the Computer?

To verify what's on the card, run gpg --card-status, which should print several lines of information including three called "Signature key", "Encryption key" and "Authentication key". These should print your subkey's fingerprints, not your primary key's fingerprint. Don't bother for the "General key info", which is a reference to your primary (public) key, and not stored on the card.

To verify the keys are not stored on your computer, run gpg --list-secret-keys. Secret keys stored on your computer are marked with sec or ssb for subkeys, secret keys not available (for example, when your exported only secret subkeys running gpg --export-secret-subkeys are marked with sec#, secret key stubs only available on an OpenPGP smartcard (like the YubiKey also implements) with ssb>. Key stubs are simple references that a key is not available or is stored on a smartcard, and do not include the actual private key.

  How can I use the same Yubikey on my 2nd machine (Linux) - do I have to import any certificates to GnuPG/GPA there?

To use the keys on another computer, you need to export the "secret subkey stubs" to this machine, which you can do running gpg --export-secret-subkeys [key-id] (listing the primary key's ID). After importing on your new machine, you should not see a sec or ssb, but only sec# for the primary private key stub and ssb> for the subkey key stubs.

  I first tried to create the keys with a live-cd as suggested from various sources, but back in Windows Kleopatra didn't let me use my Yubikey. So I used Windows to create the keys and it worked - now I'm worried that secret-keys are on the harddrive somewhere. lol If someone can point me to the right direction how to get it working with key-creation on live-cd and using on normal system, would be awesome.

This reads like you didn't run --export-secret-subkeys like described above, so the GnuPG setup on the "regular" setup didn't know about the private keys at all. The public keys are not stored on the card, anyway.

When using a live CD, be sure to create some persistent copy of the primary master key stored in a safe place (you'll still need it!) and additionally a revocation certificate easily accessible for you in case you need to revoke the whole key, and lost access to the primary private key.


Is it something to worry about when my browser warns me that my connection to 192.168.1.1 (router admin page) is not secure? I got this "Not secure" warning when I'm trying to log in to my router (it's within my physical access). Apparently my router's management (admin) system doesn't have HTTPS.

Chrome also says

  Your connection to this site is not private.

I know that when I visit an HTTP website, the data transferred between my endpoint and the remote server could be sniffed by any node among the route, but this time the "remote server" is just the router (which also serves as a wireless AP).

Is it something to worry about, in the following cases? Assume I am authorized to administer the router and have unlimited physical access to it.

The router is placed in my home and I fully acknowledge all devices connected to it (my PC, my phone, my family's PCs and phones).
The router is placed in a public place (restaurant, hotel etc.) and is open to public in some ways.

No public Certificate Authority (CA) will issue a certificate for a private IP address, such as the 192.168.x.x blocks.

Because of that, I would expect that I would not see an HTTPS connection to a consumer-grade router in my network, and if I noticed such a connection (this assumes, of course, that I'd actually notice the lock icon when it shouldn't be there; which, if I'm honest, I probably wouldn't), then I would be very suspicious that someone had installed rogue certificates, and has an actively snooping proxy somewhere on my machine or in my network.

It is possible to set up a secure HTTPS connection, depending on your router's capabilities. If you can add a certificate to your router, you can create a self-signed certificate. This will effectively encrypt your HTTPS connection inside of a perfectly valid TLS tunnel, although your browsers will be complaining very loudly that the validity of the certificate can't be verified.

There are ways to get past these complaints by the browser, such as adding yourself as a trusted CA on your computer, or getting a certificate for a domain and using your internal DNS or your hosts files to point the domain to the private IP, as mentioned in the comments.

As far as the specific cases that you're asking about:

1, your own home: There should be nothing to worry about, assuming that all other devices are secure. Rogue devices on your network will be able to do packet sniffing, so don't log in using the same password that you log into your bank with (which is good advice regardless of what you're authenticating with).

2, you're hosting a public access point: Assume the network is being actively probed at all times. In this case, I might take the time to set up TLS properly and even then, if I were truly paranoid (I.e., my access point was set up at DefCon), then each time I access the management web page, I would disable wireless, ensure nothing else is connected via any hubs or switches, then change the password before re-enabling wireless and making my configuration changes.


When is a group password for a closed circle of users acceptable? I am developing a tool for a company, that takes some technical data and creates PDF reports.

In the tool you have several text fields, which get filled by the database. If the user wants to, he can change the contents of the textfields. In the end, he presses a button and some reports get created, archived and send to the customer.

My boss made the proposal to just use a group password for everyone, so every user of the tool knows the password and simply has to enter his own username.

I refrained from this and told him, this would be convenient, but unsafe mainly for the reason of Identity theft: someone can simply enter another username than his and input the textfields with nonsense, that gets send to the customer, print a report 300 times, create the report 500 times, etc.

We discussed this a little bit further and after he realised, that an attacker indeed could do some damage, at least to the reputation, we tried to find a scenario, where such a group password would be acceptable.

This got me curious: are there environments or situations, where such a group password would be acceptable? Or will it always get shot down with the "identity theft"-argument?

It's not acceptable if you want to be compliant with regulations like Sarbanes-Oxley (SOX), which - among other things - mandates that individual users must be easily auditable.

It is fair enough (on a UNIX or Linux level) to have a group account for an application which may be assumed by an individual named user, once they have logged in (i.e. using sudo su sharedaccount), but it should not be possible to log in directly with that account. That way, it is still possible to see (via system logs) who logged in, at what time, and who assumed the privileges provided by that shared user account.


Intercepting TLS 1.2 connections I have an application that communicates with the server through a TCP TLS 1.2 connection. The app probably uses certificate pinning. I want to intercept this traffic.
Is there any way to decrypt the traffic except extracting master secret or RSA private key?
Will MITM approach (like sslsplit) work here?

In modern TLS, the private key of the leaf certificate won't let you decrypt previously recorded traffic, because modern TLS has DH (specifically, ECDHE) which provides PFS.
So you need to MiTM the connection or extract the per-connection ephemeral keys from the app.


IPsec installed algorithms What happens if a laptop and a server don't have a encryption algorithm in common?

Does IPSec abort the connection or does it always have default algorithms?

If there are no algorithms in common, the connection will fail.

The RFCs specify "mandatory-to-implement" algorithms which should result in the two sides always having something in common, but those are updated by newer RFCs, up to the point that previously "mandatory-to-implement" become "must-not-support". This is because IPSec is an old standard. So if one side is much older than the other, they can have zero algorithms in common.

Current RFC 8221 says "ENCR_AES_GCM_16" is required. That is a good algorithm. You should make sure you can use that.

If you can't use that then use ENCR_CHACHA20_POLY1305, and if you can't use that then use ENCR_AES_CBC with AH with AUTH_HMAC_SHA2_512_256 (or any HMAC, I guess). Avoid 3DES. CCM is ok, but slower than GCM and is probably only for slow devices with a hardware AES engine, not laptops which can go GCM or phones which can do ChaCha.


Cannot perform SQL injection because of the weird postgresql syntax that is used I have a website that uses ManageEngine Service Plus and it has a SQL injection vulnerability
the linksays that with the help of the following url we would be able to inject postgresql commands to get the complete control of the system:
/reports/CreateReportTable.jsp?site=0 AND
3133=(SELECT 3133 FROM PG_SLEEP(1))

I don't understand the part 3133=(SELECT 3133 FROM PG_SLEEP(1)). I know the databse is Postgresql but when I try to find an appropriate injection command on PayloadsAllTheThings or other sites I cannot anything in that format.
Can you give me tips on how to dump table names or so since it doesn't seem to execute any function other than pg_sleep()?

Attack type
0 AND 3133=(SELECT 3133 FROM PG_SLEEP(1))
is a method of blind sql injection. Blind sqli applies time to determine the content of the database, mostly using if conditions (cf eg SQL Injection Cheat Sheet - Conditional Time Delays). So if you are interested in using this technique for dumping explore it for postgreSQL.
3133 is a fixed value and PG_SLEEP(1) delays the execution at the database for 1 second. So basically this sums up to 0 AND true with a waiting time of 1 second.
You can use this to check if this type of sqli is feasible.
Basically the referenced exploit is a proof-of-concept to show that sql injection is possible.
It is also listed as CVE.
How does it work?
I don't know what CreateReportTable.jsp does exactly. I only found this documentation. The documentation mentions:

To use Advanced Filtering, select the column name such as, Requester
name, region site and so on from the combo box.

which probably belongs to a filtering of sites/branches you can define for your company. So this could be an entry point to check where the issue is in your application. Analyse the query parameter site.
If you want a deeper understanding what SELECT 3133 FROM PG_SLEEP(1) does you can verify it using docker:

sudo docker run -it --rm --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -e POSTGRES_USER=user -e POSTGRES_DB=db -d postgres:latest

sudo docker exec -ti <your_docker_container_id> psql "dbname=db user=user password=mysecretpassword"

psql is the interactive terminal for postgres. In this terminal \dt gives you an overview about what the function pg_sleep does.
The function has a return data type of void - which is basically an empty value. Enter select * from pg_sleep(1) to double check that. This will bring you back after one second and outputs no value. At first the function is applied and then the select is executed.
The empty return value then can be overwritten by choosing a constant:
select 1 from pg_sleep(1);

Mitigation possibilities and impact
The CVE states

SQL injection vulnerability in reports/CreateReportTable.jsp in ZOHO
ManageEngine ServiceDesk Plus (SDP) before 9.0 build 9031 allows
remote authenticated users to execute arbitrary SQL commands via the
site parameter.

So probably it is fixed with an update to a higher version.
The other thing is that you have to consider a possible breach depending if and how long your site has been exposed.


Reconstructing bittorrent data from PCAP I am doing a CTF flag for my school project with a PCAP flag based on this CTF write-up: eindbazen.net - Plaid CTF 2012 - Torrent

I setup a local torrent file containing an .mp3 (the audio is my flag's key) that is shared between two laptops. I followed the exact same steps as found in the write-up above using Tshark and a Python script, and managed to follow-through the same procedure.

However, the final .mp3 output after reconstruction became 1KB bigger (most values different from original when viewed in WinHex), and the audio became jumbled up. I also tried using a .zip file as my torrent file and although 7zip recognizes the folder and correctly displays the original files inside, the .zip folder also got around 35KB larger. When attempting to extract the files inside, 7zip complains of "an attempt was made to move the file pointer" and/or "unsupported compression method for xxx.mp3"

I suspect the Python script may be responsible for causing the hex values to change and "corrupt" the files upon reconstructing it from the PCAP. However, I am a total newbie to  Python as my school covers only the very basics of Python scripting and I don't know how the script logic in the CTF write-up works.

Below is the script from the write-up which I used:

pieces = {}

for line in open('bomb'):
    line = line.strip()

    idx, data = line.split('\t')
    data = data.replace(':','').decode('hex')

    try:
        pieces[idx] += data
    except KeyError:
        pieces[idx] = data

pieces = sorted([(int(p[0], 16), p[1]) for p in pieces.items()])

data = ''.join([p[1] for p in pieces])
open('bomber.out', 'w').write(data)

I would appreciate if anyone could guide/explain to me what I am missing out in properly reconstructing the bittorrent data from the PCAP (using Windows).

When writing binary output data try instead using

  open('bomber.out', 'wb').write(data)

I can't verify if this will help but it might be worth a try.


Wise/Safe to use Firejail within a SELinux preconfigured O/S? In my testing of Fedora 29 and came to find it uses SELinux by default; I installed firejail which is available in the repos. Is there any benefit to running Firejail within this environment or is it redundant and or potentially opening the O/S to even more attack vectors?

To be clear, this question is more of an opinion than a hard fact.
SELinux and Firejail perform sandboxing by separate means. At its core, SELinux is an advanced access control list (using Labels), while Firejail uses Seccomp and Linux Namespaces (https://firejail.wordpress.com/).
Yes, installing setuid program does always have a danger, and since you already have SELinux, it may not provide more benefit. Though not all programs have their own SELinux profile, and fireJail could offer more options in this case.
In security, there is a concept of belt and suspenders approach to add extra protection where possible. Your home had a lock on the doors and windows, do you still use an alarm?
SELinux is relatively hard to configure, compared to fireJail. Though FireJail is not an always-on option like SELinux.
$ firejail firefox                       # starting Mozilla Firefox
$ firejail transmission-gtk              # starting Transmission BitTorrent
$ firejail vlc                           # starting VideoLAN Client
$ sudo firejail /etc/init.d/nginx start  # starting nginx web server

If I have to choose one, I would definitely choose SELINUX as it is built into the Distro and comes preconfigured.
If you are very concerned about the suid, you may want to consider mbox (https://pdos.csail.mit.edu/archive/mbox/) though I cannot speak to its quality or if it is maintained.
Update
Reviewing the text above and as my usage of fireJail has increased. There are definitely advantages to using fireJail. AppArmor and SELinux are more concerned about protecting systems from applications. Many Application profiles will not provide as much isolation for the user.
On Normal firefox, it can see most of the user's home directory.
Under FireJail profile, that is more limited to Download, firefox, and .cache, and so on.
Additionally, Mbox does not seem updated in a number of years.  It likely should not be used.


what is the security issue if session time out is the default value from server configuration? In a web-application the session time-out is not defined neither in the application nor in the application configuration. But the default time out is taken from the IIS. what is the security issue if the session time-out is default IIS server session value? Does issue vary from IIS to web sphere?

A pen test might interpret the presence of default timeout settings as an indication that you forget to set it.

Timeout should be set in a manner that is specific to the application.  For example, if you handle credit cards, PCI-DSS requires a 15-minute idle timeout.


Security risks monitoring JMX I am doing an internship at a big company wich create industrial automated systems for some big company's. They want me to design a way to monitor all the Java based control modules. Now I am going to use JMX, but I have thought of a couple of ways of doing that, and they all include opening some ports. I was wondering what kind of security risks might come out of that.

Thanks in advance

An open port is an attack surface that can be exploited.  Reduce the number of open ports as much as possible. If a service isn't required to be accessed by the open internet,  then don't expose it.


For chip credit cards, what's preventing me from breaking the chip to trigger the magstripe failsafe? In a few cases, the chip in my chip card (or maybe the chip reader) has malfunctioned. After inserting the card and failing 3 times, it said to swipe the card instead. What's preventing me from cloning the magstripe to a card with a broken chip and then bypassing the chip security entirely?

As others have said: nothing. The idea is that the magstripe is a fallback that will be phased out completely as chip cards become more widespread.

Change takes time.


PyCrypto Possible To Check If File Already AES Encrypted? import os, random, struct
from Crypto.Cipher import AES

def encrypt_file(key, in_filename, out_filename=None, chunksize=64*1024):
    """ Encrypts a file using AES (CBC mode) with the
        given key.

        key:
            The encryption key - a string that must be
            either 16, 24 or 32 bytes long. Longer keys
            are more secure.

        in_filename:
            Name of the input file

        out_filename:
            If None, '<in_filename>.enc' will be used.

        chunksize:
            Sets the size of the chunk which the function
            uses to read and encrypt the file. Larger chunk
            sizes can be faster for some files and machines.
            chunksize must be divisible by 16.
    """
    if not out_filename:
        out_filename = in_filename + '.enc'

    iv = ''.join(chr(random.randint(0, 0xFF)) for i in range(16))
    encryptor = AES.new(key, AES.MODE_CBC, iv)
    filesize = os.path.getsize(in_filename)

    with open(in_filename, 'rb') as infile:
        with open(out_filename, 'wb') as outfile:
            outfile.write(struct.pack('<Q', filesize))
            outfile.write(iv)

            while True:
                chunk = infile.read(chunksize)
                if len(chunk) == 0:
                    break
                elif len(chunk) % 16 != 0:
                    chunk += ' ' * (16 - len(chunk) % 16)

                outfile.write(encryptor.encrypt(chunk))

This is how I encrypt file, but if you run it twice or more on the same file it will keep encrypting it no questions asked, I want to add some kind of a if check if it's not already encrypted by AES? Is this possible?

As mentioned by Valmiky Arquissandas, encrypted text is generally expected to be computationally indistinguishable from random data. Thus, the only publicly known efficient way to do

something like check if a file is "not already encrypted by AES" is to run a randomness test.

However, your application should use authenticated encryption anyway,

and if it does then it can use the verification procedure to determine with very

high accuracy whether or not the file was already encrypted by the same key.

Additionally, as Valmiky also indicated, it can use a custom wrapper to let it distinguish with

very high accuracy between files it already encrypted and files that are independent of it.

(However, given your program's code, it would be easy to create a

file that registers as the former without having been encrypted by it.)


Running code generated in realtime in JavaScript with eval() Consider a front-end JavaScript application where menu items needed to be shown or hidden based on somewhat simple logic (roles that user has and some other logical state).

A simple language was introduced to define this logic in a concise human-readable way and every menu item was assigned a string condition, which looks like this: "isLoggedIn() AND NOT role(PARTNER)".

In order to actually check this condition, a simple compiler was implemented, which translates this language into a valid JavaScript code string and executes it using eval() returning the boolean result in the end.

The compiler works by replacing some constructs, like AND, OR and NOT with valid JavaScript equivalents like &&, || and ! using simple regular expressions:

private compileExpression(expression: string) {

  // Adding commas around function arguments (to make them strings)
  expression = expression.replace(/(\w+)\((.*?)\)/g, `$1('$2')`);

  // Replacing "AND"
  expression = expression.replace(/\sAND\s/g, ' && ');

  // Replacing "OR"
  expression = expression.replace(/\sOR\s/g, ' || ');

  // Replacing "NOT"
  expression = expression.replace(/(\s|^)NOT\s/g, ' !');

  // Prefixing predicates
  expression = expression.replace(/(\w+)\((.*?)\)/g, 'Π.$1($2)');

  return expression;

}

This turns "isLoggedIn() AND NOT role(PARTNER)" into "Π.isLoggedIn() && !Π.role('PARTNER)", which is then executed by eval():

public matchCondition = (condition: string): boolean => {

  // Using greek letter "P" for predicate (for shortness and uniqueness)
  // noinspection NonAsciiCharacters
  const Π = this.predicates;

  const expression = this.compileExpression(condition);

  const result = eval(expression);

  return result;

}

The Π is an object with simple predicate functions, which return boolean values like isLoggedIn(): boolean and role(roleName: string): boolean.

The expressions, that are being translated and executed are stored statically in local object as strings and are not accessible from global context. Also, all expressions are written by the developers and are not coming from users of the application in any way.

Is it safe to use eval() this way or should it be avoided at all costs (e.g. "eval is evil", "never use eval", etc)?

What are the possible attack vectors, that could be used to compromise such eval usage?

If expression strings will be loaded from the HTTPS server using XHR/Fetch, will it change the situation security-wise?

The reason to introduce such language and not defining the rules in code directly is that it required that these conditions could be defined in string values, e.g. in a JSON file. The other reason is that such language is easier to read at a glance.

Using eval in this context doesn't create any vulnerability, as long as an attacker can't interfere with the arguments passed to matchCondition.

If you find it easier to read / program it this way, and you're confident that no untrusted input will ever go into your expression compiler, then go for it.

eval isn't evil, untrusted data is.

Please note that it's entirely possible to avoid eval, by extracting the predicates then handling them with your custom functions, for example:

if (predicate === 'isLoggedIn()') {
    return Π.isLoggedIn();
}


w00tw00t.at.ISC.SANS.DFind iptables fix - abusable? It's only an idea. I've recently logged that my server is scanned by w00tw00t tools.

I found many solutions to this, such as use of apache mod-security, fail2ban, etc..

The one I want to speak about, is usage of iptables to block such IP's, based on apache log matching.

If I would use any presented idea, about how to block those scanning address, we must point out important fact, which is requesting IP's are almost every time spoofed, which means, they don't belong to attacker.

Isn't this idea then causing damage to our common users? If I would block out IP, which was spoofed by attacker, I would block someone, who is not causing me a real damage, which means, in conclusion, none of the iptables based defense is usable, or am I wrong?

Or worse, could this server-side preventive measure be used as attack? Such as If I need prevent somebody from accessing site, I will spoof his IP and get it blocked by this preventive system using iptables blocking, isn't it?

Study material:
http://blog.urlvoid.com/w00tw00t-at-isc-sans-dfind-web-scanner/
https://serverfault.com/questions/125607/dealing-with-http-w00tw00t-attacks
http://profi-admin.com/Articles/Showfull/06/05/2010/Administration/How-i-got-rid-of-the-w00tw00t-entries-in-my-server-logs
http://foxpa.ws/2010/07/14/using-dfind-exe-and-blocking-w00tw00t-at-isc-sans-dfind/
http://www.myatus.com/2010/07/17/blocking-w00tw00t-scans/
http://spamcleaner.org/en/misc/w00tw00t.html

TCP connections are not easily spoofed.  The reason for this is the three-way-handshake that must be completed before the connection is considered "established".  The connection must be established before an HTTP request can be sent.

UDP packets are easily spoofed but can't be used to attack Apache.

Since HTTP works over TCP connections, you can be confident that the IP address you are blocking is actually attacking you at that time.

An IP address that is attacking you today might be owned by a legitimate user tomorrow or even potentially at the same time if your legitimate user is infected and is part of a bot net.  It's worth making sure your firewall rules expire some time after the last attack was seen.

If you are particularly worried about false positives, you can create a custom 403 page that includes an out-of-band method of contacting you ( such as an email address or a phone number ) and then block the IP addresses using Deny from 1.2.3.4 in your Apache config.


How safe is it to edit PHP files in Web browser via CPanel? For some reason my Notepad++ can't connect via SFTP since yesterday so I was thinking about editing my site via CPanel file manager which has HTTPS.

I never thought about editing my site in this way, so I'm wondering if it's as safe as SFTP?

HTTPS is as safe as SFTP if handled properly (reasonable algorithms and parameters). And of course if you use reasonable authentication method (which is not discussed here), but on this level, none of the protocols have serious flaw that it would make insecure.


Brotli compression algorithm and BREACH attack I spent a lot of time on BREACH attack implementations. In theory, Brotli compression, like other compressions that use lzz7 family algorithms, must be vulnerable to the BREACH attack.

Experiences and tests that I did on a test environment show BREACH attack validity and performance on gzip. But when I test on Brotli, the attack fails because the compression result length does not show the expected result. For example, it returns equal value for true and false characters!

I don't know the Brotli algorithm details, the BREACH attack is so sensitive to compression algorithm and decision is based on just one byte difference between correct character compression result and false characters. Use of Static dictionary or Context modelling maybe a reason for this behaviour.

Why does Brotli behave like this?

I thought this was quite an interesting question and problem, so I had a go at implementing the attacks myself, but against something other than "true" or "false".

To make things simple I used a static page as a file and injected content into it at the end. The target secret looked like this:

<input type="hidden" name="secret" value="7253b8f45f322b411ce39b12c6e9a84c" />

I used the source of an MSDN page as an example to build around. The full target page source I used can be found here; the secret is on line 33. An important factor here is that the page content includes a lot of other hexadecimal strings, which imitates a potentially more difficult attack scenario.

To attack this, I used a fairly naive method:

Append <input type="hidden" name="secret" value=" to the end of the page, then append our previous guesses (if any), then append 0000 to ffff in sequence and look for the smallest result when compressed.
For the 4-character hex string that produced the smallest result, add the first three characters to our guess. Dropping the last character is important as there is quite a bit of uncertainty in the last character, and if it does get it wrong it tends to just repeatedly generate the last character for all remaining guesses (e.g. 7251 on the first would generate 1111 on all subsequent guesses).
Loop steps 1 and 2 until we have <4 characters left to guess. Run through the remaining possible combinations, in each case adding " /> to the appended string to complete the tag.

I wrote a complete implementation with parallelism in C#, which you can find here.

Here are the results for GZip:

................................
Guessed f45a
Secret: 7253b8f45
................................
Guessed f322
Secret: 7253b8f45f32
................................
Guessed 2b41
Secret: 7253b8f45f322b4
................................
Guessed 11ca
Secret: 7253b8f45f322b411c
................................
Guessed e39a
Secret: 7253b8f45f322b411ce39
................................
Guessed b12a
Secret: 7253b8f45f322b411ce39b12
................................
Guessed c6e9
Secret: 7253b8f45f322b411ce39b12c6e
................................
Guessed 9a84
Secret: 7253b8f45f322b411ce39b12c6e9a8
Reached last block.

Guessed 4c
Secret: 7253b8f45f322b411ce39b12c6e9a84c
Done!

This took only a couple of minutes to run and it correctly discovers the secret.

Now let's try again with Brotli, using the "fastest" compression mode, with the same configuration for the attack:

................................
Guessed 7253
Secret: 725
................................
Guessed 3b77
Secret: 7253b7
................................
Guessed 4aa7
Secret: 7253b74aa
................................
Guessed 47aa
Secret: 7253b74aa47a
................................
Guessed 0aaa
Secret: 7253b74aa47a0aa
................................
Guessed 0aaa
Secret: 7253b74aa47a0aa0aa
................................
Guessed 3a0a
Secret: 7253b74aa47a0aa0aa3a0
................................
Guessed 0aaa
Secret: 7253b74aa47a0aa0aa3a00aa
................................
Guessed 4aaa
Secret: 7253b74aa47a0aa0aa3a00aa4aa
................................
Guessed 2aaa
Secret: 7253b74aa47a0aa0aa3a00aa4aa2aa
Reached last block.

Guessed 7a
Secret: 7253b74aa47a0aa0aa3a00aa4aa2aa7a
Done!

Not so good. The second guess goes wrong and this throws off the whole algorithm. So maybe we need to be a bit more cautious, and only accept 2/4 characters per block instead of 3/4.

................................
Guessed 411c
Secret: 7253b8f45f322b41
................................
Guessed 1c77
Secret: 7253b8f45f322b411c
................................
Guessed e377
Secret: 7253b8f45f322b411ce3
................................
Guessed 9b12
Secret: 7253b8f45f322b411ce39b
................................
Guessed 1277
Secret: 7253b8f45f322b411ce39b12
................................
Guessed c677
Secret: 7253b8f45f322b411ce39b12c6
................................
Guessed e977
Secret: 7253b8f45f322b411ce39b12c6e9
................................
Guessed a84c
Secret: 7253b8f45f322b411ce39b12c6e9a8
Reached last block.

Guessed 4c
Secret: 7253b8f45f322b411ce39b12c6e9a84c
Done!

And there we can see it works again! So it turns out that it isn't impossible to attack Brotli in this way.

The key part that explains why your attack failed is the pre-defined dictionary:

  Unlike most general purpose compression algorithms, Brotli uses a pre-defined 120 kilobyte dictionary, in addition to the dynamically populated ("sliding window") dictionary. The pre-defined dictionary contains over 13000 common words, phrases and other substrings derived from a large corpus of text and HTML documents

(from Brotli - Wikipedia)

So do "true" and "false" appear in this dictionary? Yes! I found a textual copy of the dictionary here and you can find true and false on lines 6829 and 1204 respectively.

The reason my attack works and yours doesn't is that I'm looking for something that isn't in the dictionary. For a single token like "true" or "false", using the dictionary index is much more efficient than trying to fold the characters together with another instance in the stream using distance encoding.

But why was it harder for me to perform a successful compression oracle attack using Brotli than with GZip? There don't appear to be many hexadecimal strings in the dictionary. I believe this is simply because the Brotli compression system is more complex than GZip. GZip uses a combination of LZ77 and Huffman coding, which has a strong focus on duplicate elimination, which works great for a compression oracle attack. Brotli, on the other hand, has more tricks up its sleeve, leading to a higher likelihood of other compression mechanisms being used instead of duplicate elimination during the first few blocks when the duplicate isn't very long. One way to improve the attack for Brotli would be to brute-force a longer set of values in the first block (e.g. 6 or even 8 characters) to try to elicit a duplicate elimination. This is much slower but would likely force a reliable compression oracle out of the Brotli compressor.


Two factor authentication using CVV and 3D secure code While making online by Debit/Credit card, instead of using OTP (received on mobile), one can use a 3D secure code (verified by visa or mastercard) which is know to user. Should this qualify for two factor authentication (as all details are what you know category but not from what you have or what you are categories)?  Secondly, in case of compromised system (hacked computer) this will lead to total compromise (no forward secrecy). I know OTP through mobile is not always available (no network or network congestion problems) but using this scheme is not adding any security (in case oh co-existing adversary i.e hacked machine). Please comment.

No, asking for a password or secret answer via 3D Secure is "something you know" and not another category of authentication as the cardholder data (number, expiration date, code) could also be "something you know". To qualify for "something you have" it will need to be verified in real time.

Applications such as Google Authenticator and 2FA dongles can work offline so they would work in a situation where mobile reception is poor.

Although 3D Secure is not two factor authentication, it can add security as the 3D secure details are not sent to the merchant themselves with the rest of the cardholder data. They are often sent directly to an authentication authority such as Arcot, and then they return a code to the merchant indicating if the 3D secure details were correct and that the card processor will take on the liability for any fraud rather than the merchant. Having said that, the current implementation leaves a lot to be desired. Often the Arcot authentication page, although it is HTTPS, is loaded within an IFrame within the merchant's website, not allowing your average user to check the address bar to verify where their 3D Secure answers are being sent.


Signup/Signin with Mobile+PIN Telegram implements signup/signin with mobile number and a 5-digit one-time password. I believe the flow to be something along the lines of this:

Grab the mobile number, generate an OTP, cache it and send it via SMS.
When the user introduced the TOTP, check whether there's an account with matching mobile number, creating it if necessary. The user is now authenticated.

My question is, how is this as safe as "tradicional" registration/login with a fixed password? If I'd be to implement the same flow on an application of mine, what pitfalls should I watch out for? How can I guarantee that a user's account is not compromised by such flow?

The question is not if it's "as safe as" traditional password: it's not meant to achieve the same thing.

For telegram, a "user" is a phone number: anyone having access to that phone number is, by definition, an authorized user. In other words, it delegates the security of you account to you and your phone company.


What are the risks of still using a 1024-bit certificate in a private network? One of our colleagues ran a Qualys scan on an internally used product and found that the product still uses 1024-bit certificates for its modules to communicate with each other. The vendor says that this issue will be targeted in a future release (a few months at the least).

I read a few links (Symantec FAQ and a very informative blog post) about the risks.

Since the product is used in a private network, I am of the opinion that we shouldn't worry about the certificate issue a lot. It is less likely for a hacker to be aware of such a product unless he/she is an insider. The weak certificate can definitely lead to leaked cipher suite and in turn leak the entire communication. I wouldn't deny that. My stance depends on the assumption that the attacker doesn't have access to the internal network.

I would like to know from the community what are the other scenarios that I am not considering here.

If I understand your scenario correctly:

You're talking about a security mechanism that relies on signatures made by 1024-bit RSA keys.
You have a relatively easy way of deploying updated certificates and revoking the old ones. It's a matter of days, maybe months, but certainly not years.

The public record for breaking RSA is a 768-bit key. Nation-states might be willing to expend more effort to go further, but 1024-bit keys still are out of reach by publicly known methods.

Under these assumptions, there is no meaningful security risk of using 1024-bit certificates (except maybe if you're worried about nation-state attackers, but even then RSA key size are not your biggest worry). There is a risk of non-compliance, because compliance rules tend to address scenarios that are not as favorable as yours (deployments to third parties that you can't realistically force to update, embedded devices that simply can't be updated, etc.).


What Can I Do While I'm Waiting for "Chip and Pin" Credit Cards? For the second time in 8 weeks, one of my American Express (AMEX) card numbers was stolen.  I do use the card online, but only at reputable (and SSL/TLS enabled sites).  I use it in the real world, too, although nowhere shady.  While AMEX's fraud prevention is good and they detected the attempted fraudulent usage, it's quite a hassle when they have to issue a new card.  I've got several things set up to auto-pay, so I have remember all of them, log into their sites, and update my payment info.

I know that chip-and-pin cards are finally coming to the US in the next year or two.  But i the meantime, what can I do to protect my credit card number better while still being able to use it?  For online transactions, I wish I could set up one-time numbers, but AMEX no longer offers that service.  Anything else I can do?

The first thing I would do is a full audit of any device you enter your card number into. Obviously you can't audit the POS machines at the stores you use, but if it was a store issue, they would have gotten a notice by now. So the problem is probably in the computer(s) you use for online transactions. I'd go to any machine you've typed your number into and run a full virus/malware scan on it. Being compromised by 2 separate sources in such a short time isn't entirely impossible, but still unlikely.

I wish I could provide more insight to a solution to prevent future compromises but I'm not privy to any technology that'll help here. I realize I didn't really answer your question, but I still think my suggestion is very much worth looking into given the lack of time between compromises. It would certainly be a top priority of mine if I was in this situation.


How to store login information on the user's device I'm developing an application that needs to store various pairs of username/password to automatically log in into third party services so that  users don't have to insert them each time they open the application.

However, I'm facing the problem of storing them safely: even though they are saved on the user's hard disk (and they remain saved there except for the moment I log in to the third part application, when I send them to the server through some APIs) nothing prevents a malicious program to steal the file. I'd like the application to be open source and the location of the file will not be secret (anyway, security through obscurity does NOT seem to me a good idea, but exactly the opposite). I thought that maybe making the user insert a password and encrypt the file would solve the problem, however, I find it a bit redundant: the user must insert a password to access his computer, doesn't he?

I was wondering how programs that manage user login information (such as Mozilla Thunderbird, OneDrive, and so forth) store users' passwords safely on the HD.

Increasingly operating systems and runtime environments are offering APIs to digital wallets. And there are networks let components which can be be used by enterprise systems like hashicorp and cyberark. There's lots to choose from.

When you write your own password manager you take responsibility for your users' passwords. You also potentially exclude a lot of users.

If it were me I would write an interface to get the credentials from a separate process then bundle the solution with some simple examples.


How to check big video file if can't check it entirely? There size limit on VirusTotal, some videos are very big. What if cut off part from the video and send part of it. Is it possible? What part of it, where malware can be?

Most file formats (such as videos) aren't going to execute code unless:

The file is somehow a valid executable and you purposefully execute it
The application viewing it (e.g. a video player) has a specific vulnerability, and the file contains crafted content to exploit that specific vulnerability

In either case, there is no way to give you an answer without knowing exactly what type of malware. For instance, #2 could be a vulnerability in the video header, or the video data itself, which could be any part of the file.

In general, if you aren't trying to execute a video file and your video player is up to date, you probably don't need to check your video files for malware.


Are there enforcements on host configurations to protect other computers? I was reading the Wikipedia article on Smurf attack. As far as I understand, the only protection from a smurf attack is to rely on other people to configure their hosts in a way that these hosts won't participate in a smurf attack.

That is, you need to trust others to protect your computers.

If that's the case, I feel like there should be some kind of enforcement on hosts to indeed make the configurations for a collective network security. Because in theory, an admin can say: "like a give a damm about what happens to other people" and refuse to configure his network to prevent to participate in such types of attacks. I know that it would be a very pointless act but in theory it can happen.

So my question is, are there such enforcement policies?

No, there are is no technical enforcement for such attacks (I take you mention the Smurf attack as an example).

TCP/IP comes from a place where the reliability of the network was key, not its security. This is why there are no basic security elements built into the protocol and, historically, we relied on "best practices" (like the one to change the default for routers in the case of the Smurf attack) to protect ourselves and others. Some protocols were also changed to disable malicious behavior which was not thought of initially.

There are however organisational  ways to address such issues, a typical one being blacklists of various sorts. This does not work too well, is hardly scaleable but this is the best we have today.


How can I prevent `am` from starting my activity? I have an Android app and it has 3 activities; A, G and B. When the app starts users see Activity A. If user wants to navigate to activity B, app starts activity G and asks for a password. If the password is true user is directed to Activity B, if not back to activity A. None of the activities are exported. Problem is on rooted devices a user can start activity B from command line using

am start -n package.name/package.name.B

command. How can I prevent this?

Either do the actual security check in activity B or make G send on some kind of token to B in the Intent.

The token can be any random data generated at runtime. Since G and B share the same process they can easily get access to it, but other processes cannot (not without manual debugging).

But note all of these only make it difficult for users to use your app without the password. The user does control the binary and memory, so can bypass any protection you put in.


Security of Web Game over WebSockets? Project that I'm working on depends on WebSockets to communicate between the server and client browser for all interactions within the game.  I'm attending university for Computer Security, but I'm still unsure about potential attacks against the current validation system.

I'll start off real quick and say that at this current time I cannot use Secure WebSockets due to Autobahn (still ) not supporting Secure WebSockets.  If I have to change my framework that I'm using to solve any problems I will though.

As it works right now, on connecting the user requests the server's public key (2048 bits) which can be changed at a regular interval, server gives the public key to user.  To validate the key a quick exchange of sending a constant known string encrypted with the key is sent to the server and the server verifies the key is correct to the user.  After verifying the key, the client encrypts the plain-text password provided by the user and sends it to the server.  Server decrypts password, hashes password with bcrypt and validates the password in a timing-attack resistant way (No early out, nearly constant runtime).  Encryption uses a randomized nonce as a part of the padding to prevent replay-attacks.

The part I'm most suspect about is how my current implementation "tracks" which socket belongs to who.  Basically if a "login" request is handled by a socket and the result is positive then the socket gets "named" by setting a special attribute on the socket to the username provided in the login request.

On disconnection the socket is destroyed and there are staleness checks for sockets that haven't received a request in a long time to be automatically logged out.  The only way to set the attribute on a socket server-side is to perform a successful login request.

I'm aware of the MITM attack possibility regarding the key exchange.

My concerns are what are the flaws in this system, and how should I prevent or mitigate them?

Essentially, you have a password equivalent string (the public key encrypted password), which is sort of protected by the requirement for the constant string to be sent. However, if it is a constant string, an attacker could just replay an old call - they can get the key (it's public) after all. The randomised nonce must also be transferred to the client, or be generated on the client - either way, since it happens before authorisation, an attacker can presumably get it.

It might be worth considering including some form of token in all requests, effectively decoupling the specific socket from a given user and therefore bypassing your main area of concern - presumably it doesn't really matter which socket a user comes in on, as long as you can prove that the request comes from a specific authorised user. This also has the advantage of allowing the same backend processes to handle alternative login methods (for example, if you added an API to your application for mobile application use). This also ensures that user sessions can be continued over a restart of the server side process - currently, from the sounds of it, your users would find themselves logged out if you had to restart the server process, even if the process restart was momentary. Presumably, the flags on specific sockets wouldn't be set in this case, without a new login.