How can Paypal know my card is being used in another account?

There are a couple reasons why Paypal (or more generally, any payment service) can know if you've used your card in more than one place.
Your credit card is absolutely tracked everywhere possible

Shouldn't my credit card be stored with a hash under my account only?

If your card is kept hashed then it can be easily compared across accounts.  Hashes are deterministic, so for a fixed hashing algorithm a given credit card will always give the same hash.  Therefore if they were storing hashes, they could easily compare across accounts and determine if the card was already stored elsewhere.  Doing so can be advantageous, as in this case it is being used to prevent fraud (the implication is that if the same card is added to multiple accounts, it is likely due to fraud).  Once you have a "secure" hash of a credit card, there's no reason not to check it across different accounts.  Paypal certainly can and does.
However, this ability isn't limited to Paypal, and can easily be available to much smaller merchants.  For instance with Stripe (a common PCI-compliant payment method) the merchant will be given a unique identifier for each credit card number stored on Stripe.  The merchant doesn't keep (or even see) the card number, but they can still compare the given hash against other card hashes that have been used in their systems.  This can (and is) easily used for the less-altruistic purpose of tracking a user's buying history across multiple accounts and anonymous transactions, while still maintaining PCI compliance.
So to be clear, your credit card is tracked absolutely everywhere by as many people as can keep their hands on it, even if they don't know your credit card number themselves.
Paypal keeps your actual credit card number on file - not just a hash
Smaller merchants can and should make sure and never store, transmit, or even look at actual card details.  However, there is no requirement that forbids any merchant from keeping the actual card number if they so desire.  In general though any merchant that wants to keep card numbers on file and remain PCI compliant will (theoretically) have to go through stricter validation, security auditing, and effectively have to pay a ton of money in fees.  The increased costs and liability of keeping credit card numbers on file while remaining PCI compliant are so large that any moderately well run small-medium business will never try.
However, large businesses can and do choose to do otherwise.  The reality is that someone has to store card numbers somewhere so that your card can be billed.  The larger credit card processors (which Paypal definitely is) certainly store the full card number.  They should store the numbers using strong encryption and secure keys/access control procedures.
As for the details of how they actually determine that a credit card number is used twice, ultimately only Paypal can answer that.  They may have a method for comparing encrypted card numbers directly, but more likely they also store a hash of the card numbers and compare those directly (h/t Jory Geerts).  Either way though, they do keep your card number on file, and they can compare card numbers against accounts.
Note that this doesn't mean that they are "Keeping all registered cards in one big file for cross-reference".  Their infrastructure for secure card storage is certainly far more complicated than that.  However, they obviously have a compelling business need to be able to compare cards across accounts, and have setup their infrastructure so that they can both store your cards securely and also check for duplicates across accounts.  I agree with the linked comment: I would guess that they are also calculating a secure hash of the credit card number and using that for easy comparisons.


Is SQL Injection Possible without double and single quotes?

Yes.

There are other ways to get data from a database, or just do something malicious. One way of doing this is to select all the records from the database, using either SELECT * FROM TABLE users or SELECT * FROM TABLE users WHERE True and then filtering through the returned data to find the user that the attacker wanted.

Further, statements like DROP TABLE users are not caught under the double quotes system, and have pretty nasty effects.


Does "/phpmyadmin/setup/index.php" present a security risk?

Well this is a huge security risk. Even though it is impossible to modify data if nobody can view your database structure though this security panel they can use zero day security flaws in phpmyadmin to get your information.

Generally speaking you should manage your database through an endpoint that is not accessible to every visitor of your website.

You should move this to a secure location. Some other subdomain that is protected by some filter or something like that.


Recourse if debit card was used on a suspicious website

Don't report this as fraud; that will kick off an investigation that will ultimately conclude you did authorize the transaction. Waste of time all around.

Call the card company, tell them you made a purchase on a site that is not at all PCI-compliant, is "likely fraudulent" and your card information is now assumed compromised.
Go through the hoops to get a new card issued with new numbers.
Wait 30-45 days to see if the glasses show up. Be pleasantly surprised if they do. If they don't, dispute the charge before the end of the dispute period (gen. 60 days).
Educate your husband to never buy anything marketed through ads. Even when the goods are delivered, they're seldom as good a deal as you think.

As for identity fraud, I'm not seeing birthdays or socials in the form, so it's unlikely they could actually do anything with it. They ask for enough information to authorize a transaction so I'd expect fraudulent charges on the card at worst if you don't shut it down immediately.


How do you create a password list for a forensics case based on the evidence

What you're looking for is Bulk Extractor. I haven't used it before, but have heard good things.


Difference between IPSEC SA and CHILD SA

Before I start, I need to explain how IKE and IPSec work together.  It's not like TLS (where there is one set of logical keys that protect everything); instead (using the language of the RFCs), you have 3 Security Associations within this one tunnel:

You have an IKE SA, that is used to protect negotiation traffic between Linux1 and Linux2 (such as negotiating traffic SAs).
You have an IPSec SA that is used to protect data traffic from Linux1 to Linux2
You have an IPSec SA that is used to protect data traffic from Linux2 to Linux1

Now, for your questions:

What is a CHILD SA?

A Child SA is any SA that was negotiated via the IKE SA.  An IKE SA can be used to negotiate either SAs to protect the traffic (IPSec SAs), or it can be used to create another IKE SA.  In the context you're seeing it, it's most likely a synonym for the IPSec SAs.

What is the difference between ikelifetime and ipseclifetime

No SA is eternal; they all have a best-by date; and when that expires, they go away (and hopefully replacement SAs are also negotiated, unless you're actually done with the tunnel).  ikelifetime would be the lifetime of the IKE SA; ipseclifetime would be the lifetime of the IPSec SAs.


Short answer:

Your best option is to simply start over.  If have a backup/restore point saved where you are absolutely certain there is no malware, you can try that, but many viruses these days will disable backup/restore.  In that case, reinstall your operating system (you may want to do that anyway just to be certain).  Once that's done, get a better antivirus such as Avast! (free) or ESET (if you're willing to spend money).

Long answer:

If you want to triage the malware, the first thing you should do is double check that you are not connected to anything.  It could be possible that the malware turned on your internet connection.  Run cmd and type in netstat -ano and see if you have any established connections to foreign hosts.

The next thing you should do is download Sysinternals and Wireshark if you don't already have them. Since you aren't connected to the internet, your best bet is to probably download them on to a thumb drive on a different computer and bring them over.  You will want to format that thumb drive before you plug it into another computer though when you are done.

Once you have that, run Wireshark and look for any network activity coming to or from your computer.  Since you aren't connected, you'll probably see nothing, but it's an easy step and will put a spotlight on what the virus is doing if it works.

For details on using Sysinternals for detecting malware, watch this video: https://www.youtube.com/watch?v=80vfTA9LrBM

The video basically says to use Procexp to identify any binares that are out of place, and use Autoruns to see if any of your Registry entries have been modified to start an executable that shouldn't be there.  Use Procmon to get a step-by-step list of what all of your processes are doing (such as in your case, starting RDP).

But at the end of all of this, you will still want to remove the virus (referring to my short answer).

I hope this helps, and good luck!


Oauth2 vs APIKey in a server to server communication

This is an interesting topic and there are a couple of things to consider. First we need to come at it from the API provider, not just the consumer.

Who?

The main consideration is Authentication vs. “Identity” and Permissions. Refresher:

Identity = Who say you are
Authentication = Who you really are
Permissions = What you can do

Check out this post for more detail on API ID and Permissions.

While, in this instance permissions may be implicit (where by virtue of being authenticated you are able to use the API), consider this: As the provider of an API to a service with the level of sensitivity payments require, I want to know that the consumer is who they say the are.

Passing an API Key only confirms that you have the API Key: it does not prove that you are authorised to access the API.

Now, possessing an OAuth Access Token may initially be viewed the same, however the OAuth RFC states

  The authorization server MUST authenticate the client whenever
     possible.

OAuth enables this by providing refresh token, as you said, along with a registered redirect URI. It also suggests a minimally scoped token for all initial and re-authentication requests.

This gives the API provider much more control, more visibility and thus more confidence that their API has not been compromised.

OAuth also plays nicely with permissions. If the payment gateway company decided to extend authentication to require permissions to GET and to POST, this would be less work and more secure than if you had to try to tie a key to permissions.

Exposure

A secondary but relevant consideration is what to do if the API Key is exposed.

I know I want be able to trust the key, however it might have been breached. So I also whitelist the clients IP... IP’s can change, depending on configuration, and they can also be spoofed... How can I know if the key is being used nefariously or not?

If the API key is then re-issued post breach it can be easier for someone to determine possible new keys once the initial key is known. This means that the providers key gen algorithm may also need to be adjusted.

If you were issued an Access Token that somehow got exposed, once it comes up for refresh, the unauthorised user should not be able to get reauthorised. I can log them log this erroneous request and work with the consumer to diagnose root cause.

Summary

The API key was only ever meant to serve as a form of ID. As such they are basically misused when implemented as a primary security measure.

If API Consumers need to be authenticated - as in you need to verify the caller of the API and provide access to certain resources based on that verification - OAuth is the better choice.

Hope this helps!

NB For arguments sake, I have assumed no one has root access to your internal services or network, and all over-the-wire comms are via HTTPS.


Does X.509v3 certificates prevent MITM attacks in SSH

X.509 is just a format for public key certificates, the type typically used by web browsers. The critical idea was to have the public key in the certificate signed by someone else who's public key you also trust. In web browsers these are the root certificates that come bundled with the browser. Typically companies like Comodo, DigiCert, GlobalSign, etc. They allow you to trust https://acme.com when acme.com's certificate is signed by a trusted root certificate. The same could be done for each ssh host as it is for web hosts, but it tends to be too much work and cost. So, you typically see a ssh 'fingerprint' when you ssh to a new host and a warning if the host changes its public key.

Notice that the public keys used to sign certificates still need to be distributed to the end user. Computer OSes like Windows and Linux also come bundled with root certificates. So the vulnerability in the X.509 scheme is in someone replacing trusted certificates in the software before it is installed on your system.


What actual damage can a DDoS attack do?

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.


How safe is it to give a device that has malfunctioned to just anyone?

It's going to be impossible to tell what can be extracted from a non-functioning device without inspecting it. It is impossible for us to know what has malfunctioned or how or if storage is accessible or damaged.

So, yes, there is a possibility that someone could extract any amount of data. If you want to be on the safe side, and you cannot factory reset (and be sure that the reset worked), then destroy the device instead of giving it to just anyone.


Using self-signed certificates for your mail server

My understanding in regards to the first question is yes, it's safer to use a CA.

Regarding the second question, the attacker would have to create a key that had the same public key as your CA. This is hard, and gets harder with the size of your CA. Basically you only have to worry about a government or multinational corporation. The only difference between your private CA and Verisign's CA is in how securely the CA was generated & is stored (NOT insignificant) and the fact that Verisign is paying Firefox et al to preinstall their CA.

The best intro tutorial on SSL I've found has been available for many years and is still current: http://www.vanemery.com/Linux/Apache/apache-SSL.html


Should all Server Certificates from one CA have the same CRL

Each CA certificate is supposed to have one and only one CRL.  It is serialized and signed with that CA certificate, and each subsequent serial number supersedes previous ones.  However, items should not be removed from it ever.  I don't believe behaviour is defined where a CA maintains multiple concurrent CRLs.

That said, as a CA, you may (must) maintain a separate CRL for each CA certificate (subordinate or otherwise).

The reason for multiple crlDistributionPoints is to allow you to increase reliability by giving multiple URLs.  This isn't really necessary because there are many different ways to provide reliability, but it can be helpful I am sure in some scenarios.


Additional confirmation for online bank payments

I've never heard of just using the date of birth for authentication. It's a bad idea as a date of birth is non-revocable. Meaning if it is "compromised" you can't change it.

If it is the only means of authentication for consulting account or transactions it's a REALLY BAD IDEA.

But that brings me to my second point. It is, in general, not considered your risk, but the bank's. If you can proof their authentication mechanism sucks and you get defrauded, there is a reasonable chance the bank will have to pay you back as they weren't very diligent.

That being said you would still have to go through a lot of hassle to get that settled. If a bank is taking such an approach and there are no other controls in place, I wouldn't stay with the bank.


What Symantec does with the specific mail is probably their secret sauce and also depends on the mail. But common things are

Adding "signatures" to anti malware programs in case the mail contained malicious attachments.
Updating the reputation filter for web sites in case the mail contained links to sites where the attacker tried to grab credentials or deliver malware.
Updating reputation of sender IP address so any mails from this address gets marked as harmful.

These updated rules then get shipped to all their customers so they can profit from your finding the same you can profit from their finding.


what fields should I encrypt in a database containing user information?

Encryption is just a tool; it is applied for mostly three reasons:

To achieve some confidentiality. This makes sense in contexts where the stored data (database contents) could be exposed to malicious third-parties, but some specific data element (the encryption key) could be kept hidden from the same malicious third-parties.
To achieve compliance to some regulations. For instance, when dealing with credit card information, one more-or-less has to follow the prescriptions of PCI-DSS, including applying some encryption for some pieces of data.
To give a feeling of security by sprinkling some crypto all over the place. This reason, of course, is not good; however, it is very common in practice.

For the first reason, this makes sense only relatively to an attack model where attackers cannot read the encryption key. The application which accesses the database must, by definition, be able to read the data contents, so it must know the decryption key. Consider, for instance, a comprehensive full-database encryption (what Microsoft and Oracle call TDE): this encrypts all the database contents; but the application that accesses the database must know the key, to decrypt the data on-the-fly, and sees the cleartext contents. If the attack model is about attackers who steal backup tapes or recover discarded hard disks, then TDE is the way to go: such an attacker will only see a big encrypted pile of data, with a key that he does not have. On the other hand, if the attack model is about SQL injections, then TDE offers no additional security since the injected SQL is interpreted in the context of the normal application, over the decrypted data.

For the second reason, encrypt that which is necessary to achieve compliance, and be done with it. That's the good thing about compliance: you do not have to think, only to follow the rules.

For the third reason, you need to invoke the crypto gods for every field that auditors / bosses / customers feel to be "important". Usually, people feel nervous about what they consider to be their identity, so names, email addresses, street addresses, phone numbers... should all be encrypted. Since this is only security theatre, you can most of the time achieve the same kind of psychological effect with an "encoding" that needs not be encryption properly said (e.g. Base64).


It depends on what routing technology that you use.

I know cisco switches have a optional security setting on allowing only a few MAC addresses associated with a port. See port-security.

This makes it impossible to set up a bridge between your network and your colleague's network, as the bridge will proxy the arp packets between the two networks, hence making the switch block the port.

A gateway router between two networks will not work either, because they will have to manually add your gateway/network in their router's routing table.

But, a NAT gateway should work, but along with the limitations a NAT router have. The colleague's network will not be able determine if your machine is acting as a gateway for your subnet or is acting as a single machine. (Unless cisco have implemented some crazy fingerprinting to determine inconsistency between the TCP/IP stacks used for various connections).

So, with these three possibilities, I suspect it is the port security which is banning routers from connecting to your network.


Does client side hashing add any benefit here?

When you hash passwords on the client, the shared secret between client and server is no longer the cleartext password but the hash of the cleartext password. Your password is no longer monkey, your password is now $2a$04$RuNMmxnNakaesRjxjI3IAO70b2zK8lb5eRLb./huDLJ0OkWC0ikGm (bcrypt hash of "monkey"). The server would then hash this hash again and compare it to the hash-hash it already has in the database for that user-account.

So anyone who somehow obtains the client-calculated hash can compromise your user account.

The only advantage you have in this scheme is that the server is never aware of the user's cleartext password, not even in memory. This makes it provably impossible for the server to steal the cleartext passwords, even if it had malicious intentions.

Keep in mind that this scheme requires that the client always uses the same salt for hashing the same password. Otherwise re-hashing the hash on the server-side won't yield the same result. But you can use different salts on different clients and you can change the salt when you change the cleartext password.


The brute force attack can be described as such: the attacker tries a lot of random potential passwords, until the right one is found. Forcing a password change for the user, i.e. changing from one potential password to another, does not substantially lower the success rate of the attacker (indeed, it changes anything only if the spaceof possible passwords is so small that the attacker can explore it exaustively -- and this means that you have a bigger problem, which is that your users choose very weak passwords). It is a widespread, but wrong belief that password changes somehow "restore security".

What may make sense is to disable accounts which are the target of a brute force attack, indicated by a lot of failed attempts. But this kind of locking feature can backfire: it allows anybody to lock the account of anybody else, which can turn into a big helpdesk problem.

Correspondingly, there is no need for you to change your cellphone provider password because it is old. Change your password if it is weak, but weakness does not grow over time; it is there right from day 1.


How can I implement a secure download area on a website which requires an electronic signature?

It is worth noting that numerous services exist online that do this sort of thing. Accellion, LiquidFiles, Dropbox, Box.com, and numerous others can grant you this kind of functionality. Depending on volume and complexity, you might even be able to leverage some marketing-oriented online service like salesforce.com or hubspot.

There are a zillion things that you do wrong in trying to do it yourself. You should definitely consider signing up for an existing online service or installing software that does this.


Distribution of keys for a python messaging application

A simple solution would be for each client to encrypt messages sent to the server using the server's public key, which is usually sent to the client as part of connection negotiation. The server can then decrypt the client's message using its private key, and then re-encrypt it using the private key to distribute the message back to the other clients - who can then read the message using the server's public key to decrypt.

'Better' solutions would involve distributing each the public keys of all connected clients as part of the initial handshake. The client would need some means of knowing how to associate a public key with the message sender which means that there is some information leakage outside of the encrypted text. This is better because now the server can be compromised and the information being transmitted is still safe, but comes at the cost of slower connection speeds and additional complexity.


How are RFID access systems compromised?

The Proxmark 3 supports a variety of RFID protocols.  This is an open source RFID platform that is commonly used by malicious actors to capture and replay RFID tags found in the wild.  In practice an attacker would stand outside of buildings A and B and capture every card,  including card AB all the way down to card ZZ.

IT appears as though the TSEC reader is using the DESFire/Mifare standard,  which has been broken since 2008.  DES as an algorithm has been broken since 1973,  which was the year it was published. The proxmark 3 should have no trouble cloning these tags.

This is also a good talk for an introduction to RFID Hacking: Live Free or RFID Hard.  This talk brings up an interesting point,  a lot of RFID wallets don't work and have not been tested.  Most organizations don't require the use of RFID wallets, and treat RFID like magic.


My company uses Thycotic's Secret Server.  It is commercial, but it is also scalable, and the total cost depends on the number of users (active) and the feature set you need/want.

It is web accessible only (IIS/ASP.Net), and has a hosted version as well as installed versions.

Security wise, it is good enough for government agencies (US) and their booth at VMWare last year listed divisions of the Department of The Navy as current clients.


You are incorrect in your assumption that robots.txt on subdomains are ignored. Most search engines will grab and obey the robots.txt for individual sub-domains.

If you wish you can instruct spiders not to index elements of your website without listing them in robots.txt, through either:

Adding <meta name="robots" content="noindex" /> to the HTML of the web pages
Adding X-Robots-Tag: noindex to your HTTP headers

More details available here

However, regardless of this you should not be relying upon robots.txt for security. What you are leaning towards here is security through obscurity which is widely regarded as a bad idea.


Checking if TLS 1.1 and 1.2 implementation in a webserver is upto standards

This SSL test from SSL Labs covers quite a few properties of TLS.


Celebrity malware like Stuxnet, Confiker, Zeus will get the kind of attention you're referring to. Any list of those sort of reports is going to get out of date very fast though.

Many organisations inlcuding Symantec, Trusteer, Microsoft, SRI and Sophos publish malware analysis reports. There aren't any RSS feeds of these resources and some organisations spread the content all over their web presence in blogs, press releases and the like (Microsoft is particularly bad at this). You'll also have to wade through some promotional content from the commercial vendors and other research output from the pure research outfits. The easiest way to keep up with most of the publications in this area is to follow the SANS Internet Storm Center who publish links to a lot of the papers.

Shallower but more immediate analysis can be found from the VirusTotal community or ThreatExpert.


How to avoid abuse of web-server endpoint from a rogue client?

For your examples you'd need a throttling mechanism in your application which checks some preconditions like the timestamp of the last user activity before the request is processed.

However there's no general purpose measure which prevents all misuse of your application. You must analyze the use-cases in your application and think about how the functionality could be exploited in order to develop and deploy security controls. A penetration test could help with this.

Your current approach sounds a bit like candy security (Authentication as single security layer).


What types of software vulnerabilities are out there?

I think the most comprehensible dictionary of software weaknesses is the Common Weakness Enumeration (CWE).

The view Development Concepts (CWE-699) may be a good starting point for you:

  This view organizes weaknesses around concepts that are frequently used or encountered in software development. Accordingly, this view can align closely with the perspectives of developers, educators, and assessment vendors.

There are also graphical depictions of CWE, which shows relations of weaknesses in a directed graph, e. g., the graphical depiction of CWE-699.


I've shared fairly sensitive info with people over email and used 7zip do to it. As @forest points out, zip does not do encryption well.

Use the "encrypt with password" feature (or whatever it's called in your 7zip program). Select AES-256 encryption if it gives you the choice and pick a strong password. Don't email/text the password, instead read it to them over the phone or hand it to them on paper.

Assuming you chose a strong password, that zip file should be ok to email, put on Google drive, wtv. The one caveat is that zip doesn't encrypt the names of the files, so make sure there's no personal information in the file names.


Storing credit card numbers for enterprise payments

In my PCI work, I have not dealt with this question, but my understanding is that it depends on the issuer, brand and corporate context.

Visa and MC in the past have considered PCI at the enterprise level to apply to all PANs the enterprise has visibility into as part of its business, including issued corporate cards. Amex sometimes has not.

I would advise reaching out to your counsel and your issuer to understand what your issuing agreement says, and what their practice opinions are.

Independent of whether or not PCI applies, I would also advise reaching out to your security team to arrange a solution that allows for segregated storage of PANs outside of their reference in common corporate data systems like email, tasks, and calendar to satisfy the use cases that you have carefully, clearly, and helpfully outlined.

This may take the shape of a corporate-level secret management solution, which does not specifically apply to credit cards but which does support segregating the storage and transmission of sensitive information so that, for instance, emails/tasks/calendars can say "use card #25 for this" rather than "use PAN 5555... expiration xx/yy for this."


Can a VPN provider or actors within its infrastructure access open ports on the client machine?

Yes that is possible as your VPN client sets up a network interface like any other interface, and it sends and receives packets all the same. If you start a server application that listens on all available interfaces it will also listen for incoming connections on that VPN interface.

But just like your other interfaces you should have a firewall in place that blocks or ignores all incoming connection requests (except for the ones you have configured to be let in).

On the other end of the VPN connection (the VPN provider’s side) the system would normally also be firewalled and configured to not accept any connection requests going your way as that is not the service they are intending to offer and would also be a rather obvious security issue. The VPN services you have in mind are setup for one way connection requests, you can use it to connect and communicate by starting from your side, but not the other way around.

Other VPN setups like office-to-office interconnects would be configured differently, allowing connections both ways. But that does not apply in your case.

As long as you treat your VPN like any other internet connection to the outside word and filter/firewall it accordingly you will be fine, connection-wise.

There is one risk: the VPN provider itself. There is nothing preventing them from changing the settings on their side and have a bunch of traffic thrown your way which your firewall then has to block (so best keep it enabled). So the real question to ask yourself ends up being: how much do you trust them (and why).


vulnerability management, risk mitigation vs risk acceptance

There is no such thing as "no risk". There is always residual risk. Therefore, management must accept some level of risk (known as "acceptable risk").

"Inaction" is not the same as "accepting risk". What you are seeing is management not wanting to make a decision that costs money. That's all. There is no "risk thinking" here, so you can't look at it through a risk lens.

Yes, there should be a simple risk process to identify, assess, and treat the risks in this scenario. Most managers are not well trained in risk basics and are not aware of how simple, effective, and straightforward it can be. Many managers in small companies are afraid of formal risk processes because they can seem like a lot of overhead and bother.

You can kick start this yourself by asking judgement-free questions of management.

what is your nightmare scenario in this situation?
how comfortable will you be if the worst-case happens?
are you ok with these vulnerabilities being un-mitigated in the meantime?
do you want to put in some extra monitoring or other protections to help reduce the risks?
do you want me to look at low-cost alternatives to patching to see if they can reduce the risk to a level you would be more comfortable with?


up2date tools for security audit linux / centos

you can use a combination of a vulnerability scanner and credentialed checking to achieve a decent level of confidence in a base build.

Nessus, Nexpose and OpenVAS will all do scans of servers and if provided with credentials to log into the server will so some more detailed checks.  Nessus and Nexpose are commercial products but have options which can be used for free for (AFAICR) non-commercial use only.

OpenVAS is open source so is freely usuable.

In addition to that the commercial version of Nessus can do compliance checking against Center for Internet Security or other security standards.

The benchmarks that CIS provide are usually worth reading in and of themselves as they have some decent suggestions for build hardening (although they don't have RedHat CentOS 6 coverage yet as far as I can see, I'd imagine that the v5 standard would still be largely applicable)


Should Javascript & IFrames be used to refresh sessions when Master Cookie Domains are used?

It seems to me that what you are proposing does not violate the normal workflow.  You are making a request from the asserting party (site1 or site2, AP) to the service provider (auth-SP) which in turn is making a request to the identify provider (IdP).

It is also fairly common to implement this approach when a site accepts credit cards but doesn't want to accept the PCI regulatory burdens.  A company like Cybersource serves as the SP and accepts user input in an iframe within the AP web page. As far as PCI (Payment Card Industry in case the acronym is obscure...) is concerned, it's no problem.

I'm not sure how the confirmation number is returned to the AP, but that doesn't much matter.


What should I do to develop a secure note taking app in Android 8.0?

These two goals are incompatible.

  I want this application to work well on [platform] that runs Android 8.0.

and

  Google (through the OS) to [not] have access to its contents.

"runs on Android 8.0" by definition means the OS (Android 8.0) will have access.

Assuming you want to do minimize that access, at the very least you will want to write your own keyboard. All those spell-check, auto-correct, and text prediction features are part of the OS, and the keyboard will have access to every key stroke you enter.

More reasonably, you probably shouldn't worry about RAM scrapers for memory, or the OS and keyboard, and just encrypt the bytes stored on disk for "good enough" protection.


TLS_RSA_WITH_3DES_EDE_CBC_SHA reported as 112 bits

You should disable all triple DES ciphers because 192 bit triple DES keys only have about 112 bits of security and 128 bit triple DES keys have even less than 112 bit security, rather around 80 bits for the best attacks. Furthermore, triple DES only has an 64 bit block size, which is detrimental to security as well.

There is a difference between the key size in memory - including overhead like parity bits (192 bits), the bits used of the key (168 bits), the intended security of the key (112 bits) and the actual security given the attacks possible on the cipher (still 112 bits). The figures between parentheses are for triple DES keys (DES ABC). For double DES keys you will come to 128 bits / 112 bits / 112 bits and 80 bits.

AES 128 has an actual security of over 126 bits (128 bits encoded, 128 bits actual and 126 bits of security) it should be strongly preferred. It's also much faster than 3DES and is widely supported, so disabling 3DES altogether should be the preferred option - unless you are certain that clients will fail.

In general you should try and achieve a security of around 128 bits or over.

Notes:

the strength of the symmetric cipher used in TLS has nothing to do with the certificate used;
the 112 bits of security is because of a meet-in-the-middle attack which was already known when 3DES was designed, so 112 bit is the intended strength of three key 3DES.


This is a XY problem since your real issue is the time synchronization issue. Why did you end up with that?
I would say, the problem is not only bruteforce (you additionally detect TOTP bruteforcing, right?), but also reuse. You want a small enough value to prevent repeats. Watching you log in would allow me to do that during the next 15 minutes, although it could be argued that 30 seconds might have been enough. You probably don't want to make it even smaller than those 30 seconds, since you need some time for people to manually retype them, plus all the time synchronization issues that might arise.
I would favor the second option, but what confuses me is how you need both past and future timeslots (note: 15 + 1 + 29 = 45, not 30). The RFC already mentions, and it is recommended that you do, adapt the calculation to each device drift. This should (a) allow you to avoid many of these errors and (b) if you know that 1 minute ago, the user provided the code for "2 minutes ago" (as seen from the server clock), you only check codes after that, i.e. you shouldn't allow a code from 5 minutes ago since they showed their clock is already ahead of that.
And obviously, it is paramount that all your verifier servers have their timedate correctly kept synchronized (NTP). :)


Like others have said, firewall, and if you feel it necessary IDS/IPS too.  But to me, it's the wrong question.  You need to address these things:
Forensics
Have you managed to work out how you were comprimised before?  If not, it would be a good place to start.  Knowing how your system ended up with a RAT on it in the first place means you can close off that door
Firewall
As mentioned by a few others, firewall that stuff.  A box running two NICs and using   UFW or Iptables to filter traffic is a good start, although make sure that box is itself very locked down.  Consider whether you need to run each service on the firewall box too.  e.g. if it's in the same room as you, does it need SSH/telnet running, or can you just use it in person?
IDS/IPS
If you consider it necessary, you could even add an Intrusion Protection/Detection System to the box.  There are several freeware tools to consider in this regard.
System hardening
Both on the box you proxy through, and the box you develop on, consider some hardening.  Get a software firewall that is good for your OS, and antivirus for that OS too, and ideally some way to check regularly for Rootkits etc.
Good practices
More important than any of the above is to adopt good practices.  It's no good setting up a hardware firewall if you then open ports whenever something doesn't work, and forget to address whether they need to stay open, and it's no good installing a rootkit finder if you never run it.
All of this said, base what you do on a risk assessment (useful to know how previous exploits worked for risk assessment, too), and don't go overboard.  You could spend a week building a nice little setup with custom hardware firewalls, IDS/IPS protection, hardware level AV, and all manner of other stuff, but if you'd do better with a simpler set up and spending that time working, consider whether that's a better idea.
Audit
Try and find a decent security audit tool for your system.  If you are running linux, I find tiger is pretty good,
Opportunism
The likelihood is that you weren't targeted.  Statistically speaking, people trying to make money out of security holes in a criminal way (like holding code to ransom) aren't seeking out particular individuals to exploit, but rather people who fit a certain demographic.  It's more likely that you were exploited last time because some script kiddie could find a dev server of some sort running or something like that, and was scanning for these particular things in order to perform the exploit on you that they did.  Your biggest aim is to make yourself hard to find and then target, as this is a much more likely scenario than a direct target of you and only you.  The other thing that makes me think this is that you were extorted for money, whereas a targetted attack would probably be trying to steal your code and keep it.
Consider whether you may have been targeted, but I think on the whole, closing any security holes you can find will be a good first step.  I think you can probably avoid this problem again with just the firewall, but a lot depends on how you were comprimised.


How to allow only some specific computer systems to access website?

You can't do it using the MAC address - these are not visible across routers. Even if you were on the same LAN, it doesn't solve the problem (as posted) since it's trivial to change a MAC address.

The big question is how closely you need to stick to your requirement.

There are lots of solutions such as simply authenticating the user, using authentication devices (such as RSA keyfobs), client side certificates - but these methods can be transferred between machines. Browser fingerprinting makes it more difficult, and something like evercookie makes circumvention more difficult (but more likely to fail to work in the first place).

Really we need to know more about whether it's the device or the user you need to authenticate and how strong the requirement to disallow duplicated access is.


sudo cp /usr/bin/curl /usr/bin/curl.bin
sudo vim /usr/bin/curl.wrapper

here is the wrapper:

#!/bin/sh

date >> /var/tmp/curl_ppid.log
ps -f -p $PPID >> /var/tmp/curl_ppid.log

exec curl.bin "$@"

and then:

sudo chmod 755 /usr/bin/curl.wrapper
sudo touch /var/tmp/curl_ppid.log
sudo chmod a+w /var/tmp/curl_ppid.log
sudo ln -sf /usr/bin/curl.wrapper /usr/bin/curl

It is better to keep the wrapper script in another location called curl.wrapper, so your package manager will not overwrite your script during an update.


How big window is secure and practical with TOTP?

There isn't an industry standard on this that I'm aware of. It's up to your implementation and expected desyncronization. A single minute may still have synchronization problems.

If you set it to 5 minutes (in each direction) that's a total of 20 valid OTPs at any given time (assuming a 30 second expiration). This means that a guess would have a 1 in 50000 chance of being correct, or averaging about 25000 trials before a success. It would be very easy to detect when someone is trying to guess. Because of this, as long as you have a proper password system with rate limiting, 5 minutes should work fine for your case.


Penetration testing - how to fix a vulnerability?

When the application is open source, then you just need to find the sourcecode section which is responsible, fix the bug and recompile. You might want to send a patch to the maintainers of the application so they can apply it to the mainline.

When the application is closed source, then providing a patch yourself is usually practically impossible. You could do what the crackers do and manually edit the compiled binary with a hex editor, but this is 1. very difficult and tedious and 2. often a violation of the EULA of the software.

Sometimes you can plug a vulnerability temporarily with a firewall rule or some other middleware layer which prevents the exploitive data from reaching the application intact. Sometimes you can also temporarily fix a vulnerability by switching off a specific feature or changing a specific setting of the application (hope it's something you don't need).


While SSL 3.0 POODLE is a design problem in the standard which thus affects all implementations TLS POODLE is an implementation problem only, that is implementations did not implement the TLS protocols properly.

According to https://technet.microsoft.com/en-us/library/security/3009008.aspx?f=255&MSPPError=-2147217396 (updated 04/2015) and https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls IIS is not affected by TLS POODLE.


How are browsers able to find and construct an alternate trusted chain path?

In SSL/TLS the server is supposed to show its certificate as part of a chain. Theoretically, the server should make sure that the sent chain is correct, and the client is "morally entitled" to reject the connection if the exact chain sent by the server fails to validate. However, clients are allowed to make extra efforts; if they can validate the certificate with another chain, then it is OK to continue.

Therefore, one cannot formally blame some clients for failing to validate the server's certificate if the server sends a flawed chain.

When a client tries to build an alternate chain, it will use some or all of the following methods:

The client may have locally installed intermediate CA certificates (in Windows system, the "intermediate CA" store is meant for that).
The certificates sent by the server may be reused (but maybe not in the same order).
The client may have access to some LDAP server or equivalent in which some certificates may be looked up by subject name (this may happen in Windows / Active Directory setups). The initial plan for X.509 was that there should be a worldwide Directory, like some sort of generalized DNS, but it never happened.
The client may try to download other intermediate CA certificates by following the URL found in the Authority Information Access extensions of the certificates.

This last method is what will usually work. A well-issued certificate will contain an AIA extension with an URL pointing to the certificate for the CA which issued it. That certificate may itself contain an AIA extension pointing to the upper-level CA, and so on, up to the root. As long as all URL are publicly accessible, network is up and running, and no sysadmin got into his pathetic excuse for a mind to block that mechanism (I have seen it done, unfortunately), then the chain will be successfully rebuilt. Modern Windows systems do that automatically.

But remember that SSL clients are allowed not to behave that way. An important point to notice is that URL-following relies on HTTP. A Web browser knows HTTP; that's kind of a core feature of a browser. However, a stand-alone application that uses some SSL library may not be as able to issue random HTTP request, or even simply willing to do so. Some SSL libraries provide the protocol support but rely on the caller to actually provide network connectivity (the caller opens and operates the TCP connection, the library being purely on the computational side of things). Depending on how the application is designed and its SSL implementation, you may or may not succeed at pushing the extra certificates where necessary.

It is much better if the server is properly installed in the first place.


Why banking websites always ask me to authenticate my PC even after I'd chosen to "Remember my Computer"?

An aspect of security which more and more banks are implementing is to try not to trust anything sent by a computer, as an attacker could theoretically change the responses sent to the bank.

Imagine you have authenticated your PC, and an attacker has captured your traffic and has your cookies. If they then try to log on to your account and the bank doesn't ask them to authenticate their PC, that is one less hurdle for them to beat in order to get at your money. So the bank can insist that their cookies are not stored, or that specific ones are wiped on logout.

From a general security perspective, I wouldn't let my PC remember any details from an internet banking site, or in fact any site that could be used to steal sensitive usernames or passwords.


What are useful use cases for employing asymmetric cryptography in a database?

Suppose your web application needs to store your users' credit card information for automated recurring billing purposes.  For PCI compliance, you might decide to offload the the storage of the credit card information to a service like Authorize.Net that stores and tokenizes the credit card information in a PCI-compliant way.
However, you don't want to be locked-in to using Authorize.Net forever - you want to be able to migrate to another vendor if things go south with Authorize.Net.  But, you've seen from posts like this that Authorize.Net does not make it easy for you to export your users' credit card information from their system.
So, you decide that it's best to encrypt and store the credit card information in your own database, in addition to storing the information in Authorize.Net.  Asymmetric cryptography is ideal for this use case - the data is encrypted on the server using the public key, and the private key is stored offline.  This way, you have the ability to decrypt the credit card information if you ever need to (using the private key) - but if the server is breached by an attacker, he has no way of decrypting the credit card information (because the private key not stored on the server).


Is there a coordinated Firefox user-agent for anonymous browsing?

Existing user-agent strings for popular releases would be de facto coordinated standards. These could include (in assumed order of popularity):

Latest Windows Chrome release
Latest Windows Firefox release
Latest Ubuntu LTS Firefox release
Latest Ubuntu Firefox release
Latest Debian Tor release

...but for greatest effectiveness smaller communities would still need to coordinate around one of these, and pick an UA that has limited/no effect on usability (sites that still sniff for browser compatibility).


Can I reencrypt my GPG private key with more password rounds?

From what I read in the GnuPG manual, you may use --edit-key and the passwd subcommand to change the passphrase on your key; if an iteration count was provided on the command-line with --s2k-count, then the new password hashing should use the specified count.

(I have not tried it; this is just theoretical.)


Is it possible to test for Postgres BlindSQL injection using pg_sleep() in a WHERE clause?

First of all, try the simple approach. Is this really a situation which only allows a completely blind injection? For SQL injection vulnerability in the WHERE part it is far more common that the application will react differently depending on whether it got at least one row or none at all. And it is likely that the injection can force an empty result set via AND 1=0 or an none empty result set via OR 1=1

If this approach fails because the data is not used for anything visible or you cannot force the empty/non empty set, only then it is time to look for blind injection techniques.

To include a SELECT clause into an WHERE part you can use a sub select or a function like strpos:

strpos(
    (SELECT CASE WHEN 1=1
            THEN pg_sleep(10)
            ELSE pg_sleep(0) END
    )::text, '1'
) > 0;

There is an interesting paper on Advanced PostgreSQL SQL Injection and Filter Bypass Techniques.


How should I deal with adware in chrome on ubuntu?

chrome://extensions/

Type this link to your address bar and press enter. These are the extensions of your Google Chrome Browser.

Search for a malicious extension that could be responsible of these popups.
By clicking the trash icon you can easily remove an extension.

Removing extensions do not harm your browser or computer. For being sure you can remove all extensions one by one.


Why would a software need my IP address in authentication token?

Is there a legitimate security reason to need it? My guess is to ensure that no other machine can reuse the token.

That is a pretty good guess! Depending on how the software is implemented, it could be that the software is restricted to internal use (within the company) & there is IP whitelisting enabled at authentication level of the software.

Therefore, an intruder would need to have the token itself and prior information on having the IP address as part of the token as well.


UAC or logging into admin account first before installing software?

They are both essentially the same, let's think of the possible scenarios.

an attacker takes over a single user
an attacker has admin or more permissions on the machine

Since Uac runs in a restricted desktop the standard user has no access to that desktop object, meaning that any keylogging, injection or screen logging activity done in this permission set should be blocked, the same as running in a different login session.
Assuming the second scenario the attacker has full access, meaning that it doesn't matter.

If we are talking about exploiting the mechanisms both have a pretty big attack surface(assuming an exploit or bypass);

uac has anything from registry or path based side loading, the desktop object not being secure and the entire consent mechanism being broken.

Logins have the registry profile, files on disk, lsass rpc calls, gpo and many other attack vectors for exploitation.

I would go with what is easier for you, just keep your admin password cycling and the account usage to a minimum and you should be safe in that regard.


Anonymity Stack: Home connection -> VPN -> Whonix(Tor) -> Socks5. Few questions on anonymity

First, some comments
I'll be frank here. A lot of your setup is poorly thought out or outright dangerous. For example, using a proxy after Tor (it's not TOR) can greatly decrease anonymity as you now have a centralized exit point (even with the use of rotating proxies). This is exacerbated by using a VPN, since now rather than having a protective chain of relays, you have two points, both controlled by individual entities, which can collaborate to fully deanonymize you. But let's look past that for now. Some comments about the assumptions...

One home internet connection from an ISP that keeps a close eye on potential TOR usage. The connection is being shared by a couple other devices and people.

Being shared by multiple people is irrelevant, as TCP/IP fingerprinting is able to distinguish multiple devices coming from a single IP. If you need to reduce the chance of an ISP knowing you are using Tor, you may have to use pluggable transports with a bridge. These are designed to obfuscate the Tor protocol in various ways, though the use of a bridge is only intended if you are being blocked. It is not always sufficient for simply avoiding membership attribution.

One solid VPN provider that resides in a non 14 eyes jurisdiction, doesn't have a record of collaborating with intelligence agencies, offers stable servers in a multitude of locations, employs a zero-logs policy running everything from RAM memory and doesn't even ask for account names or emails.

A VPN being in a non-SSEUR (14-eyes) jurisdiction can actually make anonymity worse, as now rather than going through small ISPs in a "bad place", you are going through the border of a "bad place", complete with all their IXP taps. This can be bad enough that some circuits that go through many topographically distant countries can even lead to complete deanonymization. Furthermore, even if the VPN claims to provide zero logs, their ISP and DC certainly does log, it would be unheard of not to. See this answer which provides an example. I strongly recommend you read it.

Payment was done through bitcoin.

I'm sure you're already aware of this, but bitcoins aren't anonymous. Ensure payment was done with initially anonymously obtained bitcoins.

A standard whonix setup(gateway, workstation) running as virtual machines on the host using VirtualBox

VirtualBox is rather insecure, as are most hypervisors. It can be especially vulnerable to leaking graphics information when hardware acceleration for graphics is used. Whonix is best used with physical hardware isolation, so a simple 0day in the hypervisor will not bring down your whole anonymity system. Using hardware isolation will reduce the attack surface to that of the networking protocols, Tor control port, and SOCKS protocol.

A list of 1000 socks5 proxies which may or may not have their activity monitored and logged by a potentially hostile 3rd party which will be used at browser-level to access a website

This is dangerous, far more dangerous than using plain Tor exit nodes. Chances are a large number, if not all, of these proxies are managed by a single entity. This makes it far more dangerous than Tor, where each exit tends to be operated by a different entity.
Furthermore, there is the risk of the proxies being too close to your guard or VPN topographically (or even on the same subnet!). Tor ensures that none of the three relays in any given circuit are too close, but this guarantee breaks down as soon as you use "extra" proxies. If your VPN or guard and one of the proxies is part of the same DC, it can completely deanonymize you. This goes against "anonymity 101 common sense", but is quite true. There's zero chance that there will be no extensive monitoring between the border of your country and your "safe, non-SSEUR country", but there is a non-zero chance that there will be no monitoring at the junction between two small ISPs in the same country.
In the case of you -> vpn -> node1 -> node2 -> node3 -> proxy -> website, The three nodes are guaranteed not to be too close, topographically. There is no way for Tor to guarantee that vpn and proxy are not right next to each other, blowing your anonymity. This is the same reason using Tor over Tor is a horrible idea.
You may want to read Measuring and mitigating AS-level adversaries against Tor, which explains this phenomenon.

Machine -> Home connection/Personal IP -> VPN IP -> TOR -> Firefox ESR with a Socks5 Proxy-> Website

You should absolutely not be using plain Firefox ESR, even with "privacy" extensions. You should only ever use Tor Browser, or you will be subject to completely accurate fingerprinting (for example, through audiocontext fingerprinting). There are more than a dozen extremely important features which Tor Browser provides which are lacking on Firefox ESR and cannot be implemented in addons, requiring patches to the source code as well (like Tor Browser's reduced timing granularity of javascript.now()). Tor Browser is far more than just Firefox and a few addons.
To answer your questions, though...

Is there any way in which the ISP can know that we are on TOR and/or using Whoenix.

Yes, it can know you are using Tor. A VPN typically uses UDP or TCP for communication, and there is no padding. Tor on the other hand uses its own protocol, where data is sent in groups of cells of 514 bytes each (previously 512). This means that your ISP will see VPN traffic going through in bursts of 514 bytes, indicating use of Tor. There is likely also a way to determine that you are using Whonix with a high likelihood of Whonix makes any unique connection attempts at startup (such as update checks) that could be detected through a type of passive fingerprinting called website fingerprinting.

Could 'website' ever find out what the originating IP address really was?

Potentially, if it was coordinating with an entity that could see both your proxies and your VPN. Other than that, no, not with your first assumption in place, assuming it also extends to 0days and not just backdoors.

Is there any way to correlate what happens at the 'website' level with the originating IP address/connection

See previous answer. This question is basically the same as your second one.

Would using a public internet connection instead make a big difference in the anonymity of the setup?

That depends on many factors. A public internet connection may have more fine-grained logging. It may be subject to attacks on the WiFi protocol. Unlike a hardwired home connection, a public wireless connection allows countless others in close range to determine your unique hardware (MAC address randomization is not enough), and potentially mount website fingerprinting attacks.
Recommendations
Rather than just criticizing this setup, I think some recommendations are in order.

Use Whonix with physical isolation, or Tails.
Use stock Tor Browser with the security slider set to high, without any other changes.
Install open source firmware on your router such as OpenWrt.
Do not use anything extra like a VPN or proxy.
Ensure all your software is up to date, and keep track of disclosed vulnerabilities.
Avoid WiFi because of fingerprinting attacks from a local adversary and insecure WiFi chips.
And as always, be mindful of your OPSEC.


Suricata implements a sub- and superset of the Snort language, but doesn't add support for matching on the layer 2.
Recently there has been some work on at least tracking and logging MAC addresses (see https://github.com/OISF/suricata/pull/4975), so L2 is getting a bit more love.
In general, I would suggest opening a feature ticket describing the use cases.


Why do GUI terminals allow the pasting of control characters?

Terminals pre-date copy and paste. So within the terminal protocol, there is no distinction between pasting versus typing. The idea of pasting content into a terminal emulator window was retrofit into the system by simulating the rapid typing of characters when the terminal when the "paste" function is activated. This just dumps the content in exactly as it appears in the clipboard.

As for pasting control characters: the response of the terminal emulator's programmer would be something along the lines of, "Why would you even do that?"  You make a compelling argument that this could actually be an injection vulnerability in the terminal program itself.

As such, it's not out-of-the-question to suggest that programs like PuTTY and GNOME Terminal should have a setting somewhere which allows you to specify whether or not pasting of control characters is something you want to enable. Perhaps disabled by default.


What is ISO27000 (27001) and how to achieve it?

ISO27000 has little to do with penetration testing. It's a collection of ISMS (Information Security Management Systems) standards that provide a list of controls which an organization should implement as it enables (or should enable) proper security governance.

It's more on a conceptual level and provides more a set of rules which can be used to create policies and processes.

The standards can be used for both implementation as well as auditing. Auditors will review if you have correctly implemented all concepts and acredit you with the certificate if it is deemed you have performed a correct implementation. They will request to see the defined policies and will test these against the actual situation. This is almost never technical.

One of the controls (there are several) requires the company to perform regular attack and penetration testing. The auditor will not perform a penetration himself but will request relevant reports. The policies often also define how problems should be tackled or how risks can be accepted or mitigated. The auditor will review the report and request how follow up is performed (and review if this is done correctly)


Password reset system code system vs long hash

The token is just to verify that you received the email, that you own the account.

Password reset links in emails are a convenience that provide proof that you own the email account and allow you easy access to the password reset workflow.

These tokens don't have to live anywhere for long term and you can invalidate them after some missed attempts if you feel like it. So you don't need huge entropy the same way MFA tokens don't.


Does getting a challenge and response with hostapd-wpe mean that credentials were sent?

It seems the answer is yes getting a challenge response indicates the password was sent. My mistake was in cracking the password.

To successfully crack the password I created a new wordlist.txt with a couple of words in it and the actual password. I then used the following in hashcat on a windows OS.

hashcat64 -m 5500 -a 0 DOMAIN\username::::response:challenge wordlist.txt

I believe the mistake was the way in which I added to the word list I had

used echo password >> rockyou.txt

Which does not generate a new line... very simple mistake that cost me a few hours of banging my head against the wall.


Is Chromecast's UPnP requirement "a security nightmare"?

As long as you keep UPnP blocked at your gateway, you will be fine against any direct attacks against UPnP.  Later in that same article you linked:

  First, and foremost, you need to make sure you've blocked UPnP at your
  Internet gateway. Specifically, you need your firewall to block any
  system from outside your LAN from accessing the ports 1900/UDP, and if
  you have Windows systems, port 2869/TCP. Of course, what you should
  have been doing all along with your firewall is blocking every port
  except the ones, such as the Web's port 80/TCP, that you must use on a
  daily basis.

However, you will still be prone to lateral movement from an attacker gaining entry into the network from another attack vector.  Once latched into a network, typical reconnaissance involves scanning for vulnerable devices like those running UPnP.  The article does a good job to describe how vulnerable UPnP (or more likely, the various implementations thereof) are, so you will have to weigh the risk of running a vulnerable protocol behind your firewall.


Do people use "phising" as a real term, or just a mistaken spelling of "phishing"

It's a misspelling. Even in both links.

  phishing (M-W Online)

  a scam by which an e-mail user is duped into revealing personal or confidential information which the scammer can use illicitly

Might not be the best proof, but only 1.2% of all the Google results are for "phising" versus "phishing". I seriously believe this is human err. Furthermore, this is a relativity newer term, so it makes sense for things like this to happen.


If you boil an XSS exploit down to the basics, it's just inserting text in a field. In this regard, yes Selenium WebDriver could be used to carry out an XSS attack by inserting the appropriate code into text fields.

That said, there is a lot more to effecting an XSS attack than just inserting a script into text fields. You could just scan pages for text fields and blindly insert your payload, hoping for the best, but I wouldn't imagine it being a very effective delivery system. Then you come to the hurdle of verifying whether or not a payload was successful or not. You could reload the page and scan the DOM for your script, obviously countering any nasty surprises you inserted, and verify it that way but it doesn't sound very efficient. There is a research/discovery period in any successful attack unless you just hope to strike it lucky.

From a test automation / QA point of view I could see it being useful in terms of pen testing or regression testing. You can attempt to carry out XSS attacks on fields within your web application. Inserting script tags and ensuring the input is either rejected or handled properly depending on the expected outcome could be useful.

It really depends what your goal is. Are you looking to test and secure your own app or find vulnerabilities in others?


I already had bots connect to my applications when experimenting with client/server applications (only on well-known ports, though). However, the abuse potential is small. Bots which connect to random hosts usually first try to fingerprint what application is running (which will fail because nobody knows your application exists) and then run known exploits against that application (they won't know any for an application they have never seen).

If you want to be more careful (or just get rid of the noise), you can configure your router to disable port forwarding for your server application. That way it can only be reached from the local LAN.

If you want to be really careful, use virtualization software to run client and server on virtual machines which communicate through a virtual network.

If you want to be totally crazy paranoid careful, disconnect both client and server from the internet and have them communicate on an airgapped wired LAN.

Regarding your question "is there a way for an attacker to see the source of the custom programs I'm running": Did you intentionally write a program which responds with its own code to certain network messages (i.e. a networked quine)? If not, an unintentional bug which causes this to happen is quite unlikely, especially when you consider that C programs usually don't have access to their own code anymore after they are compiled. A buffer overrun vulnerability which dumps parts of the compiled code of the application is conceivable, but the attacker would have to invest quite a lot of work to reverse-engineer it and find more exploits. And I doubt anyone would bother to invest that much work to pwn a test program by a learner who might never even run it again.


To me this seems more like a bug than a security flaw. If the security of the site were breached, I would expect that the text remains the same (cause now it looks suspicious), but only the actual href changing to some malicious host. It could however well be that there is malicious intent involved here, which could best be confirmed by validating the destination of the link.


Forget LUKS password after mounting or lock LUKS partition when unmounted

cryptsetup won't automatically remember your encryption password, but when used in conjunction with Nautilus, you are given the choice to have Nautilus remember the password (which is generally VERY BAD if your home partition is not encrypted because anyone with access to it would then have full access to your "encrypted" drive).

When unmounted by Nautilus, the encrypted volume is first locked. If you chose for Nautilus to "remember" the LUKS password, it will not "forget the password after unlocking," but rather store it on your hard disk.

As for your last question of how the data can be made available if your system forgets the password, the simplest solution is also the most effective: remember it yourself (and type it into the prompt manually when going to mount the encrypted volume). If you need to have an easy-to-remember password that's secure, look up the XKCD method for secure passwords. (Or, you could be like me and memorize a 50-character random alpha-numeric-symbolic character string.)


Considerations if I were to lengthen session expiration dates at some interval if the client stays active?

As we discussed in the comments, the biggest problem here is that if someone gets a session token, they simply can send periodic requests and keep the session running.

Also once a session has expired. Just mark it expired. Don't let a session renew on another ping. (I am assuming that these sessions are not like different users on same machine. In that case, it could also be the case that a user forgets to log out and another user logs in and gets access even after the session has expired)

You can refer the OWASP cheat sheet on ways to handle session expiration.


Should I upgrade old volumes to new cryptsetup encryption mode?

There is no security advantage to AES-XTS over AES-CBC-ESSIV—in fact, in the standard threat model for disk encryption (an adversary can read multiple snapshots of a disk, e.g. because of bad sectors on spinning rust or wear-leveling in an SSD), XTS leaks slightly more information than CBC-ESSIV: XTS leaks exactly which blocks in each disk sector didn't change, whereas CBC-ESSIV leaks only which leading blocks of each disk sector didn't change.  Here a ‘block’ is the block size of the underlying block cipher—16 bytes, for AES—and ‘disk sector’ is the smallest unit of I/O on the underlying storage medium—typically 512 bytes or 4096 bytes.

For example, suppose you write disk sector 8137 twice, first with the text foo bar baz qux zot, and then with the text foo barbaxqux zot.  If we pretend a cipher block is a single word, then:

Under XTS, the two versions of disk sector 8137 will look like:

dbk iww dfv ngv jus
dbk iwwoywngv jus

Under CBC-ESSIV, the two versions of disk sector 8137 will look like:

dbk iww dfv ngv jus
dbk iwwoyw bst kib

That is, changing a single cipher block in the plaintext under XTS changes only the corresponding block in the ciphertext, whereas under CBC-ESSIV it also changes all subsequent blocks.  So the XTS adversary can tell exactly which blocks you changed, but in CBC-ESSIV the adversary can only tell how far along in the disk sector the changes started—they can't tell whether you changed one block, or two blocks, or all of the final blocks.

The only reason to prefer AES-XTS is that there's a United States federal government standard for it, unlike AES-CBC-ESSIV, and nobody in the Western world was ever fired for choosing a United States federal government standard for cryptography.

I am not sure what the text you quoted is on about, but here are my two best guesses:

For some reason, dm-crypt foolishly passes TRIM commands through for disks configured to use aes-cbc-essiv, but not for disks configured to use aes-xts-plain64.
A message got garbled along the way, and the author of the Arch Linux wiki page thought that aes-cbc-essiv is subject to the standard watermarking attack on aes-cbc-plain…which was the motivation for aes-cbc-essiv in the first place.


How is the username and password captured on this mobile device?

This is explained by the first, second, and third immutable laws of security:

If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.
If a bad guy can alter the operating system on your computer, it's not your computer anymore.
If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.


Security of Shared Corporate Credit Cards

Issue everyone with their own corporate card, so you can link each purchase to an individual.


When using an SSH tunnel does the server resolve domain names or is it still done via the ISP/DNS server on the router?

This depends on the kind of tunnel:

If you just do a port forwarding then all DNS requests will be done by your local machine against the configured DNS server and thus be visible by the ISP.
If you configure an explicit HTTP proxy in your browser and you tunnel access to this proxy through SSH then the DNS resolving will be done by the proxy, i.e. at the other end of the SSH tunnel.
If you use SSH as a SOCKS server then it depends on the SOCKS version in use. With SOCKS4 DNS lookups will be done locally. With SOCKS5 they might be done local or at the other end of the tunnel, depending on the capabilities and settings inside the browser.
With applications which are not aware of the proxy (i.e. use of socksify or similar) DNS lookups will be done locally (i.e. visible by the ISP).

A safer way would be to use a real VPN instead of a proxy since this way all network traffic independent of the applications configuration can be tunneled, including DNS lookups. But note that VPN is often misconfigured so that DNS lookups or IPv6 connections bypass the VPN.


Does MySQL Router offer any protection of MySQL-DBs behind it?

Maybe and only for DoS attacks. I see it's only like a load balancer.
For some extra security I would advice ProxySQL and then implement similar approach to https://www.percona.com/blog/2016/08/23/how-to-stop-an-offending-query-with-proxysql/ .

Explanation:

For databases main worst attack vector is SQL injection so routing/load balancing queries won't make any difference but blocking a query is much more better.

Best practice is to log every query and alert on some suspicion. Best case to use WAF but here ProxySQL acts like a database WAF.


How I add cookie to w3af for authenticated attacks?

In w3af in order to test a web application after selecting the OWASP Top 10 scanning profile you need to enable the auth plugin. The auth plugin can be enabled by placing a check mark in the box to the right of either the detailed or generic version of the plugin.  Many times simply selecting generic and supplying w3af with a valid user name and password will do the job.  If this does not work there is a second option which uses the detailed options which allow you to tweak the way the log-in credentials are processed by w3af.

There is additional information provided in the documentation provided by w3af at the following url:
http://w3af.sourceforge.net/

Also you did fail to mention whether you were using the CLI or the GUI version however these directions obviously apply to the GUI but can be converted to CLI by simply navigating the plugin tree in the console.


How secure is the use of fingerprints (like Apple's TouchID) for authentication in banking apps?

The problem is that the server cannot store a hash of the fingerprint, because the fingerprint can come with slight variations that would give a completely different hash. And if your fingerprint is compromised (either by taking it on a object you have touched or directly from the server) you can hardly change it - ok you can use up to ten fingers.

But a fingerprint can be a correct way to unlock a private key, because it become close to a 2FA authentication: something you have (the private key) and something you are (the fingerprint). And in case of compromission, you can always revoke the key. That means that to securely use fingerprint for authentication, you should combine it with X509 certificates.


Is it fundamentally possible to develop a (provenly) transparent computing system?

With existing hardware, no, it is fundamentally impossible to demonstrate that the code you run is indeed the code you should run and nothing else. This is easily seen with regards to confidentiality: imagine, for instance, that you run a vote-counting application; voters connect to it and send their vote. The "honest" application does not leak individual vote data, though it sees all votes and knows what each voter voted. However, from the outside, you see only the network packets that come and go, so you cannot tell whether some other part of the system is inspecting the RAM contents at the same time or not. In practice, a malicious system maintainer would run the application in a virtual machine and take VM snapshots whenever a new voter connects. By virtue of the VM emulating a "true" machine, this kind of malicious activity cannot be reliably dismissed.

Some things can still be done to try to obtain some guarantees that the code that runs is the expected one:

The hardware could be set up in a physically secured room, under audit, with access procedures that require at least two human operators, and video cameras recording the whole thing. This is commonly done for root certificate authorities: that kind of machine is on offline PC, kept in a cage in a secure room, and used occasionally (say, on a monthly basis) to issue a few certificates to intermediate CA, and to make new CRL. The whole process aims at ensuring that, indeed, the machine will do only what it is supposed to do; and this is all procedures, without special software.
For some operations, there are possible cryptographic protocols. For instance, for voting systems, one can use homomorphic encryption, allowing the central system to tally the votes without being given access to the actual vote contents. Since voters submit only encrypted votes, they must demonstrate that the contents are "valid" (they encrypted a 0 or a 1, but not another value): this is done with zero-knowledge proofs. Note the nuance here: the voter is not proving that he is using a specific, open-source code that encrypts his vote; but he proves that what he ultimately sends to the tally machine is indeed the encryption of a valid vote, regardless of how he actually computed it.


Historically, it has been possible, such as the GIFAR malware case from over a decade ago.

But as of now with modern web browsers, there is no way. It has been patched to prevent polyglot images from being executed at will. <img> will only read and output the image as an image, regardless of the Content-Type of the page itself (it used to take precedence).

However, you might want to know that it might be possible to do an XML injection using an svg file. XSS will not be possible as long as you stick to the <img> tag, but XXE can occur.


I could not find anything about this particular ISO 97001 on the ISO website or any other related sites. But I saw you placed a tag ISO 27000 and that you mentioned ISMS, so I suppose you are talking about ISO 27001 which is Information Security Management System.

Normally, with all ISO certification, once you are accredited the certificate, scheduled surveillance audits will have to take place. Should you have major deficiency, the auditor will give you a certain amount of time to take corrective actions. If, after the given time, you have not successfully implemented those corrective actions or adjusted your processes, a certificate revocation will/can be issued.

The main reason you implement the ISO 27001 is to cover business risks. If you see that you have the ISO 27001 but that you actually don't bother using the controls defined in the framework except when there's an audit, then you have a serious security mentality issue within your company. Also note that if there is a serious incident and it is shown that controls defined in the framework were not followed, you are not covered by the framework/certificate anymore.


Are my personal files safe from BORA ramsomware if I have set them to 'read only'?

If ransomware hijacks your account, it can do anything you can do. This means it can just turn the read-only bit off again. Thus, this is not an effective defense.


GUI isolation in X11 when entering Truecrypt password

Xterm does not allow isolation unless you set it to run as another user, in another tty. Gksu and Gksudo do not provide any sort of isolation at all. The same applies to all other password entry utilities, like kdesu/kdesudo, pinentry, etc. They are regular windows, like any others.
Wayland supports isolating Windows, but only for applications which support the protocol, which Truecrypt does not. All programs which do not support Wayland fall back to the legacy X11 protocol, which Wayland supports as a fallback, but which it cannot provide any window isolation for. As a result, using it with a bunch of legacy applications does not provide you with extra security, and your Truecrypt password can still be snooped.
There are two viable solutions I can think of:

Open a new Xorg session in a new tty as a new user, and open Truecrypt there.
Go into a tty without Xorg running, log in as root, and mount Truecrypt using command line.

Note that unless you are very careful, a determined attacker can almost always gain such a password if they have access to your regular user. For example, if you ever use sudo or su to get root, they can keylog that. If you do not do it in an X session, they can still hijack it using functions, aliases, LD_PRELOAD on your shell, etc. If you are ever root and you use su to lower yourself to your regular user, then root can be hijacked with a tty pushback attack. If you try to switch to a different tty to log in as root so your possibly compromised regular user can't sniff your Truecrypt password as you enter it as root or a safe user, you might actually be presented with a fake login console where you give it your root password, instead of agetty (or logind). The only way to mitigate that is by remembering to use the SAK combo every single time you switch to a new tty to log in as root. So you see, there are a lot of things you will have to remember, and you only have to slip up once for a determined attacker who has access to your regular user to grab your Truecrypt password.
My personal security procedures are very robust but can be a bit tiring if you are very GUI-oriented. I do almost everything in the terminal, without using Xorg. I use grsecurity with RBAC to isolate individual programs so they cannot mess with my $HOME or any configuration files if they get hijacked, I always use SAK when switching to a different tty to log in, and when I do need to use Xorg, I only keep one or two programs open at a time. I only ever need to use a browser, a few video games I run under Wine, and Gimp for photo editing. Xorg runs under a different user. This may seem excessive, but it's pretty much the minimum that assures that, if my regular user is compromised, then nothing short of me slipping up and forgetting to use SAK or using su to get root instead of logging in as root in a new tty, or a kernel 0day will be able to initiate keylogging to get something like my encryption key.


If the browser is already "aware" of the HSTS policy for this domain, then the browser will immediately rewrite the request to go over HTTPS and will fail if that is not possible.  There are two ways for a browser to become aware of an HSTS policy:

Have previously visited the site with a valid HSTS policy, and recorded that HSTS visit.
Having a preloaded HSTS policy from the site operator, such that the policy is included when the user downloads/updates the browser.  Each browser has their own procedure for preloading HSTS.

So, if your policy is not in the preload list and your user has never visited your site before, then the first request may go over HTTP.  (And, in the case of an active MITM, it may stay over HTTP since they can strip the HSTS header.)

Edit: includeSubdomains applies to the subdomains of the current domain being visited, and so a user visiting www.example.com will not get a policy for *.example.com, but *.www.example.com.  If you want to apply the policy to all subdomains of your top level domain, you need to get the user there somehow.  (This doesn't have to be a redirect, it could even be an IFRAME.)  Per the RFC:

  The OPTIONAL "includeSubDomains" directive is a valueless directive
  which, if present (i.e., it is "asserted"), signals the UA that the
  HSTS Policy applies to this HSTS Host as well as any subdomains of the
  host's domain name.


Validate Code Signing Root Certificate Offline

First, you need to ask Windows to validate the signature on the EXE. Your DLL can do this using the WinVerifyTrust() API, and Microsoft provide example code for doing this here.

That will tell you that the Windows you're running on is happy with the signature on the EXE. A maliciously configured machine could have an EXE signed with a self-issued certificate that had been installed on the machine, so this doesn't fulfil all your requirements, but it does it least force the opponent to do his job thoroughly.

Then, to check on the certificates, use CertGetCertificateChain(), followed by CertVerifyCertificateChainPolicy(). You can ask these functions to check for revocation, and do several other kinds of check: it's worth reading their documentation closely. There's an example program here.

Through these APIs, you can get the CERT_INFO structures for the certificates in the appropriate chain, and can check those however you like.

If you know which certificates could have been used to make valid signatures, the strongest check is to get the public keys from the certificates in the chain and check them against the public keys of the known certificates.

There is a counter to this check, if the opponent is smart, which is to edit your DLL to change the public keys stored in it to the ones the opponent is using. So you have to hide those public keys, by encrypting them, spreading their bits out over a larger piece of data, or similar tricks. Most software copy-protection comes down to trying to hide data from an opponent while still making use of it, and this is no exception. A sufficiently persistent opponent will always win this battle; your task is to make it sufficiently difficult that they give up before solving the problem.


How to estimate the time for a hacker to crack a strong password

It's not possible to answer how long it will take to crack a password without knowing how the password is created. If you create a password based on your (or a relative's) birthday, street address, middle name, etc it is assumed to be a week password due to Kerckhoffs's principle. Since you don't know if an attacker will know this information, it's best to assume that they will, and that they know the format you decided to use.

For the sake of demonstration, let's assume they don't know anything about your family, but they know you've formatted your password as My[B0y or G1rl][day of month with suffix][abbreviated month][symbols on keyboard corresponding to year]. That's 2 possibilities for boy or girl, 365.25 for month and day, and let's be generous and say 50 for year. 2 * 365.25 * 50 = 36,525. That's nothing. An attacker could try hundreds of similar methods without having to do a significant number of hashes.

The only way to reliably estimate password strength is by basing the estimate on the password generation method. If your password generation method is to generate 10 random alphanumeric characters, you'll be randomly picking 1 password from a set of 6210 passwords. On average, an attacker will guess your password after trying half of the possible passwords, so unless they get extremely lucky they'll have to guess around 6210/2 = 419649682934170112 times before they guess yours (of course this could be higher or lower if they're lucky).

This 8x GTX 1080 benchmark has been floating around for a while, if we assume that's what an attacker uses, they can do 200 billion md5 hashes or 826 bcrypt* hashes per second. If you're worried they have a room full of ASICs, take that times a billion (although bcrypt is somewhat resistant to ASICs). Worst case scenario with bcrypt is 6210 / 2 / 826000000000 = 508050 seconds, which is only a few days, but as far as I know bcrypt ASICs are still unlikely to exist (or be that fast if they do exist). Of course, you could easily make this much better by using 12 or 15 random characters instead of 10.

*Assuming a cost of 12; the benchmark gives 105.7 kH/s with cost 5, so 105700/2^(12-5) ≈ 826 H/s.


Is Hydra splitting the wordlist file into as many parts as tasks / threads?

I found the answer.

Hydra is, I think, doing a modulo [number of tasks] to create each "subfile" that are processed in parallel. Why that ? Because it's 99% the same sequence of passwords test, I mean they are processed in the same order.

ie : Password number 1 will be tested as number 1 launching 16 tasks, password number 2000 will be tested in 2000th position as well in the 16 tasks hydra processing.

It also means the thread/task 1 will process password 1, 17, 33, 49...

Thread/task 2 will process password 2, 18, 34, 50... and so on.

And of course passwords are processed sequentially, ie in the same order, if you launch hydra with only 1 task.

I tested it on 8k passwords and it's almost all the time the same order in both cases, with very little variation sometimes.


Local server applications using a web frontend on multi-user desktop environments

I don't have a good answer, but I note that the question does not mention container technology as a potential isolation mechanism to explore.

I would encourage that exploration. The container ecosystem has enormous momentum, thousands of engineers across hundreds of companies, containerizing all the things. There is no reason in principle that it would not be a perfect solution for this problem.

A production quality solution might not be available at the present moment, but I have already seen on several occasions the kubernetes ecosystem deliver a solution from a standing start before an org that needed the solution was able to get out of a planning process to ramp up on its own.

Quick googling on this finds a POC:

https://www.researchgate.net/publication/314070005_GUIdock-VNC_Using_a_graphical_desktop_sharing_system_to_provide_a_browser-based_interface_for_containerized_software

I don't believe the k8s machinery at present supports vnc, but I remember seeing ports of the vnc protocol to web sockets, which is directly servable from k8s cluster.

Hopefully someone with direct knowledge of the state of play here will chime in.


Android app permission warning: how serious?

Androids permission model up to lollipop is flawed in the sense of usability, and they are moving towards context driven permission request model. Let us review the current situation again:

You as a normal user are looking for an application and after searching the google play, you finally find it.
As happy as you can be you click install, and then there are random pages asking for things like EULA, permissions, installation mode, (random stuff huh?) we're used to clicking next, next, finish until the application's installed. (Seriously, No one ever reads those pages!)
Once you look back, you realize that the application asked for 2 pages worth of permissions and you allowed it while you were excited about trying it out.

OR

You may be a security conscious user (just like all of us) who cares about these things, You do see the application is asking for access to your SMS and GPS and Contacts while its functionality is as simple as a 4 digit calculator. Is there something you can do about it? NO!!!

You either have to forget about the application or just give it all the permissions.

If you haven't seen yet how this model is wrong, let me make it clear.

You are installing the application and want to try it out so naturally you want to get everything out of your way to achieve this goal.
You haven't installed the application yet so you don't really know what features it has and what permissions it may need.

This is not the best time to ask you to give it permissions.

Up to Lollipop:

  Google Play’s permission details screen will tell you everything an app may request access to. It won’t really tell you why an app may want to access something, though.

But in Marshmallow

  Apps designed for Android Marshmallow will ask you for permission the first time it wants to access something.

The more Usable implementation is to ask you to give permissions while the feature is being used. Suppose you open the skype application, try to start call and it asks you for microphone permission...seems right. Then you want to switch to a video call and it asks you for camera access.

Now if an application asks you for access to the camera out of nowhere you can decline it. And also if you're worried about skype capturing your video while its not running in the foreground you can revoke this permission and give it back when you want to make a call.

I refer you to Scott Hanselman's AWESOME Podcast with Google's Adrienne Porter Felt about Designing Usable Security at (13:00) she talks about android permission model.

  A good end goal would be for people not have to think about security in order to remain secure.

tl;dr

The model is flawed, switch to another platform, wait for it to get fixed but meanwhile my personal advice is:

Don't do your banking and other critical stuff on a device where a lot of random applications are installed.
Cancel the installation if the application is not from "well known" publishers and is asking for permissions you think it doesn't need or is too much.
If possible, contact the publisher and ask for clarifications about their applications permissions.


An adequate message authentication code for REST

If you use SSL for transport, and do it properly, then any extra MAC is redundant; and, when it comes to it, so is SCRAM. A selling point of SCRAM is that it is supposed to resist situations where SSL is used improperly, i.e. without appropriate server authentication (unfortunately, it happens). But the security argument of SCRAM is rather weak in such a situation, because it will not prevent a man-in-the-middle attack; and, without a MitM, the basic plain-password-within-SSL is already good. The only advantage of SCRAM over a plain password is that in case of a MitM, the attacker does not learn the password right away. He still sees all the exchanged data, and can insert commands of his own, and he obtains enough data to perform an offline dictionary attack, something that very few passwords come through unscathed.

In your proposal for adding a MAC, you do not say where the MAC key comes from. This is critical. A MAC has any value only as long as the key is unknown to the attacker. But if the client and the server already share a key which is unknown to the attacker, why would they even bother with a password and SCRAM ? Let them use Pre-Shared Key TLS, i.e. SSL/TLS with the shared key as basis for mutual authentication and encryption: no certificate at all (so no certificate validation to get wrong), slick and fast operation.

Even better, if the client and server share a password, don't want to use certificates, fear offline dictionary attacks, and don't want the server to store the passwords as is, then the solution is TLS-SRP. Client and server authenticate each other relatively to a common password, the server does not store the password but only a hash-equivalent of it, and the password is safe from offline dictionary attacks, even in case of a MitM attempt (not only is the attempt thwarted, but the attacker does not even gain enough data to "try passwords at home").

The SCRAM designers were probably told about SRP at some point, because they added in section 9 of the specification the following paragraph:

  Authentication mechanisms that protect against this attack are
     available (e.g., the EKE class of mechanisms).  RFC 2945 [RFC2945] is
     an example of such technology.  The WG elected not to use EKE like
     mechanisms as a basis for SCRAM.

They give no justification whatsoever of why they reject PAKE protocols (which they improperly call "EKE", which is only the name of the first known PAKE protocol).