Password policy for elderly clientele I work for a company in which the age of our average user is over 70. We have an app* that helps them collect and submit physiological data to their doctors.
I found this question that I believe is helpful if you're helping your mother set a password: Secure Memorable Passwords for Older Users
However, we're struggling to develop a policy for our 5000+ users, particularly given these additional wrinkles:

The users' accounts are set up at the doctor's office by a
non-technical medical professional that probably thinks "Dog123" is a
good password. We can educate them about password complexity, but
getting them to similarly educate users on-site is a different
ballgame.
Many of our users don't have an email address, making it infeasible to send a password reset email
Password managers are also infeasible, because we can't expect our medical staff to be setting up LastPass for the users (especially with no email address)
This is medical data, with all the regulation that comes with it.

Any suggestions for a password policy that secures our sensitive data without frustrating and driving away our entire user base?
*EDIT: Mobile app. There is a web app in the ecosystem in which medical staff reviews collected data, but it currently has no functionality for the patients.
ALSO EDIT: A lot of debate here between "you can assume they have smart phones" and "no you can't." It's a bit moot in our case because we provide $20 Androids to patients without one.

Disclosure: I work for the referenced company, and I'm not sure how to get the suggestion in this post across without it seeming like a sales pitch. Here goes.
It seems to me that "memorized passwords" and "our average user is over 70" are not going to play well together. Have you considered solutions other than passwords? You'd want something which is:

A physical object; ie non-memorized
Inexpensive for the doctor's office to hand out
Easy to use even for the (potentially severely) technologically-challenged.
Meets the security (and/or compliance) requirements for this product. Ex.: would you be allowed to use a physical object instead of a password? What if you coupled it with a weak password or knowledge-based set of questions.

You could consider having the doctor's office generate random passwords and print them out, but we all know that passwords of the form x7a8Cqr4dPt20 are not user-friendly.
The solution that comes to mind is Entrust Grid Cards (disclaimer: there may be other vendors who have similar features, but I'm not aware of any)
The doctor's office could print off a grid card on their standard office printer; when using the website / app the user will be challenged to provide three cells from the grid, if they lose the paper then they go back to the doctor's office and get a new one printed.


Can a mismatched server encoding on HTTP POST or GET result in a security issue? It is possible for a server to parse HTTP POST and GET data with a fixed encoding or one that is dynamic with the client's response.

Consider the situation where a client uses UTF7,32 or any other encoding other than UTF8.  The server is then hard coded to only use UTF8 when reading the data.

Question

What types of security issues can occur when a mismatched encoding (from server to client)  or decoding (client to server) occur?
If this is a vulnerability, what kind of tools scan for this in Eclipse or Visual Studio?

Request from client to server

Assuming there are no vulnerabilities in the UTF-8 decoder on the server (e.g. overlong UTF-8 encoding or illegal UTF-8 continuation bytes) that could bypass a filter or other encoding routine I can't imagine any sequence that could be decoded to anything dangerous in itself. It is not like UTF-7 where a sequence such as +ADw- can bypass a filter or encoder as they don't understand the encoding.

This of course is assuming that the UTF-8 is decoded and then reencoded for other backend components that may be vulnerable (e.g. a backend process that decodes in UTF-7 could be vulnerable if the raw bytes are sent from the front-end).

Response from server to client

Again, if the client UTF-8 decoder is free from vulnerabilities itself this should be safe. This is assuming the client is interpreting the server response as UTF-8 encoding - I wasn't sure from your question whether the client sending UTF-7 was also expecting UTF-7 in the response. If this was the case then yes it could be vulnerable to XSS via unencoded tags passed from the server. If not then another thing that could throw a spanner in the works are browser plugins (e.g. Flash/Silverlight) but these would normally either get their input from the browser once the text had been decoded, or from the server directly (in which case your pre-condition of only reading in UTF-8 across the network would still apply).


How can I detect if IETF TokenBinding is in use for bearer tokens? Token Binding increases the security of traditional bearer tokens (cookies).

This Blog describes that ASP.NET can use Token Binding. As a security consultant, I'd like to observe or detect that this is done from an external perspective.

https://blogs.msdn.microsoft.com/dotnet/2015/11/30/net-framework-4-6-1-is-now-available/

What technique (netmon) or tooling allows me to determine if token binding is in use for a given website?

When a server supporting the Token Binding protocol receives a bound
     token, the server compares the TLS Token Binding ID in the security token with the TLS Token Binding ID established with the client.  If
     the bound token came from a TLS connection without a Token Binding,
     or if the IDs don't match, the token is discarded.

(draft)

The problem is that I don't believe any client is implementing token binding which follows the draft. So you should create a test client yourself and then clear or change the private key and the bearer token should be dropped.

I wouldn't know why a client would want to have this tested on its servers. Are there any clients (software clients) who support token binding? It seems like .net is one of the first pieces of software to support the protocol. Also, the protocol is still a draft so it will take some time until we see adoption.


Cracking a 6-character alphanumeric password Windows dialog box To put this problem in context, I have a touch monitor screen whose firmware program is protected by a password.

The firmware program is downloaded over RS232 via a Windows utility program provided by the manufacturer of the touch screen.

The problem is, upon completing the download, the utility program asks for a 6-character alphanumeric password, and I have no idea what it is. The company I bought the screen from has closed down since, so there's nowhere I can get hold of the password.

Since it's an alphanumeric password, (2*26+10)^6 = 56,800,235,584, my questions are:

How easy is it to crack the password?
What are the possible ways of cracking it?
How would you attempt to crack it? (ex. robot program that will try to enter all possible passwords on human's behalf, etc.) What software tools would you use?

You can easily inject characters as if typed either via USB tools or code. Depending on the latency of trying a code and assuming no lock-outs it may not take too long to iterate through every possibility.

A better option may be to attach a debugger, enter any code and step through until you see the check of the input string. Change the logic of the result and then let execution continue - depending on the language and hardware this may be straightforward or painful.

I'm assuming you've tried Google hacking it and user forums in-case it's a widely known default...


Advantages to killing sessions after 5 minutes? I'm dealing with a server that isn't mine to configure. Something somewhere between me and this server kills any connection after 5 minutes if no traffic passes between the two machines. This includes active connections where a command is running on the server; specifically, I've demonstrated that this disconnection occurs using an SSH connection (running a bash command that doesn't print any output for more than 5 minutes) and a SQL database (running a SQL command that lasts more than 5 minutes). It also disconnects if I go read something and don't send any commands for 5 minutes, of course.

For the SSH setting, the group responsible for the server has recommended that I enable keep alive client side. They haven't provided any suggestions for the database connections.

I'm completely confused, though. What is the security benefit here? For SSH, I can bypass their settings completely from the client side, and they even recommend doing so. (The latter means there cannot even be a "security through obscurity" argument, since it won't be obscure because every user will need to know about it. Not that I think this would foil an attack even if it were obscure, especially since I found out on my own before they even recommended it.) For both, this demonstrably degrades availability. I could potentially see that disconnecting active sessions after a few hours of inactivity might be beneficial (Although the possible threats of long open sessions aren't immediately clear to me.), but every 5 minutes? This means I can't even read a DBA.SE post while I'm working out my SQL without being disconnected. Is this as ludicrous as it sounds to me, or is there something I'm missing?

Clarifications

Some points have been mentioned in comments, so I'd like to clarify a little.

I am able to consistently reproduce the timeout at 5 minutes. I used commands that record a timestamp server side every few seconds, and after a disconnect, the last timestamp recorded was always exactly 5 minutes after the first timestamp. So the disconnects were never sporadic.
Shortly after I wrote this post, the system/network admins responded that this is indeed intentional. I quote, "More fallout from the 5 min time limit set on the F5s a few weeks back?" I'm not sure what an F5 is; some Googling suggests it's a very expensive switch, which corresponds to someone who was trying to find a workaround for my DB connections later mentioning the switch settings.

(I don't believe this information invalidates any answers.)

I'm completely confused, though. What is the security benefit here?

Nothing.  The most likely scenario is that something in between is timing out the connection after 5 minutes to conserve resources.  That could be a firewall, a WAN accelerator, an SSL accelerator, etc.  Or it could be just a bad default setting.  Who knows?

Network admins often have different concerns than everyone else, that often times can come into conflict with others.  We work in a silo-ed world where the holistic picture isn't taken into account.

Don't assume there's a particularly good reason for every setting, but leave room for the potential that the 5 minute timeout was a quick fix for some other problem they're having, and your application problem was blowback.


Password manager vs remembering passwords I have always thought that you are not supposed to use a password manager but to keep your passwords in your head, but lately I have thought about the pros and cons of having a password manager.

Some areas might be: password length, key logger prevention, entropy between passwords, accessibility.

(I'm not asking how to create hard but memorable password! It might be a part of the solution but not the whole question.)

Finally, is there any way of combining them: keep a half in the manager and typing the other, to avoid key loggers.

I wrote this last year on the pro's and cons of password managers:

Pros:

Great balance of convenience and security - people tend to choose simple passwords and the reuse the same password (or base) because there are so many of them and you have to enter them so often. With 1Password or Lastpass you can generate a truly strong password (at least for your critical accounts) but still have the convenience of having it auto-filled or at least available written down on your phone. A real benefit is also in things like secret questions, this is commonly a weak point where a really strong password has a 5 letter dictionary word as a secret question answer. You can now generate strong secret question answers also
Portability - the problem with using your browsers save password function is that unless you combine it with something like Google or Firefox sync it is not portable. Even then it is currently not available on your phone (at least not the iPhone, not sure whether the Android browser has Google sync)
Secure storage - your sensitive information is encrypted in storage and protected by a master password. This is a lot better than just writing it somewhere or storing in a note or unencrypted spreadsheet
Not just for passwords - you can store bank details, insurance numbers, credit cards, passport numbers, etc which can save you time entering in these details and provide you secure access to the details on move. You can also store files like scans of your documents or your private keys
Improve your memory - on sites I hardly ever use, and government sites with those complicated usernames I can never remember these details. Launch up the iPhone, 1Password and everything to hand with easy search
People also add anti-phishing / anti-malware to this list but that one I don't agree with. You still have to enter your master password which malware can capture, if you have it on your phone and enter the password again it can be captured. If you launch websites from the tool I guess it could be anti-phishing but that's the same as typing it in directly or using your bookmarks

Cons:

Single point of failure, keys to the kingdom - if you sync your keychain to your phone or have it on your desktop or laptop some could get access to that. If your master password is weak then you lose everything in one go. As far as I'm aware 1Password does not offer a hardware based two factor authentication option for the master password which would reduce the risk of this significantly. Lastpass does offer a using a yubikey as a two factor mechanism but because Lastpass has a web application it can suffer from web application vulnerabilities (e.g. XSS) which could leave your account details and at worst case passwords exposed.
Terms and conditions - it is still technically 'writing a password down'. This maybe against the terms and conditions on things like your Internet Banking site. This may reduce or remove any protection you get in case of a fraud. You can always check this and not store the password for these sites
Trust in the cloud - it is supposed to be encrypted in storage but if you do synchronize the data some people will never trust that 1Password or Lastpass does not have a backdoor, potentially allowing a malicious or disgruntled employee access. All software has vulnerabilities, again a serious one could allow an attacker access to your data

Another option is to use a password vault stored in a hardware encrypted device like an Ironkey. Versions come with a password manager loaded in. It is a little bit less convenient as you have to attach it to a USB drive and have read access to this but it is definitely more secure. It mitigates some of the risks highlighted above, it is hardware encrypted and only stored on your device. Also if your Ironkey is on your physical key chain you are far less likely to lose it than your phone or laptop. You can also remotely destroy it if you do manage to lose it.

For the online remote destruction you need the enterprise version of the key. The remote destruction is a feature in the management console. When the key is plugged in it, it phones home. If the destruction has been activated, at that stage it becomes unusable and all data is effectively lost (believe by trashing the decryption keys). There is also an offline mode (similar to an iPhone), where you can set it to auto self destruct after 10 failed master password attempts.

Conclusion

Overall I believe the pro's outweigh the cons. If you have no option for two factor authentication then having a strong password is your only defense. Using a password vault just makes this a lot more practical and convenient.

There is no reason why you could not keep half the password in a password manager and remember the rest, it would make it more difficult for a key logger to capture your password, however the trade-off for usability may not be worth it. A better option maybe to use two factor for your really sensitive information and a password manager for the rest


Is there any working solution against large SYN Flood request? Fighting against a large SYN Flood attack that is happening every 2 minutes repeatedly.

During attack, number of syn-rcv is between 290-550

ss -n state syn-recv sport = :80 | wc -l

CPU 100% (htop output)

Tried cloudflare firewall, not helping at all
CSF in action, seems can't help

backlog increased to 16K, SYN Cookies enabled... nothing helped..

Cloudflare should terminate all connections and thus prevent these spoofed syns from arriving at your server. Appears to be a misconfiguration since this traffic is being seen at your server.

Per their documentation:

  How does Cloudflare mitigate SYN Flood attacks?

  Cloudflare mitigates this type of attack in part by standing between the targeted server and the SYN flood. When the initial SYN request is made, Cloudflare handles the handshake process in the cloud, withholding the connection with the targeted server until the TCP handshake is complete. This strategy takes the resource cost of maintaining the connections with the bogus SYN packets off the targeted server and places it on Cloudflare’s Anycast network. Learn more about how Cloudflare's DDoS Protection works.

  Source: Cloudflare - SYN Flood Attack

From the same source (Cloudflare - SYN Flood Attack), mitigation techniques include:

  Increasing Backlog queue

  Each operating system on a targeted device has a certain number of half-open connections that it will allow. One response to high volumes of SYN packets is to increase the maximum number of possible half-open connections the operating system will allow. In order to successfully increase the maximum backlog, the system must reserve additional memory resources to deal with all the new requests. If the system does not have enough memory to be able to handle the increased backlog queue size, system performance will be negatively impacted, but that still may be better than denial-of-service.

  Recycling the Oldest Half-Open TCP connection

  Another mitigation strategy involves overwriting the oldest half-open connection once the backlog has been filled. This strategy requires that the legitimate connections can be fully established in less time than the backlog can be filled with malicious SYN packets. This particular defense fails when the attack volume is increased, or if the backlog size is too small to be practical.

  SYN cookies

  This strategy involves the creation of a cookie by the server. In order to avoid the risk of dropping connections when the backlog has been filled, the server responds to each connection request with a SYN-ACK packet but then drops the SYN request from the backlog, removing the request from memory and leaving the port open and ready to make a new connection. If the connection is a legitimate request, and a final ACK packet is sent from the client machine back to the server, the server will then reconstruct (with some limitations) the SYN backlog queue entry. While this mitigation effort does lose some information about the TCP connection, it is better than allowing denial-of-service to occur to legitimate users as a result of an attack.


When connecting to public wifi, is login information resent if you were previously logged in? i’m paranoid about using public wifi but sometimes I have no choice.  I have read that it is unsafe to log in to accounts using public wifi.  My question is: If I log in (for example to Gmail) using a secure connection on my laptop, then take my laptop to a public location, open my laptop to see that I’m still logged in, and then connect, does my log in information get re-sent?

I am thinking that if my log in information does not get re-sent, then maybe it’s a bit safer?

The logins to sites like Google use one of the modern authentication methods. Often OAuth.

These use tokens issued by the site to your browser to indicate that you have logged in. There are typically 2 timeouts for authentication on these sites.

There may be a login timeout. This may be updated when you do something active on the site or it may be a fixed timeout. Generally measured in days, sometimes weeks or months. When it expires, you have to put your login credentials back in.

On top of that, there is a token refresh timeout. Tokens are typically short-lived since that reduces the amount of work the servers have to do to check that the browser using the token is the one it was sent to originally. The token is checked on each page refresh (sometimes via socket connections as well) and can be refreshed by the server during those interactions. If the token expires, the server will typically recheck your login credentials and issue a new token without your interaction if it thinks the credentials and the browser are still valid.

This is what lets you have extended sessions with a service without having to log in all the time. You will note that banking and finance services don't allow extended sessions as they are certainly less secure. But with careful processing, it can be a fairly safe mechanism and is used, for example, on Azure & AWS management portals.

So, to your question. There is reauthentication going on. A secure service will check that the token is coming from the originating IP address and if not, will force a recheck of credentials (which doesn't necessarily mean a new login for the user). But all of that happens over HTTPS (TLS) and so should be invisible to a Wi-Fi based hacker.

I say should because there are lots of ways for this to go wrong. The service may not be validating tokens correctly for example which can lead to token replay attacks (though that needs something to have access to the token from your browser). You could be subject to a Man In The Middle Wi-Fi attack which intercepts your TLS connection. Browsers are generally better at reporting on these now, if you get a warning to say that there is something wrong with the certificate for a site while you are on Wi-Fi, that is a pretty good indicator of a MitM attack happening. There are also various ways for the service to have messed up the configuration of their TLS making it weaker.

For security, you should always use a good VPN (there are many really poor ones) and have that turned on from the outset.


About slowloris dos attack in skype So I scanned my home pc for fun with nmap "vuln" script and it said something about the slowloris vulerability at port 443 . So I started up slowloris.pl and it really worked . After that I wondered what was on port 443 and found through an nmap scan that it was skype . So here is my question/s :
1) Is skype really having some kind of unpached vulnerablity / bad implementation in windows ?
2)What would be the worst case scenario of an successful slowloris attack on windows (besides temporary downtime of either the port or the whole networking in the affected computer )
3)How easyly exploitable is the vulerability ?
4) Is there any knowen solution ? Well I cant close the port because well 443 is 443 and I don´t wanna redirect all my encrypted traffic .

I can answer part of your question. :)

2) The worst case scenario of Slorloris is a short-term denial of service (unless it's used as part of a social engineering attack against admins, perhaps).

3) Since you were able to replicate it, you already know the answer: it's easy! But there's one mitigation: if there's anything that blocks ports (firewall, router with NAT, etc), it's not exploitable at all.

I don't know the answer to 1) and 4), and googling "skype slowloris" doesn't surface any results. Are you 100% sure it was vulnerable? It's possible it's just a classic DoS (like port exhaustion), not slowloris.


AES-256 ESSIV in dm-crypt I am playing around with disk encryption. https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt#iv-generators says:

  essiv: "encrypted sector|salt initial vector", the sector number is encrypted with the bulk cipher using a salt as key.
  The salt is derived from the bulk cipher's key via hashing.
  Note that while the cipher algorithm is always as the same as the algorithm used for data encryption,   its key size depends on used hash algorithm.
  In other words, while data encryption can use AES-128, the ESSIV calculation with SHA256 will use AES-256.
  ESSIV takes hash algorithm as an option, so the format is essiv:hash, e.g. essiv:sha256.
  Available since: 1.1.0 (kernel 2.6.10)

The way I see it, I hash original KEY (32B), use this hash as key for bulk cipher (?) and encrypt sector number (8B) with it: result is used as IV for AES-256.

Now, do you have any idea which bulk cipher is it about? And what about its IV? I can't find anything about it in code: https://elixir.bootlin.com/linux/v3.10/source/drivers/md/dm-crypt.c#L256. Thanks.

EDIT: since ESSIV takes sector number 8B long it also has to be padded, possibly with zeros or PKCS7.

Seems that in my case it was sufficient to use AES-256 ECB for ESSIV iv generation. I probably deceived myself by misinterpreting sentence:

  Note that while the cipher algorithm is always as the same as the
  algorithm used for data encryption..

Although it makes sense, since IV usage in generation of primary IV is unnecesary in this case.


Is it ok to use the same SSL certificate for both HTTPS and SOAP-level signing/encryption? I'm currently looking after an integration platform with SOAP based web service connections out to partner organizations.
At the moment, the same SSL certificate is used for both transport level security (HTTPS over the public internet) and for message level signing and encryption in the SOAP payloads.

Is this typically considered bad practice? The immediate downside that comes to mind is the fact the key now exists in more than one place and is a little more vulnerable than if it was in one place. Compromising the key would break both the HTTPS and SOAP level security.
Are there more issues to be aware of here? How is this handled in other places?

Ok so without wanting to answer with "depends", here's my thoughts on this.

Signing the SOAP messages with a certificate provides the ability for legal non-repudiation of the message contents.

You're right that having the same cert used means that you're potentially over exposing the key.

So this is where the "depends" comes in.

If your use case is to provide assurance that the message is being sent, unchanged, by who it's signed by, then you're doing this wrong, and you should use separate certs and treat them properly.

If your use case is more to simply verify that the message body has not been tampered with in general and that it's been signed by something that has access to this shared private key, then I'd be ok with it personally.

Cheers,
Pete


Spam that comes from names in my address book, but not their email addresses I've recently received two spam messages that show a possibly worrying degree of knowledge about my contacts, and I'm wondering how concerned I should be.

Specifically, the names -- but not the email addresses -- that they appear to come from are family members.  They share the same last name as me, but it doesn't appear to be random name guessing -- the only two messages I've received with a sender sharing my last name are real first names of family members (no "misses").  Edit: one of the names is fairly common; the other is pretty rare (didn't rank higher than #428 on http://www.ssa.gov/oact/babynames/), and can be easily discovered by visiting the website linked in my profile.

The messages were addressed to an older email account that I no longer use, but that's still set up to forward to my current address.  This older email address does show up in various google searches alongside my name, but neither of these other two names as far as I can tell.

Given the above, how concerned should I be that my account has been breached -- as opposed to an account belonging to some third party who knows both me and these two family members, and still has my old address in their contact list?

Edit 2: I've had 2-factor authentication enabled on my main email (gmail) for some time before this spam began arriving, with no known loss of control of my phone, backup codes, etc.  I will also enable it for Facebook now that that's become available.

I have noticed SPAM which meets this description, and which I infer is the result of address book compromises of people who have me in their contacts.  For half a dozen of my acquaintances, I began receiving SPAM with the following characteristics:

My friend's name ("JOHN WAYNE") in the From: field, but with a different actual email address, often at yahoo.com ("rikhanis@yahoo.com")
Subject is my first name, or some simple variation ("GREG", "FOR GREG")
From, To, and Subject often all caps
One-line SPAM with links:

greg, hey. look what I found! http://www.BAD.kr/bbs/data/bearangerchristophergordon/

GREG, HI. YOU NEED TO VISIT THIS http://www.BAD.com/babyelementmarkphillips/

hey greg http://BAD.net/diagramcyclingtimothymurphy/

None of the friends who were named in these messages could find anything with antivirus... but none of them were technically competent, either.  However, given the ongoing repetition of SPAM with their names but different email addresses, I'm concluding their address book got compromised and the spambots are using that to tailor the SPAM.


allowing users to add custom html/js code and show it only under another domain I have a web app where I allow users to create a one-page portfolio using drag and drop, also I allow them to add custom HTML freely (basically any html or js code)
I'm aware that I shouldn't allow the custom HTML to be executed while they are in the EDIT mode, so I save it in the database but never render it into the editor page.
However, I need that custom HTML/JS to be rendered in their built portfolio page, to prevent security issues here is what I did:

In addition to the private IP related to my app, I added another private IP
I purchased another domain, let say for example my app domain is portfolio-app.com, I purchased another domain portfolio-show.com and pointed that domain to my app (using the second private IP), means: I have 2 domains pointing the same app but each domain has its own private IP.
In my app I have a route in place that detects if the request is coming from portfolio-show.com host, if so, then it lookups the path and show the specific user portfolio,

The routing logic basically goes like this:
if request.host == 'portfolio-show.com'
   get ':any-id', to: 'portfolioController#showAction'
end

The showAction is rendered only on portfolio-show.com but never under portfolio-app.com,
so if you are a user 1 your portfolio will be visited under portfolio-show.com/user-1-portfolio
My concern is: is showing the custom HTML/JS under a different domain enough to protect my app? am I safe if some user put malicious code on their portfolio page?

Based on this description you have a "secure" and "insecure" domain. Both domains have the same possibilities, use the same layout etc. The only difference is that the insecure domain also allows insecure things in addition to all the other things.
In this case an attacker could likely motivate the user to actually use the insecure domain instead of the secure one. It looks the same and behaves the same so it seems to work. Only now attacks like XSS can be mounted successfully since insecure things are allowed on this domain.
To prevent this you not only need to allow insecure things only on the insecure domain but also prevent any confusion between these domains, best by not allowing sensitive things on the insecure domain at all (i.e. no login, no user sessions etc - or at least no shared user base).


Touch tone phone username and password I just got off the phone with Fidelity, who manage the health benefits for the company where I work. Before talking to a person, I was prompted to enter my username and password on the numeric keypad: 2 for abc, 3 for def, ... (Their passwords are limited to letters and numbers)

It occurred to me that doing this severely lowers the set of possible passwords an attacker would have to run through. For example, an eight character password has only about 4^8 = 65536 possibilities once the sequence of keys is known. (Some keys map to 4 letters plus the numeral itself, so it's a bit more than that).

How easy would it be for an attacker to listen to the key sequence and then brute force the password from the sequence of touch-tone digits? My guess is that phone lines are not as secure as HTTPS.

Yes, it's possible - but not necessarily easy - for someone to listen in to your DTMF tones.

Land Line

This is the easiest to tap.  In increasing order of difficulty...

Anyone in your house can pick up an extension and listen to what numbers you press.
Anyone with access to your house can install a digital recorder into a phone socket and then listen for the DTMF tones.
Anyone with access to your property could attach a device to your phone line to listen in on everything you say.  Phone calls are not encrypted :-)
Anyone with detailed knowledge of your phone company could open your local cabinet and tap the connection there.

In short, typing in your password, credit card number, or any sensitive data, via a POTS landline is not a good idea.

Mobile Phone

Ok, let's assume that you've got a cellphone / mobile phone.  It's a lot harder to tap - but not impossible.

Anyone nearby will be able to physically hear the tones you type in.  Your phone's speaker will play the DTMF as you press the button.  A digital recorder, a microphone pointed in your direction, and some software to pick out the tones is all that's needed.
The connection between you and your base-station is usually encrypted.  However, there are known weaknesses in the encryption algorithms.  A determined attacker could, theoretically, decrypt your communications either in real-time or after the event.
It is possible (although difficult) for an attacker to force your phone onto a fake basestation.  At this point, the attacker can hear everything which you type in.

Are You A Target?

All of this really does depend on how high a value target you and your account are.  I doubt that your health benefits are of particular interest to criminals.

That said, if your bank account contains billions of dollars, and you use the same password for banking as for benefits - some of these scenarios are more likely than others!


What aspects of hardware configuration are significant from a security perspective? What is worth keeping in mind (security-wise) when choosing a set of hardware?

For example, might a cheap (or obscure) setup like a Raspberry Pi make for a less secure server than a more standard machine? Or does the security of a server depend entirely on the software it's running? (Please ignore physical security aspects like cases, locks etc.)

One thing I'm worried about, is that operating systems (in general) might be less thoroughly tested on obscure hardware. Is that a valid concern? (Sorry if that's too general; I'm not sure if I'm on the right track here.)

I don't think the hardware should make a tangible difference in terms of security if you're comparing Raspberry Pi with a standard 32/64bit platform (i386, amd64 etc). Unless you consider physical security (which you don't), or perhaps from availability perspective, which is also an important part of security, but I'm guessing this is not what you're after.

From what I see about the Raspberry Pi, it's simply an ARM platform, typically used in many devices like smart-phones, routers, voip gateways etc. ARM is a very widely deployed platform, so in that respect it's still a good choice. It's definitely not obscure.

Whilst there might be some marginal differences in terms of what security features the platform can offer. For example whether or not it uses the NX bit, I would say that your primary concern is not the hardware but rather the software that you're running, and the way you expose your server to the outside world. Software itself might be vulnerable on either platforms and this is more likely to be your "weakest link". This includes the software you choose (OS, web stack, services, listeners etc) or your own application if you develop it.


why my Metasploit folder does not have wordlists folder (usr/share/)? I am trying to use msf word-lists but I just noticed in usr/share/metasploit-framework there are only two folders lib and config.

I am not sure how that happened but my msf is updated.

Is there any way to fix this and replace what is missing or get this back to the original state?

Thanks in advance.

on kali, the standard path for wordlists is /usr/share/wordlists - you should find several subfolders there containing wordlists.


What do the UDP entries in my netstat output stand for? I ran netstat -a under windows.

what is the meaning of this line  UDP    [::]:57427             *:* ?

Proto  Local Address          Foreign Address        State
UDP    [::]:5355              *:*
UDP    [::]:57427             *:*
UDP    [::1]:5353             *:*

I wonder if one of those is a backdoor to my machine?

Break down:

Your computer is listening on UDP ports 5355, 57427, 5353 and accepting communications from any foreign address.

5355 and 5353 might be DNScache
57427 might be FDResPub, which is a Windows OS DLL, that advertises the computer and its resources to the network.

Running:

netstat -a -p UDP -b

can be helpful in determining what is attached to those ports.

[::] and [::1]

If you run

netstat -a -p UDP

you will see that the [::] lines are equivalent to "0.0.0.0", which means that these ports are bound to any local IP address. [::1] lines are equivalent to 127.0.0.1, which is the local host.


Is encrypting data with a private key dangerous? I have been reviewing code for various internal apps that handle secure transmission of data with external systems. These follow the following process:

RSA encrypt data with 3rd party public key
RSA encrypt again using our own private key
Transmit data
3rd party decrypts using our public key
3rd party decrypts again using their own private key

In this system we generate new private/public keys for each third party and all public keys are distributed securely and then kept private.

I don't understand why we would encrypt data using our own private key. I suspect the designer's intent was to enable verification that the data originates from us and that same person had no knowledge of signing messages to implement that instead. Unfortunately, that person is no longer around to be asked.

I am happy that our data is acceptably safe because we encrypt that with the third party key, but private key encryption seems sufficiently non-standard that I feel some discomfort.
Is there anything that I should be concerned about?

It seems that the code you are looking at is taking a bit too literally the first description of how RSA signatures work.

When RSA was first described, it was an asymmetric encryption system: sender encrypts data with the recipient's public key, and the core operation is a modular exponentiation which takes as input a number modulo n (n is the modulus, a part of the public key) and returns a number modulo n. Then somebody said: hey, if we reverse the process and decrypt some input data (with a private key, necessarily), then we get a signature since anybody can perform the reverse operation (encrypt with the public key), which counts as signature verification.

This is an over-simplistic description of RSA signatures, and it does not actually work, because it neglects the effect of padding, which is necessary for security (see PKCS#1 for the Right Way to do RSA encryption and signatures). But the idea that signatures are encryption-in-reverse (or "encrypt with the private key") is unfortunately widespread, and lead to scores of homemade solutions which are all, invariably, weak in some way (but not necessarily in an obvious way). Chances are that you observe such a homemade solution.


SSL root certificate optional? I may have been under the wrong impression on how servers should be setup and what certificates actually get sent over during the server hello certificate message. I came across this today from Symantec/VeriSign:

Root installed on the server. For best practices, remove the self-signed root from the server. The certificate bundle should only include the certificate's public key, and the public key of any intermediate certificate authorities. Browsers will only trust certificates that resolve to roots that are already in their trust store, they will ignore a root certificate sent in the certificate bundle (otherwise, anyone could send any root).

If this is true, and root cert does not need to be installed on the server, well, there goes what I thought I knew about proper server setup and how the chain gets validated back to the root. Then again, when I look back at this question, under Certificates and Authentication section of Thomas Pornin's answer it says:

So the client is supposed to do the following:

Get a certificate chain ending with the server's certificate. The Certificate message from the server is supposed to contain, precisely, such a chain.

This says pretty much the opposite of the Symantec/VeriSign message above, unless I am misunderstanding something. So:

Does a server need the complete chain installed, including the root? If not, what does a browser use to compare against for validation since the server won't be supplying its root cert during the handshake? Does it simply look at the identity cert and get it from there? (Like opening up an identity cert on your local machine, and seeing the full chain in the certification path?)

Again if this is true what about stand-alone client apps that use SSL libraries? Will this depend on the application since it may have different path building methods to a trusted root vs a browser?

The server always sends a chain. As per the TLS standard, the chain may or may not include the root certificate itself; the client does not need that root since it already has it. And, indeed, if the client does not already have the root, then receiving it from the server would not help since a root can be trusted only by virtue of being already there.

What Symantec says is that they recommend not sending the root, only the rest of the chain. This makes sense: since the root is useless for validation purposes, you may as well avoid sending it and save the 1 kB or so of data bandwith per connection.

Anyway:

The server's certificate, with its chain, is not for the server. The server has no use for its own certificate. Certificates are always for other people (here, the client). What is used by the server is its private key (that corresponds to the public key in its certificate). In particular, the server does not need to trust its own certificate or any CA which issued it.
In TLS, the server is supposed to send a chain; and the client is supposed to somehow use the server's public key for the handshake. The client is free to "know" that public key in any way that it wishes to, although of course it is expected that the client will obtain the server's public key from the certificate chain that the server just sent. Browsers will primarily try to use the chain sent by the server (by trying to link it below one of the roots already trusted by the browser); in case of failure, they will try to build other chains based on intermediate CA certificates that they already know or can download on-the-fly.

In stand-alone applications, application writers are free to configure or bypass that step in arbitrary ways, which can be useful if the server's public key can be hardcoded in the application code (in which case the chain sent by the server is just completely ignored). Unfortunately, freedom to implement a custom certificate validation step is also freedom to wallop security, stab it to death and then throw its corpse in a ditch. It happens way too often.


Can a ransomware "destroy" git remote repositories? Instead of a backup, i store my important documents (my resumee, certificates and such) in a git repository - which is then pushed to sth like github.

My reasons for using git instead of an backup are:

My important documents are anyways inside git repositories, so pushing the content regularly to an external server(or github.com) is not difficult at all.
I don't know much of how to make proper backups (so that they are protected from ransomware).

Its obvious that ransomware can destroy my local repository, but can they also destroy the remote one? I mean, the connection is done with ssh keys, so a ransomsoftware can obviously read the key and push sth to github. But then I could maybe just revert the commit, right?

So the essence of my questions is: can a ransomware destory the content of the .git folder on the remote repository? (so, that i can't revert any change)

(NOTE: I do not mean using some exploits or anything like that, because of course it the answer to my question would be then "yes" )

Yes. A Ransonware can "destroy" your files locally. As for the server, this depends on the configuration. It would be interesting to use a password in the key to auth with git. Ransonware can read your files, but it will not be possible to send remotely.

Recommendation: Use the ssh key with password and do not use automatic authentication.


Do SSL / X.509 certs cover all ports for a host? Or are certs both host- and port-specific (excepting wildcard certs)?

I would assume they aren't, because they're supposed to verify a domain, but at the same time I've never seen anyone run HTTPS on any port other than 443, and I've only seen X.509 certs used in conjunction with HTTPS, so despite the fact that the answer is probably "no", I wanted to check.

Theoretically you can put anything you want in a certificate; for instance, this certificate actually contains a video file as "Subject Alt Name" (surprisingly, Windows has no trouble decoding a 1.2 MB certificate -- but it does not show the video, alas). However, in practice, certificates "for SSL" just contain the intended server name, as specified in RFC 2818. The client (Web browser) will verify that the name from the URL indeed appears where it should in the certificate. There is no standard for storing a port number in the certificate, and no client will verify the presence of that port number anyway, so, in short words: certificates are not port-specific. The notion of "identity" that certificates manipulate and embody does not include the notion of "port".


Why is a one-way hash not enough to secure a password alone? Why is it that people use other algorithms, such as bcrypt for securing passwords, and not just a few thousand iterations of an SHA-2 family algorithm?

Note: lets say for examples sake a few thousand is 10,000.

The point of using bcrypt over regular hashing is that throttling (key stretching) can be easily and reliably implemented which makes brute-forcing a time consuming, thus impossible job. Hash functions even with thousands of iterations are still relatively easy and no time job for the processor. Bcrypt is designed to be brute-force resistant as cryptography or computing develop. If password cracking becomes easier, you just increase the cost parameter.


Is this JavaScript mailto redirect vulnerable to XSS? I am working on a XSS attack and I do not think it's vulnerable after numerous hours of trying. However, a second opinion would be great.

<script language='javascript'>
  var redirecturl = 'mailto:xsss@m0chan.com?mkt_tok=mailtokenhere%3D%3D';
  function redirect() {
    var anchor = window.location.hash;
    window.self.location = redirecturl + anchor;
  }
</script>

My initial attraction to this was the fact that it's passing the value of anchor into window.self.location = redirecturl + anchor;. However I think that using mailto here makes XSS impossible.

This is more injection than XSS, but Mailto links have a few features that you can abuse. For example, instead of the email program popping up with just the TO filled out, you can pre-fill the CC, BCC, Subject, and Body. This is done by editing the query string, e.g. ?subject=xyz&cc=other@example.com.

My first thought was that window.location.hash would prevent adding anything to the query string, due to the #. However, I tested it on Chrome, and it seems to be possible.

So using this, somebody malicious could add sneak a few things into the email and hope that it goes unnoticed. For example, the malicious actor could send a blind carbon copy to an account they control:

https://example.com/contact#&bcc=evilminion@example.com

mailto:xss@example.com?mkt_tok=mailtokenhere%3D%3D#&bcc=evilminion@example.com

Or they could insert advertisements:

https://example.com/contact#&body=%0A%0A%0A%0A%0A%0A%0A%0A%0A%0A%0ABuy%20your%20foobar%20cheap%20at%20example.com%2Ffoobar

mailto:xss@example.com?mkt_tok=mailtokenhere%3D%3D#&body=%0A%0A%0A%0A%0A%0A%0A%0A%0A%0A%0ABuy%20your%20foobar%20cheap%20at%20example.com%2Ffoobar

This will still depend on the email client to include these other headers. RFC6068 discourages clients from adding anything beyond "a limited set" of headers that are deemed to be safe, such as subject, keywords, and body.


What compliance framework is appropriate for firewalls As a more corpose vulnerability assessment and penetration test, one step of our activity is to review from a security perspective the policy of some firewall.

In our society we have a deep understanding of firewall rule and best practice but we don't have any standard reference for commercial purpose and we don't know guidelines to explain security concern about misconfiguration and best practice to the client and to add more value to our know-how.

In out little research about it we found from the NIST this guidelines:

Guidelines on Firewalls and Firewall Policy
 Recommendations of the National Institute of Standards and Technology
 Special Publication 800-41 Revision 1

Is there other reference about firewall policy and firewall configuration? Any suggestion?

The target client is a public Library, in Italy.
I don't think there is some specific rule about firewall as we have, for example, for privacy stuff.

DISA STIGs are always good:

http://iase.disa.mil/stigs/net_perimeter/network_infra/firewall.html


Is it possible for a phishing link to install a major virus on a Mac? My girlfriend recently had her university MS Exchange account hacked. The attacker took over her email account and started using it to send thousands of spam emails. After a while, her email account must've hit some kind of limit, and the university server started sending her an email for every email that the spammer attempted to send from her account!

Anyway, she remembers accidentally clicking a phishing link in an email in webmail on her MacBook Pro that claimed to be an email from the university's IT Services, but that's all. Apparently, the link "did nothing" and closed immediately. She did NOT fill in any form that asked for her email address or password.

Despite changing her password, the attackers did not stop. How is this possible? Her Exchange account is linked to the university's central account system, but I'm not sure how exactly. Anyway, changing one password changes the whole thing.

Now IT services is telling her to reinstall everything (Mac OS X, files etc) on her laptop before they agree to re-activate her university account. This seems wrong to me - how could the laptop be infected, if all she did was click a link in an email via webmail? Is that even possible? (I expect she was probably using Firefox). They are worried that she has a rootkit virus.

Update: I forgot to mention, she also had Sophos installed. Not sure exactly how up to date it was.

Answer:
Yeah.  It's possible.  Re-install OSX and then change all her passwords. She got phished.

IT Services is correct here.

Prevention:
To prevent this from happening in the future make sure she understands the importance of updates, and how to spot and avoid phishing scams.

How it Happened:
A lot of attackers will use shortened URLs or legitimate websites with XSS vulnerabilities in them.  Even though your University scans the links and e-mails for viruses, if the attacker is using a legitimate site to attack then the university will let it happen.

Next, the link she clicked probably took her to a page that attempted a browser exploit, an attack on adobe flash, or against whatever your girlfriend hadn't updated recently.  Less likely, but still possible, is that they may have used a zero-day exploit - one for which there currently is no patch available.  After this point, the attackers could do whatever they wanted to her laptop including installing malicious software.

Side Note:  You ask in the title "something..something...virus on a mac". Contrary to popular belief, the idea that a Mac is more or less secure than a 'PC' is a fallacy. If a Mac or a PC is running a vulnerable service they are both possible to exploit.


Can I scratch off the magnetic strip off a debit card to only allow chip and PIN? I have been robbed in the past by thieves using my HSBC Debit Card (issued by UAE branch) to purchase mobile phones and accessories by signing for the purchases. While the card has chip & PIN protection, HSBC mention (in the fine print) that, because not all merchants have chip & PIN, they also allow the PIN to be bypassed and sign for the purchase.

My question is...if they were able to sign for the purchase, was that using the magnetic strip? And if so, can I scratch the magnetic strip, so it can't be read and essentially have a chip & PIN-ONLY debit card?

I was told that HSBC will not refund the money as I did not protect my card (even though I always protected my PIN) and will not issue a chip & PIN-ONLY Debit Card. All UAE banks provide only a chip & PIN card with a signature option. Same goes for the "new and improved" chip and PIN credit cards.

Can I scratch off the magnetic strip to protect my money?

As Phil stated, you can still use the card using its number (as you would do on-line).
Also, some ATM machine won't accept the card if not able to read the magnetic strip.

The best thing is to use a credit card: in that case you can block the payment and get a refund.


Prevent keyloggers on Linux? Are there any mechanisms in the Linux desktop architecture to prevent malicious software keyloggers? What would be an ideal Linux setup to make it very difficult for an attacker to install a keylogger on the target system?

Does is matter if you use X vs Wayland vs Mir? How can grsecurity or SELinux or any other patch help to improve the situation?

A key logger can be installed at different levels in the system with different detection ways. You already have other answers that explain that it could be installed in a dedicated process and how to detect its activity.

But it could also be installed by changing the part of the X11 server that processes keyboard inputs. If it is presented as an add-on offering additional capabilities like simpler input on non ascii characters, automatic xxx (put you most expected feature here) it can even be willingly installed by the end user on its own machine. Else, it could be installed (if attacker managed to become root) at boot time through a dedicated init module.

It could also be installed as a kernel module and directly monitor physical keyboard activity. The installation procedures could be identical as previous case.

The only way to secure a system if to always follow all security rules:

protect it with a strict firewall (easy)
never use root to do simple tasks (those two first rules are the principle of least priviledge)
never run any uncontrolled piece of software on it

And the latter is the harder to follow. Of course I assume that you only dowload system software and updates from official sources and do control checksums. But this game or add-on or utility looks so cute... And as soon as someone has made you execute code that he wanted while you would not have, it is no longer your system.

TL/DR: as usual, security cannot be reduced to technological tools but highly depends of human practices...


How does DHCP starvation work? How to prevent it? Is it the same as DHCP exhaustion? Can LANs be vulnerable to such attacks or it's against WiFi only?

Well Wifi or 802.11 is a protocol used at layers 1 and 2. DHCP works on layer 7 and uses a broadcast message to the whole network to which any DHCP server will/may reply to. So it's not only related to wifi it's, as Rory mentioned, applicable to any network using DHCP.

It's indeed the same as DHCP exhaustion. You as an attacker, will be sending tons of DHCP requests with spoofed MAC addresses to the DHCP server as to deplete the pool available IP addresses.


Session Fixation: A token and an id I am testing a web app and it works like this:

user opens the page and is assigned a sessionId.
user logs in, sessionId stays the same but user is also given an authToken.
user logs out, authToken is deleted, sessionId changes.
user logs back in, session Id is the same and a new autToken is given.

Is this app vulnerable to session fixation? I am confused because of the extra token that is given when the user logs in.

No, you are not vulnerable to session fixation, because of this authToken that you give to your clients when they log in.

You would be if

...the attacker has fixed a session he knows on the victim's computer, then the victim logged in with this session and made it authentic, now the attacker can use only this session to get access. But you are giving your clients new secret when they log in - the authToken.

without something new you give to your clients when they sign in, you would be vulnerable.

  I am confused because of the extra token that is given when the user logs in.

In your model the authToken plays the role of the sessionID that you generate and give to your clients when they log in.


How to Manage Public Key with Asymmetric Cryptography I'm working on an iOS chat project using Firebase RealTime Database.

I want to use asymmetric cryptography for the management of messages between two users ..

Browsing the net I found an excellent library Themis and for security reasons, in the documentation, advised not to save the public keys in the database but instead recommended to save public keys using a mediation service such as keybase.io.

This is very difficult for me to understand ... has anyone had experience with keybase.io or with other services?

can you suggest me some understandable ways to save the public keys with PKI avoiding the database?

The recommendation is based on the fact that it's harder to stealthy compromise a public mediation service than a single service. If they compromise keybase, with a lot of users, someone will very soon detect something wrong and warn the administrators.

On the other hand, if someone hacks your service and changes public keys, it can take a while until someone sees it. It's easier to compromise data when there are few clients, and your service will surely have way less clients than keybase.


Can I add my own VPN to a hosted website? I have a website hosted by a regular web hosting company.  Can I add VPN software to it?  I've read a little about hosting your own VPN but it seems to involve setting it up on your home computer.  Is that the only way to host your own VPN?

... regular web hosting company. Can I add VPN software to it?

This depends on what your "regular web hosting company" (whatever this exactly is) offers. If it offers only a way to put some web pages on the internet then you cannot add some VPN software. If instead you have a dedicated server or VPS you can usually do it.

  ... it seems to involve setting it up on your home computer. Is that the only way to host your own VPN?

You set the VPN endpoint where you want the VPN endpoint to be. This might be at home in case you want to protect you are outside and want to use some Hotspot in a secure way. But this can also be somewhere on the internet (i.e. dedicated server, VPS...) in case you don't even trust your local ISP. Note that a VPN only protects the connections between your local system running the VPN software and the VPN endpoint and offers no protection after it left the VPN endpoint.


Penetration Testing authorization from AWS We have a few web applications newly hosted on AWS. Before we run an automated pentest on the our Application URL using Netsparker, we had always e-mailed Amazon and requested authorization for the penetration testing. However, a question has popped up within our team whether the pentest authorization request is actually required or not when running a penetration test against an Application hosted in AWS? Some of them has the opinion that we need the authorization only when pentesting AWS services (like EC2, RDS, Aurora..etc) and not when we are pentesting an application hosted in AWS . This page that says that the authorization is required "for penetration testing to or originating from any AWS resources" is not very clear about this distinction.

From my experience as someone who has run automated pentest scans against web applications hosted in AWS - couple of times when I ran the scan without authorization, Netsparker stopped the scan (with a connection terminated message) after 10 to 15 minutes of scanning, but couple of times the scans did went through to completion after a few hours of scanning.

So the question is:

Do we have to get the authorization from Amazon for scanning a web-application hosted on an EC2 instance or we have to get the authorization from Amazon ONLY when scanning the EC2 instance itself on an infrastructure level?

We have already e-mailed Amazon for an answer, but they seem to be taking a long time to reply. Just hoping if someone here would have an answer before Amazon gets back.

Yes, you need authorisation for a penetration test of any service running on the AWS infrastructure, whether or not it’s a service directly managed by Amazon themselves. Source: personal experience and discussion with my AWS account manager. Remember, your pen test will be testing things like AWS security groups and network ACLs as well as your own service.


Advice needed regarding "Information Security Policy" - EI3PA requirements Our new startup is required to jump through hoops in order to get authorization to use Experian. We are working out of WeWork (shared space). No experian data is stored on our local machines.

We do have a web application server and a database on AWS.

They are asking for our "Information Security Policy". What should be the scope of that? IS there any template we can use that'll satisfy them?

There are many templates that can help you design your own policies. The international standard is ISO 27002. There are numerous templates you can find via Google but it might be helpful to get a professional to help you out.

But as for what the minimum will be for Experian, you might have to ask them, or hire a QSA. It is not clear from your question if the requirement is a general corporate Information Security Policy, or one focussed on PCI/EI3PA requirements.

The short answer is: you might have to hire a consultant for a short time or work closely with Experian.


"Extended Protection" primer and implementation guide to prevent MITM Extended Protection (link) (link) is a feature in Windows 7 and Windows 2008 R2 that prevents certain MITM attacks.

Does anyone have a primer (or explanation in plain English) what this feature is, and if there are any other benefits besides MITM protection?

How do I audit, control and verify that my applications are using this technology?

Is there a way I can identify applications that are not using this technology, and report on them or administratively disable them?

Are there cases when Extended Protection is undesired, or otherwise incompatible?

Extended Protection is Microsoft’s implementation of Request For Comments (RFC) 5056, and it exists to verify the authenticity the transport layer in an Integrated Windows Authentication (IWA) exchange. Extended Protection does not provide any other documented features.

In an IWA exchange there are two channels created; an outer transport channel (TLS/SSL) and an inner authentication channel (Kerberos, Digest or NTLM).

Extended Protection checks that the outer channel that arrives at the server-side matches the outer channel opened on the client-side. The server verifies that the outer channel at the client-side matches based on information supplied by the client in the inner channel exchange. If the two channel ends do not match, the server rejects the client’s request.

The IWA authentication exchange is susceptible to a replay attack specifically “credential relaying” when Extended Protection is not used.

For Extended Protection to work

Apply updates mentioned in KB973811 http://support.microsoft.com/?kbid=973811 as required.
Set registry key for clients to enable opt-in functionality as specified here KB968389 (http://support.microsoft.com/kb/968389).
Configure IIS 7.5, 7.0, 6.0 as specified in KB973917 (http://support.microsoft.com/kb/973917 or http://www.iis.net/ConfigReference/system.webServer/security/authentication/windowsAuthentication or http://blogs.technet.com/b/srd/archive/2009/12/08/extended-protection-for- authentication.aspx).
Some changes to clients and server applications may be required as specified in here http://msdn.microsoft.com/en-us/library/dd639324.aspx if custom authentication mechanisms are used.

Controlling Extended Protection

Extended Protection operates in three modes Off (also referred to as Never), Accept (also referred to as WhenSupported) and Always. When set to Always Extended Protection is required for communications. When using this mode clients that do not support Extended Protection are rejected.

Client’s rejected by Extended Protection will log messages to a HttpListener trace If configured in applications for more information on how to do this see http://msdn.microsoft.com/en-us/library/ty48b824.aspx.

Support for Extended Protection

Not all situations support Extended Protection. If you are running end-to-end newer versions of Windows then Extended Protection is likely to be easy to deploy. If you are have a mixed environment with Kerberos or NTLM through non-Windows proxy servers or delegates your implementation may require more work.

Third-party browsers that are not based .NET or Internet Explorer (such as Chrome and Firefox, Safari) will generally not support Extended Protection even though they may support IWA. This may be an issue if you need to interoperate with systems outside your corporate network or your corporate network uses a mix of browsers.


What actual damage can a DDoS attack do? Aside from not being reachable for actual customers and therefore financial loss, what damage (money/hardware/software) can a DDoS attack do?

PS: I've read about streamers/youtubers/private gamers being DDoSed and can't see any advantages for attackers to spend money on botnets for DDoSing some twitch streamer...

Edit:As this question seems too broad, let's just focus on private websites/users being DDoSed(I'm aware that the loss of critical infrastructure like power networks can do major damage)

A DDoS impacts a service negatively for several reasons (I'm not exploring the legal, social and financial consequences here):

1. Service Disruption: The most obvious -- preventing legitimate end-users from accessing a service, or affect the quality of service

2. Increase Costs: You may cause the service provider to spend more on resources to meet with your traffic

3. Camouflage: Your real attack logs gets lost in a large crowd

4. Trigger Fallbacks: A WAF / IDS/ IPS may change from filter mode to log-only mode

5. Loss of data: By overwhelming the DB or filesystem, data that has not been backed up may be lost

6. Identify Technical Capabilities: Based on how the service automatically/manually responds to a simple DDoS attack and the scale of traffic it can tolerate, you can learn about the technical competence of the system and it's operators. It also scopes out good targets, which are likely to have poor defensive capabilities.


Recommended options for LUKS (cryptsetup) I'm looking for recommended options for cryptsetup to create fully encrypted SSD (SanDisk SSD U100 128GB), which achive:

Timing O_DIRECT disk reads: 1476 MB in  3.00 seconds = 491.81 MB/sec
Timing buffered disk reads: 1420 MB in  3.00 seconds = 473.01 MB/sec

My benchmark shows me best cipher:

# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       103696 iterations per second
PBKDF2-sha256      59904 iterations per second
PBKDF2-sha512      38235 iterations per second
PBKDF2-ripemd160   85111 iterations per second
PBKDF2-whirlpool   47216 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   133.2 MiB/s   432.0 MiB/s
 serpent-cbc   128b    18.1 MiB/s    67.3 MiB/s
 twofish-cbc   128b    39.3 MiB/s    73.0 MiB/s
     aes-cbc   256b    99.6 MiB/s   337.7 MiB/s
 serpent-cbc   256b    18.1 MiB/s    66.9 MiB/s
 twofish-cbc   256b    39.4 MiB/s    72.6 MiB/s
     aes-xts   256b   376.6 MiB/s   375.0 MiB/s
 serpent-xts   256b    69.0 MiB/s    66.5 MiB/s
 twofish-xts   256b    71.1 MiB/s    72.2 MiB/s
     aes-xts   512b   297.0 MiB/s   300.1 MiB/s
 serpent-xts   512b    69.6 MiB/s    66.6 MiB/s
 twofish-xts   512b    71.9 MiB/s    72.7 MiB/s

But perhaps, you could suggest some options, that would increase my performance and security. My CPU is: Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz and it supports AES-NI (aes cpu flag).

Thank you

You might want to use PBKDF2 with SHA-512. This step is for converting your password into an encryption key (more or less directly). This is inherently open to offline dictionary attacks, and relates to the password hashing problematic. For that, you want to maximize the effort of the attacker by choosing an algorithm and iteration count which will make the task hardest for the attacker while keeping it tolerable for you; "tolerable" here depends on your patience, when you type the password at boot time.

Attackers will want to use some GPU and/or FPGA to speed up their attack, while you use a normal PC. Nowadays, normal PC are at ease with 64-bit arithmetic operations, and run SHA-512 about as fast as SHA-256; however, GPU much prefer 32-bit operations, and mapping them on FPGA is also easier than 64-bit operations. Therefore, by using SHA-512 instead of SHA-256, you give less an advantage to the attacker. Hence my recommendation: on modern hardware, for password hashing, prefer SHA-512 over SHA-256.

Remember to adjust the "iteration count" so that the time taken to process your password is at the threshold of the bearable: higher iteration counts mean longer processing time, but are proportionally better for security.

For actual encryption, you will want XTS, which has been designed to support disk encryption efficiently. This indeed shows in the benchmarks; this is for a SSD and you do not want the encryption to be much slower than the underlying hardware. Note that XTS splits the key into two halves, only one of which being used for the actual encryption. In other words, "aes-xts" with a 256-bit key actually uses 128 bits for the AES part. And that's good enough. There is no rational need for going to 256-bit keys -- i.e. 512-bit in the context of "aes-xts". 256-bit keys for AES imply some CPU overhead, which the benchmarks duly observe (300 MB/s vs 375 MB/s). With a SSD under the hood, you really want a fast encryption system, so do that.


Indicators of Compromise Just to get an understanding of how indicators of compromise works. Take For example, in this article, the SMB tool. There is a MD5 hash for it. So is my firewalls or IDS supposed to be able to detect this MD5 hash string? How would my firewalls and IDS going to check against this MD5 hash? I am a bit lost on the concept of indicators of compromise.
thanks

This MD5 hash is just a cryptographic hash of a file, i.e. a unique identifier of the file's contents. You can compute a (more-or-less) unique MD5 hash of any file.

What does it have to do with security? You see, when you have a malicious file, you can compute its MD5 hash just like with any other file. Then, if you get this malicious file in your system and compute its hash, you will get exactly the same MD5 hash. What does this mean? It means that your security software can scan your entire file system, computing the MD5 hashes of every single potentially dangerous file and comparing them to the hash of the malicious file. If it finds a match, that means trouble!

In your example, there is a list of MD5 hashes of dangerous files. If the MD5 hash of any file on your computer matches one of these, you're probably screwed.

This is quite a basic malware-detection technique, and it is easily negated by encrypting malware. However, it was the best weapon in the arsenal of most of the earliest antiviruses.


password managers and FIDO I've just been reading some posts about FIDO support (or the lack thereof) in password managers and want to check whether my understanding is correct.

My understanding of FIDO (v1) is that the device contains a secret that it will never let out of the device, and all it has to support is digital signatures based on keypairs derived from this secret. Roughly, when you log in to example.com, the device computes a site-specific keypair based on some KDF(secret, "example.com") and then signs the server's challenge with that.

In other words, a FIDO token does not have to function as a source of secret keying material, which means that it makes no sense to use it with an offline / standalone password manager. After all, you want the password database to be encrypted with a key that's not stored in or next to the database itself, which is why you set a master password from which you derive the key. A FIDO device lets you prove possession of a key, but as it's (for practical purposes) "zero knowledge" that's no use for unlocking an encrypted database.

(In contrast, yubikeys that offer other modes as well as FIDO do make sense together with password managers precisely because they can hold your key and export it when you need to open the password manager.)

So for example pwsafe+yubikey exists, but pwsafe+generic FIDO isn't likely to happen soon. (I haven't checked the FIDO2 standard in detail yet, maybe that has a mode for this.)

But then you read things like keeper password manager enables FIDO support. How is this supposed to work - is the secret stored in some form on their servers, which is only released to you when you successfully authenticate with FIDO?

Sorry to burst your bubble, but here's actually only one mode of Yubikey that REALLY makes sense for PW managers in a complete sense and that is the Smartcard mode, but there is basically no passowrd manager that actually uses it.

Online Password Managers often go with Yubi-OTP due to it's sheer compatibility only requiring a USB slot and basic keyboard drivers (and a keyboard layout that doesnt screw modhex), but some are also going to U2F simply because

It's more secure to there not being any shared secrets (Yubi-OTP uses shared secrets with Yubico when used in their cloud setup or with the provider in a custom setup)
you cannot identify the specific key used. you know, the first 12 or so characters of a Yubi-OTP are the serial number in modhex (factory default) or something the user chose when customizing it).

this allows the backend to look up the correct keys to decrypt the actual OTP data, for U2F on the other hand, while you generally are not wrong about the KDF(domain,secret) thing for generating the key, there's a LITTLE bit more to consider.

There actually is a third value used in there. a random nonce generated at registration which is part of the "key handle" which is needed for authentication and is why even if you use single factor U2F you still need a way to know who you are authenticating (like a user name) to provide the key handles along with the challenge.

Offline Password managers often go with the HMAC road which is literally just HMAC(data, secret), depending on the details of your password manager they do it in one of 2 ways:

just use the result from HMAC(some static value,secret) as part of the decryption key, which does work but is obviously bad since one capture leads to its compromise.
what Keechallenge is doing: they store the secret and use that to pre-generate the next result to use in the decryption process while storing the challenge for that result in the open to obviously issue that challenge during the next open.

both methods are not ideal since seeing just one decryption breaks this for the complete lifetime of the database except maybe if a rotation (of the challenge for 1, of the secret for 2) is done every now and then.

considering how yubikeys work on PW-DBs we can basically see how U2F can work in pw databases.

online obviously as data valve, "you ain't getting the db unless you bring the U2F"
offline as snakeoil
offline in a similar manner to yubikey HMAC, we keep the keyhandle open to issue it and actually use the public key not as an actual public key but just as content to generate our symmetric encryption key.

if this sounds crazy to you, let me assure you, it is crazy but it's not much different than using HMAC mode for encryption.

the only REAL way to encrypt stuff is Smartcard and/or PGP mode with rotating symmetric keys on each save, so the private key is actually needed to decrypt the database and that private key being ONLY in the yubikey.


What is collusion and how does seperation of duties prevent it, or fail to prevent it? I'm studying for CISSP and came across the term "collusion". I understand it means when people work together to steal something, but don't quite get it. For example, if two gunmen rob a bank would that be collusion, or is it implied that two people inside a company work to defraud it, or one person on the inside helps someone on the outside, or what?

I had a practice question that said "true or false, does division of duties prevent collusion?" the answer given was "false, it doesn't always, and by definition collusion is working together". Could someone elaborate on the reasoning? Separation of duties could help, but nothing is 100% guaranteed so it was a bit tricky for a true or false question...

By the way, I'm tagging this as physical, but have no idea of it only pertains to physical assets.

Collusion is where the bank guard opens the doors after closing, and the safecracker cracks the vault. Both people have a specific job to do that the other cannot, and without that job, the event cannot take place.

That's a different scenario from 2 people walking in with guns.

Separation of duties means that for someone to steal something, it requires collusion. If everyone has the keys to the bank doors and the combination to the vault, then collusion isn't necessary.


Checking domains HSTS status The Google Chrome browser offers a quick way to check a domain's HSTS (HTTP Strict Transport Security) status via the page chrome://net-internals/#hsts (section Query domain).

The query result looks e.g. like this:

Found:
domain: owasp.org
static_upgrade_mode: UNKNOWN
static_sts_include_subdomains:
static_pkp_include_subdomains:
static_sts_observed:
static_pkp_observed:
static_spki_hashes:
dynamic_upgrade_mode: STRICT
dynamic_sts_include_subdomains: false
dynamic_pkp_include_subdomains: false
dynamic_sts_observed: 1409173001.03746
dynamic_pkp_observed: 1409173001.03746
dynamic_spki_hashes:

What do these lines mean? Is the HSTS mode enabled or not? What is the difference between the dynamic_ and static_ entries of the result?

If either of the static_upgrade_mode: or the dynamic_upgrade_mode: lines are set to STRICT then HSTS is enabled.
Dynamic
Dynamic means that the browser has been instructed to enable HSTS by an HTTP response header (served over TLS) similar to the following:
Strict-Transport-Security: max-age=157680000; includeSubDomains;
This is vulnerable to an attack whereby the very first time the browser requests the domain with http:// (not https://) an adversary intercepts the communication.
Static
In order to overcome this weakness we have the static mode which allows for hard-coding HSTS records directly into the browser's source. The header is changed to indicate the administrator's intention:
Strict-Transport-Security: max-age=157680000; includeSubDomains; preload
Note the inclusion of preload at the end. The domain is then submitted for review. If approved then it is added to the Chromium list which is also included in the Firefox, Safari, and IE 11+Edge lists.


Safety in public wifi I stay at a dorm. I am wondering about the security of the log-in wifi system.
I want to know if my browsing history can be seen by the internet-admin that I'm connecting with.

If I install an OS on a virtual machine, will I be safe from the attacker (because I'm still connecting to the public wifi)?

Virtual machines make no difference here.

Assuming the owner/admin of the wifi access point is a average person, and not the NSA:

If the admin is reading the traffic passing his AP, but not doing anything else, HTTPS connections that are properly configured by the website owners are secure (sadly, as lay person, judging the configuration quality is not possible).
HTTP connections are fully readable by the admin.

If the admin starts to modify traffic passing the AP, as before HTTP connections are not protected from anything. This holds in both directions, ie. what you get from the webserver could be faked, and what the webserver gets from you too.
About HTTPS, pay attention to certificate warnings (instead of clicking the away, if the browser allows it). A warning is no proof for maicious activity, but nonetheless, don't proceed.

Thhird point, stop thinking that your wifi traffic is everything. Being connected to some network controlled by an attacker is very helpful to take over your computer completely...


Why should we use checkCallingPermission instead of checkCallingOrSelfPermission in Android? I scanned a project using Fortify and it says I should replace checkCallingOrSelfPermission method with checkCallingPermission.

I could not figure out the security risk that checkCallingOrSelfPermission method presents.

This is the Fortify explanation:

  The function checkCallingOrSelfPermission() or
  checkCallingOrSelfUriPermission() determine whether the calling
  program has the required permission to access a certain service or a
  given URI.  However, these functions should be used with care as they
  can grant access to malicious applications, lacking the appropriate
  permissions, by assuming your applications permissions.

  This means a malicious application, without appropriate permissions,
  can bypass its permission check by using your application's permission
  to get access to otherwise denied resources. This can result in what
  is known as the confused deputy attack.

The confused deputy is when you are operating on behalf of another program, but you do not appropriately check permissions.  The normal example of this is a grocery store cashier, scanning items using a barcode.  If a malicious customer changes the barcode, for instance putting a carrot barcode on filet mignon, and the cashier simply scans and charges carrot prices, he/she is being a confused deputy.  (On the other hand, if he/she notices, she's applying appropriate checking and is not a confused deputy, but a competent one)

In this case, what Fortify is saying is that you are being willing to substitute your own permissions for the caller's permissions (that's what checkCallingOrSelfPermissions does) - you are saying it doesn't matter what the caller can do, go with what you can do.

It is possible this is what you want - if your program is intended to perform privileged commands on behalf of unprivileged programs, this may be what you want. If that is that case, however, you are responsible for ensuring that the caller IS the real caller and that it isn't doing anything malicious.  Fortify can't help you there - that is where you'd do a real, intense code inspection and some serious testing to make sure that that trust-boundary cannot be exploited by anything malicious.  If your code passes, you'd normally then annotate so Fortify ignores it.  These are called trust-boundaries and they are where you want to spend a lot of analysis time to make sure that you are performing appropriate controls.

You probably want to just listen to Fortify here and make the change, unless you've done the work to verify your inputs and are positive that this call cannot be used to do something malicious AND it is the only way to do something useful.


Proving authenticity of data accessed over TLS by an untrusted third party Is there any way an untrusted third party who has access to content from a website over HTTPS can prove the authenticity of the data (i.e. that it was distributed by a server in possession of a specific TLS private key)? The way TLS works makes it such that a packet capture and copy of the master key is insufficient to prove authenticity, since the HMAC key is derived from the master key, which makes it possible to forge the message. Because the third party is untrusted, having them verify the TLS themselves then endorse the authenticity by digitally signing the material is not a solution either.

I'm pretty sure there is no solution under these constraints, but there may be something I missed.

I fully agree with your analysis that such a proof is impossible with common websites:

The private key of the server is only relevant inside the TLS handshake and can be used to prove that a specific TLS handshake was done with a specific endpoint with a specific key pair.
After the handshake the transferred data get encrypted and integrity protected. The keys used for this depend only on the master secret. The master secret is the same for client and server which means that the client can also derive the keys used by the server for encryption and integrity protection. Knowledge of these keys enables the client to decrypt and integrity check the data send from the server.
But since the used algorithms are symmetric they can also be used to encrypt and integrity protect new data. Since there is no additional server-side secret involved in payload protection (i.e. no signature based on the servers private key or similar) it is impossible to detect if data were encrypted by the server or by the client.
Since no additional authenticity proofs are provided by the underlying network layers (i.e. TCP, IP, ...) nor by default at the application layer (HTTP) one cannot conclude from client provided data that these data actually were generated by a specific server.

Note that there is for many years an ongoing but still active effort to provide such authenticity at the application layer (HTTP) - see Signing HTTP Messages. And there also seem to be implementations of this draft. So with luck a server will already provide such signatures in which case these can be used to proof, that the server (or somebody else in possession of the private key) has send a specific content.


Is data-remanence a concern in RAM? I know data-remanence is a concern on hard drives, but is it a concern on RAM?  For example, once a program completes, is its data still available on RAM, just as data on a hard drive remains after being deleted?

Edit: In this case, I am not as worried about data that could possibly remain after the computer is shut down.  I am moreover thinking about a situation where a hacker compromises a system that is still running, and is able to access the memory.  Does the data remain in RAM long after the program that was using it is terminated?

It can be.

Generally speaking, programs while running don't tend to wipe out their data (they do, after all, tend to need it), and any process with the ability to access other programs' allocated RAM can, in fact, read it. This is how, for example, the recent spate of big box store hacks were able to leak so much credit card data -- the attacks were carried about by rogue programs that scoured the running POS machine's RAM and copied anything that looked like card data. [I can't at the moment find a source to back this one up, I'll keep looking and edit it in later.]

Once a program terminates, the data that was in its RAM may remain around indefinitely if no other process gets allocated those same addresses and overwrites it with its own data. On modern operating systems this again requires the ability to read RAM not allocated to the process doing the reading1, and even then is unreliable at best, especially on modern systems that are constantly doing all kinds of things.

Both of these can be mitigated, if not outright prevented, by never allowing untrusted processes to run with root/administrator privileges: limited users simply do not have the ability, barring holes in the OS's security model, to access this RAM.

And, of course, there's our good friend the "cold boot attack", where encryption keys etc. are read from RAM after the machine has been powered down. This requires physical access to the machine, a boot disk (or specialized hardware), and quick timing (as data remains resident in RAM for only a short time after it's powered down).

As a quick footnote, the risks of data remanence on hard drives are rather overblown: Once data's been overwritten, it's gone. The "Gutmann 35-pass method", for example, is not only a fundamental misunderstanding of Dr. Gutmann's research, but wholly unnecessary -- a single pass with any data -- ones, zeros, random noise, kitty pictures -- is all that's really necessary. If it's not overwritten, however -- if it's merely deleted -- then it does hang around, though. Data remanence on RAM is similarly an often-overstated risk, though just like hard drives it can and does leak information if you're not careful.

1 The reason is that modern operating systems actually take the time to wipe out RAM before allocating it to a new process, specifically to avoid leaking potentially sensitive data to processes that start up and then read uninitialized data (which in the past is how such leaks were carried out).


Can PHP files be dangerous without executing them? Recently I had a job interview online as a developer and I had to download a .PHP file from an FTP. I used a VPN to connect to it and after downloading the file I just opened it in VS Code to see the code. Since I don't even have PHP installed on my computer to execute it, is there any chance that the file could be infected with something?

In theory, the file could contain some (non-PHP) code that targets a vulnerability in the IDE you used to open the file (VSCode). This would require an exploitable vulnerability in the IDE itself though, and will probably be extremely obvious to anyone not using this specific IDE. This will make it extremely unlikely the file is dangerous.
As far as the actual PHP code goes, it can't do anything as long as it's not run by a PHP interpreter.


Is there a layer 1, 2, 5 and 6 DDoS attack? I'm doing some research on DDoS attacks, and I seem to only be finding information on layer 3,4 and 7 attacks.  When I saw 3/4 and 7 DDoS attacks, I figured they were the most popular, but there were also layers 1,2,5 and 6 layers as well.

Are there more?

...when I saw 3/4 and 7 DDoS attacks, I figured they were the most popular, but there were also layers 1,2,5 and 6 layers as well.

The OSI model does not have much common with reality anymore, at least not with layers 5..7. Instead you will find layer 4 functionality packed into layer 7 (like with Websockets) or layer 5 (session) functionality within the application layer (HTTP cookies) etc. Therefore you might better refer to the TCP/IP model which merges OSI layer 5..7 into a single application layer and don't look for separate attacks at each of these layers.

DOS of OSI layer 1 (physical) is of course physical too: just somehow damage the cabling, like using a nuclear bomb (either by destroying the cables or by EMP). A distributed DOS would be much harder, because you would need to be of course physically present somehow.  At layers 1 and 2 you also have various DOS attacks against WLAN (just google and you'll find some paper), but distributed DOS would more mean attacks against the underlying control functionality. There might be some "packet of death" attacks which make certain network cards croak but you would need upper layers to get access to these cards first within a distributed attack.


Is it enough to have Intermediate CA certificate in Trust store to validate a server certificate? Lets assume that below is the chain:

Server cert -> Intermediate1 -> Intermediate2 ->Root cert

Below is the chain server sent to the client:

Server cert -> Intermediate1 -> Intermediate2

I have Intermediate1 certificate only(no other cert) in my truststore.

Given this scenario, Does client can verify the server certificate?

I'm pretty sure Client verifies successfully and initiates the SSL connection As the immediate Issuer is present in the trust store. Am i wrong?

Take a look at RFC 5280 Section 6.

  The selection of a trust anchor is a matter of policy: it could be
     the top CA in a hierarchical PKI, the CA that issued the verifier's
     own certificate(s), or any other CA in a network PKI.  The path validation procedure is the same regardless of the choice of trust
     anchor.  In addition, different applications may rely on different
     trust anchors, or may accept paths that begin with any of a set of
     trust anchors.

In other words, it depends on the implementation of the certification path validation at the client side. For some clients it works by having only a trusted intermediate CA certificate for others the full chain is required. Some client also cache the intermediate certificate once they have been verified in order to speed up the validation process.


What is the difference between Digital certification revocation and retiring? Certificate management tools use options called revocation and retiring digital certificates.Can someone explain what is the difference between both?

I would think this might have to do with what flag is used to mark the cert when it is added to the revocation list. A cert added with reason 4(superseded) or reason 5(cessationOfOperation) are not being revoked because of some compromise or inherent flaw so could be considered to be "retired".

There have been several types of certs(sha1 and MD5) that are signed with insecure hashes that are being phased out or "retired" as well.

https://en.wikipedia.org/wiki/Revocation_list


In inSSIDer, what is the difference between WPA2-CCMP and RSNA-CCMP? inSSIDer shows my wireless network as RSNA-CCMP.  The settings on the wireless router (Linksys E2000) do not at all seem to suggest an "RSNA" security option.  The security filtering options in inSSIDer have both a WPA2-CCMP and RSNA-CCMP available.

What is the difference between these?

The RSNA-CCMP filter is an accidental left-over from when I wrote the filtering system. It is exactly the same as the WPA2-CCMP filter. :D


'Remember Me' combined with Auth Token I've developed a client application which talks over a REST API to a server. The way the application works is to send the username/pwd pair in the initial login to the server and then respond with an auth token in the form of a newly generated GUID.

The client uses the GUID to talk to the server for the remainder of the session (forever until the local storage is cleared).  The login page requires the ability to stay logged in. To achieve this, I store the GUID token in local storage.  If the key is there then it auto-logs into the app.

All of the comms is carried out over SSL so I'm not worried about the security of the data or MITM, but I am concerned about the security of the token stored in local storage.

Some questions:

Should I encrypt the GUID further?  Does this give me anything?
Is storing the GUID auth token in local storage a big security risk?  Worth securing?
Does storing the token inside a cookie improve matters at all?

I also thought about having the server generate new tokens every new login and reduce the window of attack, but that would then prevent the 'remember me' feature from working.

When you say GUID is that an actual GUID as per spec, or a proper randomly generated key? If its not random that's the biggest issue right there because your session security now relies on something very easily guessed.

Given that, to answer the other questions you need ask yourself: what are you protecting? what are you protecting against? What sort of attackers? How much effort are you and/or they willing to put into it?

Then you have to consider that what you're looking at is protecting a key on a client system that is potentially hostile. You could encrypt the session key, but with what key? What algorithm? Do all browsers support the necessary algorithms? How do you protect that key? Most browsers don't support crypto so that complicates things a whole lot.

Storing things in local storage is better/worse/equal to storing in a cookie. On the one hand its better because it can help protect against CSRF because to get access to the session key you need to execute within a context that can access local storage, whereas a cookie will pretty well just be sent to the server on every request so long as the cookie is valid. However, local storage was never really meant for storing sensitive things like session keys so it doesn't necessarily get the same level protection as a cookie store on a machine (history being what it is, cookies had the same issue back in the day too). Cookies nowadays also have protection against access from JavaScript, so XSS can't do funny things with sessions like ship the keys off to another server, whereas local storage is only accessed from JavaScript.

A potential mitigation is to use both a cookie and local storage to create a composite key of sorts, but there could be complications with that too.

You could also refresh the token every so often and make sure its invalidated on the server to prevent long-lived keys, but that doesn't necessarily solve anything if a user only visits every few weeks.

Clear as mud?