Encrypt DB Fields preserving search functionality I would like to protect sensitive information stored on a Postgresql database, but I would not like to encrypt it all. The idea is to encrypt only those fields which hold sensitive information. I was thinking on using AES 256 to store the data, and I've read some posts here with some insights and recommendations about this topic.

The problem is, AES with CBC generates a different ciphertext for the same plaintext (provided the IV is different everytime) so I lose the ability to search on those fields. One of those fields is the person ID number, which is used on our webapp to search for a person's data. What I would like to implement in our app is that when the request comes from a user to search for a person with id '123', the app encrypts 123 and searches for the encrypted value (hex-encoded) in the database. Note that the ID field is not a primary key in the table.

However I read that providing the same IV for AES is not a good idea. Is there any cipher suite I can use that produces the same ciphertext given the same plaintext, and offers a good level of security against cracking? Or is it OK to use AES 256 CBC with the same IV to produce the same ciphertext in this scenario?

One of the posts I read suggested adding a new field to the table to store the hash of the plaintext for searching. While this is a good idea, I prefer to keep my tables without changes because we want to use the same persistence beans for encrypted and unencrypted databases.

What I'm trying to prevent is DBAs seeing sensitive person data performing selects on tables (the database is not under our control).

Any advice is greatly appreciated!

References:

https://stackoverflow.com/questions/1220751/how-to-choose-an-aes-encryption-mode-cbc-ecb-ctr-ocb-cfb
Indexing encrypted data for efficient searching
Least insecure way to encrypt a field in the database so that it can still be included in queries

I would actually not advise encrypting something like a user id. There should be practically no risk to anyone seeing it and you're really making a lot more work for yourself than necessary. An id identifying a user is not what I imagine a lot of people are going to call "sensitive information".

I'm actually having a hard time trying to think of a case of sensitive information that you would like to use a WHERE clause on in SELECT. I wouldn't never want to search against SSNs, for example.

If you wanted to compare user input against something like an SSN there's generally other information such as name and DOB that's entered alongside the SSN. I would pull all records out into an array with that match that information (name, dob) and then check any resultant entries with the SSN provided and the SSN from the entry, decrypted.


Ransomware/Virus/Malware - modern protection(s) Just found this on GitHub:
https://github.com/gnxbr/Fully-Undetectable-Techniques/tree/main/minizinh0-FUD
I can imagine similar ransomware, malware, viruses exist.
AV is useless?
Is only Behavior Analytics the way to go?
I can imagine you can implement several layers of security to catch it (i.e HTTP inspection when malware, ransomware, virus, if ever, calls home etc, this would require a nice database of bad IPs)
What other protections are there against Ransomware, Virus, Malware in Windows Environment mostly?
What would you implement, obtain in a Small to Medium Business? Open Source solutions would be great.

Anti-Virus never offers 100% protection
This statistic claims that AV software is able to stop about 25% of all attacks. That can be seen as a positive thing (25% less stuff I have to worry about) or a negative thing (75% still going through).
Common sense, however, is 99% effective. Not opening e-mail attachments from strangers, downloading shady files from shady sites, etc. reduces the risk of compromise drastically.
Behavior Analysis isn't 100% perfect either
There is a set of actions that AV software classifies as "malicious", and a set of actions users would like to do in order to do their job. Unfortunately, these two overlap a little, and so AV software has the task at determining how strict to be.
Too strict, and users will complain that AV software is preventing them from doing their job - which then results in the AV software either being tuned to being less strict, or the AV software being removed entirely.
Too permissive, and malware can disguise itself as a user doing user tasks, as is described in the GitHub repository you linked to.
The idea of Behavior Analysis isn't to offer 100% protection, but to complement matching of known malware. This is already implemented in top-of-the-line AV software. In other words, even with Behavior Analysis, the success rate is only 25%.
Protections against Malware
There are many approaches, and they're usually together. Generally, you want to prevent malware from getting to your devices, rather than trying to stop it once it's already there. In order to do that, known infection vectors are either prevented or made more difficult.
One way that malware can infect a machine is through exploiting known vulnerabilities in the software and operating system. The solution for that is centralized patch management, meaning that the OS and software is always kept up-to-date and known vulnerabilities are patched as soon as possible.
Another way for malware to infect a machine is via phishing. Phishing can be countered by awareness campaigns, as well as spam filters. For example, an e-Mail prefixed with !!! THIS EMAIL ORIGINATES FROM OUTSIDE YOUR ORGANIZATION !!! is more likely to cause alarm when it's supposedly coming from your CFO on a Friday afternoon.
Of course, there are many other infection vectors, but this should give you an overview.


Is this API Token scheme secure enough I am designing a REST Api for a mobile application and have some worries over properly securing access to accounts.

I am writing the API server in nodeJS and it will primarily be consumed by a mobile client (although a web client may be added in the future)

There are 2 main side aspects I wish to incorporate in the auth process:

Users ID is encoded in the token (to reduce stress on DB)
User can have only 1 valid token at any one time (login nulls any previous token)

Here is my initial design (all endpoints are over SSL):

Login

User POST's her username & password to '/login'
Server verifies users exists and the password matches the bcrypt hash in the Db
Server generates a uuid v4  for the user and stores this in Reds with the users ID as the key
The users uuid and user ID are then encoded in a Json Web Token with an expiration time of 1 week
The JWT is then sent back to the users as their authentication Token

Protected Route

User sends GET request '/users/me' withe her token set as Authorization: Bearer  header
Server verifies the JWT and sends appropriate error responses if verification fails
Server then queries the Redis store and verifies the uuid stored for the user matches the uuid encoded in the JWT
If uuids match the users id is set to req.user and the request is processed, if not then error message is sent back

Does this look like a good authentication strategy or am I way off?

I find two possible flaws.

UUIDs in general do not guarantee to be cryptographic random. Depending on implementation it may be possible to give a qualified guess about what other UUIDs have been generated by a generator, given some of the output. You need to use a suitable length of output from a cryptographic random number generator as session token.

Whenever you extend to a web client you need to secure against cross site request forgery, that is, any request that change data on the server needs to have a token that is not a cookie as part of the request, otherwise the request can come from another open web site on the users computer.

Another thing, if you want to reduce stress on the DB, you can store session information in process memory in Node. You only need the database for things that has to persist through a crash.


"muieblackcat" is a vulnerability scanner which searches for misconfigured webservers. It tried different common install paths for phpMyAdmin, all of them returned a 404, meaning you're safe.

The last log entry comes from Apache, which sometimes polls its own child processes to check if they're still working correctly.

The first and the second entry log seem like normal traffic to me.


How to securely share sensitive info (such as API keys) with freelancers? My business partner and I are building a webapplication. We have partnered with some third party services which make use of API (public and secret) keys.

The freelance developer we worked with required the keys to implement these services. Unfortunately the relationship with this freelancer took a turn for the worst and he is now blackmailing us by threatening to share those keys.

My business partner is a marketeer and I am a UI designer so we know little to nothing about this topic. How can we prevent a situation like this in the near future?

We'd like to be able to share sensitive resources such as API keys with confidence and with little risk.

P.s. we've already asked our partners for new keys.

The exact procedure you follow will necessarily change depending on the service you use. However, there are some common precautions you can take:

Switch to services that have robust, featureful key systems. Strictly from a security point of view, if it doesn't support all of the rest of the items in this list, you should look for alternatives. (Obviously, business needs and your abilities also need to be taken into account -- but only you can do that)
Follow the principle of least privilege -- when generating keys for the freelancer, ensure they have the minimum amount of permission required for them to do their job.
Make sure keys can be revoked quickly and automatically, with no human intervention required on the service's side. This allows you to react to bad actors. In this case, if you can easily revoke the freelancer's keys, they no longer have anything to hold over your head, just a meaningless string of bits.
Give the freelancer unique keys, so that you don't need to rotate all your keys just to revoke the one person's access.
Always have a second access method which can't be revoked by the freelancer for yourself/your business partner, so that they can't steal your account and hold that as blackmail.
Give the freelancer a test area to develop in, rather than having them work directly on the production server. Not only does this isolate their access to prevent damage, but it also prevents stupid mistakes from (however briefly) taking down your entire site -- if changes can be tested and demoed in a test environment, you'll have more confidence that they work before they're deployed to your customers.

Less directly, you should also keep regular offsite backups that freelancers don't get access to. That way, even if something is compromised, you can roll back to a non-compromised state easily.

Ultimately, you're necessarily giving someone in-depth access to large parts of your project. There's no way to do that absolutely safely, and what measures you can take depend on what the keys are used for.


How do you know if blowfish key is correct? Encryption novice here so maybe this question makes no sense...
Obviously if you know what the clear text is and it decrypts right, you have it.  But if someone is running through keys to break the encryption how do they know they have it right?  Would you have to check for readable text or can you tell from the math that you have it right?  Like the remainder always equals 0 or something.

Blowfish is a block cipher and block ciphers in ECB or CBC require that the length
is a multiple of the block size. If this is not the case the last block is padded. There exists several methods for padding. The point is, if the decryption does not result in a correct padding you know that you have decrypted the ciphertext with the wrong key.

You can also analyze the decrypted plaintext with randomness tests. The plaintext of a correctly decrypted ciphertext usually contains much less randomness compared to a plaintext decrypted with a wrong key. If you expect the plaintext to contain

Recently a research project has been announced which is called Honey Encryption. It will be presented at the Eurocrypt conference in Copenhagen this year. The idea is that when encrypted data is decrypted with the wrong key the plaintext that is produced by the decryption algorithm looks plausible. An attacker cannot distinguish between an incorrect but plausible looking plaintext and the correct plaintext. The disadvantage of this approach is that it doesn't seem to work with all plaintexts. It was primarily designed to be used to encrypt credit card numbers or passwords.


Should I buy nonsense domains just to make sure my clients don't visit a misspelled domain? I have my new website to be published (it's called buysteel.com). I will have thousands of clients visiting my site every month, and I would like to protect them around and at the site. Is it worth buying nonsense domains that just have the function to redirect them to the right domain?

For example I could buy these domains also:

buyssteel.com
buyysteel.com
buysteeel.com

Only you can decide whether or not it's worth it. There are a few situations that you should consider:

How does your typical user visits your site? Are they primarily visiting because you gave them physical business cards or adverts where they have to type your domain manually? Then you should register and redirect all common typo domains to your main domain. Are your users primarily visiting you from online adverts or search engine? Then you probably don't need to worry much about typo domains.
Are you aware of overseas businesses in similar industry that have similar sounding names that might one day expand to your country? Then you might want to consider purchasing their domain name to protect your own trademark.
Are you using a country specific TLD? Are you not on the .com.xx of your country's TLD? Are your main domain on a novelty TLD? Then you might want to consider purchasing the .com version of that domain name, in case you have users that thinks that every website ends with .com, or if they tried to use Ctrl+Enter on the URL bar.
Are there other countries that your business might plan to expand to in the near future? Then buying your name under that country's TLD might be something you might want to consider.
Does your main domain names consist of common, regular words in the language in your primary audience? Is there common, similar sounding/similarly typed words or synonyms that your audience might misremember your name as? Does your name consist of unusual words?

One thing you definitely want to do to set a budget limit on your domain purchases. The number of you would have to have for this kind of typosquatting are endless. There are endless variety of permutations and you cannot purchase every single permutation of typos and similar names unless you have endless budget, which I assume you don't. So you'll need to set priority of what matters to you most. Domain names aren't that expensive, but they do cost quite a bit, and you need to renew them every year or so. If you're a smaller business, holding 500 typo domains are going to eat into a good chunk of your revenue. If you are Google, these expenses are negligible.

How much are you willing to spend to hold an asset that don't actually make you any money, for a situation that probably won't matter much even if it happens. Do you have other ways you could better spend the money? That $100/year you spend on squatting might be better spent on upgrading to a higher tier server or to buy a CDN service to help improve that performance issue that you've been having.


Why different key exhange techniques for ssl key exchange? During ssl key exchange, I have read that sending the symmetric key to the server encrypted with the server's public key is an old technique. Now for key echange Diffie hellman and other techniques are used.
My question is why is key echange using the seerver's public key outdated? What are it's shortcomings?

The distinction is not so much a matter between Diffie-Hellman and RSA key exchange generally, rather it's about being able to use Ephemeral Diffie-Hellman, which use ephemeral (i.e. new) parameter every time. (It's also possible to use fixed DH parameters, but I'm not sure I've ever seen it.)

Essentially, if you record the encrypted traffic and later on get hold of the server's private key, an RSA cipher suite, you can later on decipher the entire traffic straight away (e.g. using Wireshark's SSL tools).

In contrast, using EDH, new random DH keys are (or should be) generated every time on each side. Those parameters are not recorded and not visible on the wire, which provides Perfect Forward Secrecy (PFS). This is why deciphering EDH cipher suites are not supported in Wireshark. Reasonably recent versions of Wireshark can decipher traffic that uses EDH cipher suites, but you need to get hold of the pre-master secret (every time). (See "Using the (Pre)-Master-Secret" section of the Wireshark SSL wiki page and this question here.)

(Whether it's actually perfect is not clear, but it adds another random space that an attacker may have to brute force.)

You can find more details in this RSA Security Inc. document or at the end of this section of the TLS specification.


Extensions for SSL server certificate I have some question about the X.509 v3 extensions. What extensions should appear in a proper certificate for a SSL server ?

No extension is strictly necessary in the SSL server certificate, but some extensions can only help:

An Authority Key Identifier extension will help clients link the certificate with the issuing CA.
A CRL Distribution Points extension (non critical) should be used to point to the URL where the CRL should be found.
An Authority Information Access extension can be used to include a pointer (URL) to the certificate for the issuing CA itself; the same extension can point to an OCSP responder, if applicable.
If a Key Usage extension is used, it should include some flags: keyAgreement and keyEncipherment for RSA keys to use with TLS_RSA_* cipher suites, digitalSignature for RSA and DSA keys to use with the TLS_DHE_* cipher suites (there is some confusion about whether keyAgreement or keyEncipherment should be used in the case of RSA-based key exchange, so it is safest to include both flags).
If you have a formally defined certificate policy, have a pointer to it (OID + download URL) included in all certificates in the path, or at least the SSL server certificate itself: it will give you some legal protection, should disputes arise.
The Subject Alt Name extension should be used to indicate the SSL server name. In the absence of such an extension, all browsers will fallback to the CN component of the subjectDN, but this extension is still nominally "preferred" (see RFC 2818 for details).

Of course, all these extensions are supposed to be enforced by the issuing CA, so if you already have the CA, there should be no extra question here.

If in doubt, consult the Internet X.509 PKI Profile. The profile defines what you should morally follow. If you fully conform to it, your certificates will work everywhere. Browsers are actually much more lenient than that.


What is the difference between Exploit and Payload? In computer security, we know that weak points in software are called vulnerabilities (if related to security). And once the vulnerability is found, theoretically it requires a piece of code as proof of concept (this is called an exploit). In this context, the term payload is also mentioned.

Then, what is the difference between 'payload' and 'exploit'?

The exploit is what delivers the payload.
Take a missile as an analogy. You have the rocket and fuel and everything else in the rocket, and then you have the warhead that does the actual damage. Without the warhead, the missile doesn't do very much when it hits. Additionally, a warhead isn't much use if it goes off in your bunker without a rocket delivering it.

The delivery system(missile) is the exploit and the payload (warhead) is the code that actually does something.

Exploits give you the ability to 'pop a shell/run your payload code'.

Example payloads are things like Trojans/RATs, keyloggers, reverse shells etc.

Payloads are only referred to when code execution is possible and not when using things like denial of service exploits.


Hashing a password, and summing it with every byte in a file. How secure? I have a text document with all my usernames and passwords in it sitting on my desktop. I decided to spend a couple hours making that more secure. I wrote a program for the purpose. It takes a password and a file, SHA-512s the password and adds each byte of it to the file in 64 byte chunks. It subtracts to decrypt. I realise that this falls apart if two hashes sum to 256 for every byte and that this is also only brute-forceable if you know what to expect. Are there any other security flaws?

this is only brute-forceable if you know what to expect

Stop right there. What you're describing is security through obscurity. You're betting that an attacker won't be able to know or guess your scheme. This is a really, really, really terrible assumption. It's an alluring one, but time and again it's been proven wrong. Any proper security scheme must work even if the attacker knows the system you're using; an attacker who knows everything but your password should not be able to practically attack the system.

So, throwing out the assumption that an attacker doesn't know your scheme: The security is frankly terrible. First, it's very simple for an attacker who learns part of the plaintext to use that to recover other parts, because you add the same thing to each 64-byte chunks. An attacker who gets one password of yours can see what having it in one section of the ciphertext means; specifically, if they assume it's at position X, they can subtract it from the ciphertext and get a potential part of the keystream, then try that keystream elsewhere.

Second, your program is quite vulnerable to brute-force. SHA-512 is an extremely fast hash. Fast hashes are great, in general -- they mean your crypto is faster, which means you have less overhead, which means you're more likely to be able to use crypto everywhere with acceptable performances. But they're terrible for passwords, because passwords are almost invariably low-entropy. With SHA-512, an attacker who recovers the file can brute-force passwords extremely quickly. Hashes used for passwords need to be slow: the thing you're hashing is low-entropy, so your hash must take a while to run to make this slower. A GPU can compute millions of SHA-512 hashes per second; doing your decryption is also fast, so this is not suitable to resist brute-force.

You should not use this scheme. Rather, you should use proper cryptography. If you were to build it yourself, this would look like an actual secure cipher (e.g. AES in an appropriate mode), with the key derived with a slow function (e.g. PBKDF2). Can your scheme work? Well, if your password is very high-entropy, possibly -- at the extreme level, if your password is a 128-bit truly random string, you may as well use that directly as the key to AES. But your password is likely weaker than you think, so you should just use a slow hash.

However, you should not do that either. Cryptography is really hard to implement properly. Where possible, you should use well-tested secure systems instead of coding something yourself. For instance, you could use GPG to encrypt the file; you could also use a password management tool (I'm pretty sure there exist such tools that don't even store encrypted data on the cloud, but are entirely local). Don't implement your own system except for practice; if you do, don't use the scheme described here.

Looking at your other question, you seem to still think you can effectively hide your scheme from an attacker and rely on "no, they won't figure out what I'm doing." So, here's something beyond the (fully sufficient) "security by obscurity isn't effective:" The only reason to care about an attacker decrypting your file is that they already have the file. That means you failed to keep a file on your computer secure. Your program is also a file on your computer. Why assume you can keep that secure, even if the file containing the passwords isn't?


Against what scenarios should I backup my database? I'm building a website with very sensitive data stored in my database. Losing any of it is not an option, and that's why I'm thinking to do an incremental backup every hour or so. I work on it alone, so I use only one database super-user (am I wrong?). However, I'm not sure even how my database could be damaged. Let's assume that from SQL Injection i'm 100% safe, and that DELETE/UPDATE queries are never performed (that is, by me). So, what else should I worry from?
I need to know because I couldn't find explanation, and because only then I'd know if I should backup off-site or on the same server, because if the only option is that my server itself is hacked somehow, what point would it be in saving another backup on it?

Short answer: hardware failure, programming error, operator error, malevolent actor (all sorts of attacks and "hacking").

Slightly longer answer:
The moment you care about your data (anytime other than a testing environment), you should backup your database regularly and keep the backups in a safe location (not the same machine, maybe not even the same datacenter if you want resiliency in the face of network outages). Also be careful to not overwrite your backups with new ones, you don't want to propagate bad data into your backups.

Once you've done all that, you need monitoring that your backups happened properly, verification of your backups, and recovery testing (where you try to restore your backups to make sure your process works).

Hacking is kind of the least of your concerns, the most common problems are programmer/operator error and hardware failure.


Pre / post disk encryption wipe? When dealing with full disk encryption a lot of utilities I've worked with will provide the option to fill the disk with random data to make distinguishing the encrypted contents harder to identify.

I've always wondered why do this when the process is extremely slow and often time requires that the system not be powered in to the main OS?

My leaning has always been to leave that option off and then use a free space shredding utility within the OS. Sometimes one that finishes by zeroing out the disk, other times with random contents.

Is there some kind of benefit to the pre encryption wipe that I'm not seeing? It doesn't seem that the overhead is worth it?

There are two distinct reasons why a disk encryption might fill the storage area with random data.

If you're encrypting in place, or more generally if there's a chance that the storage area contains plaintext data that you don't want to expose, then the existing data needs to be wiped, otherwise traces of old data may remain in space that hasn't been overwritten by encrypted data yet.

Wiping with zeroes is enough against all attacks that don't use specialized hardware such as an electron microscope. Wiping with zeroes is enough even against all published attacks with specialized hardware for most storage media. In the 1990s, Peter Gutmann demonstrated that data could be recovered to some extent after overwriting it with zeroes, due to magnetic remanence. The effect is rather small and each bit has an independent chance of not being recovered correctly, so it's difficult to recover data, but theoretically possible, leading to the recommendation of random overwrites.
In any case, the remanence effect is so small on contemporary hard disks that overwriting with zeroes is good enough.. For EEPROM, but not other flash technologies, I've seen recommendations to overwrite with multiple passes of random data. For NAND or NOR flash, overwriting with zeroes is good enough.

To put it simply, overwriting with random data instead of zeroes is useless paranoia in almost all cases where it's used.

There's a different reason to fill the disk space with random data, which is if you consider the size of the encrypted data to be confidential. Encrypted data is indistinguishable from random data if you don't have the key. Therefore, in a disk filled with random-looking data, it's impossible to tell which bits are random and which are encrypted. This is only a very small privacy concern since revealing how much disk space is free is rarely a concern.

If you want to start storing data before wiping, it's more complicated: the wiping tool and the disk encryption tool have to know which area they can use and which area is the domain of the other guy. Also, if you were relying on the free space being wiped or randomized, then your disk does not meet your security requirements until the free space has been properly disposed, so you shouldn't be using it.

In summary, overwriting with random data is rarely useful. But if you do want it, you need to wait until it's done.


EMV Transactions vs Magnetic Stripe In Mag stripe transactions, I've worked on solutions by which you get an initial small value Authorization and then can capture a full amount later using the transaction_id. E.g. The payment gateways in restaurants.

With the move to chip and pin / EMV, is this still possible? I've stumbled into some vague articles implying that the future capture amount is now reduced to 20% etc. Can someone point me to some correct information?

EMV has no effect on the rules for capture amounts.  It's only an authorization-time feature.  There are things you can do with swipe cards that you can't with a chip, but your specific example isn't one of them.  For example, you can't display one total on the device and then authorize a different total, such as when the card is swiped while still ringing up the transaction. 1.
For transactions where the capture/settlement amount is different from the authorization amount, those rules are set by the card brands and are more dependent on industry and type of the transaction than how the card is presented.
For example, Visa's says:

A Merchant must submit an Authorization Request for either:

The final Transaction amount
A different amount or amounts if the final Transaction amount is not known, and the Merchant or
Transaction type is included in and complies with Table 5-13, Special Authorization Request
Allowances and Requirements

Table 5-13 starts on page 370 and runs for the next six pages, so there's a lot of special cases.  But if you aren't one of them, then Visa can fine you if you change the amount, regardless of swipe or chip.

1 Actually, you can, but the bank can see it and is likely to decline.  Except in the US where the banks specifically don't care, and in fact encourage this.  See QuickChip, for example.


If I'm the owner of VPN network, what can my ISP see? I'm planning to build small VPN network, so that me and my customers can connect and use it. But from my understanding, if I use my own VPN network, still my ISP can see the traffic, am I right?

Here is a simple diagram, what I have in my mind:

To protect myself (against MITM) while I'm connected to public WiFi, this is more reasonable.

But my concern here is ISP, if they are able to see all of my traffic, then I have to search for another solution. (for example using VPN from another provider will solve that problem).

The ISP sees everything as it is, the connection is only safe between you and the VPN. As you mentioned, this VPN allows you to browse on insecure networks, public wifi hotspots with safety, defends against eavesdropping and MITM, so still good to have.

There are no other solutions. If you try to communicate with a website with or without VPN that only supports HTTP, the transferred data will still be unencrypted. It's the matter of between who.


How to get site's 'real' URL (before being rewritten) If a site uses .htaccess file to rewrite the URL for e.g. better SEO. Is it possible to find out what is the "real" URL?

I'm not sure what your question is.  Let's say you have a simple rewrite rule like to redirect content from http://www.example.com/old.html to http://www.example.com/descriptive-directory/new.html something like:

RewriteRule ^old.html$ http://www.example.com/descriptive-directory/new.html [R=301,L]

Then a user's web browser sends a GET http request to http://www.example.com to fetch old.html:

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

The web server catches this in the rewrite rules, and sends back a http response from the server like:

HTTP/1.1 301 Moved Permanently
Location: http://www.example.com/descriptive-directory/new.html

and then your browser fetches whatever content is at http://www.example.com/descriptive-directory/new.html as if you had originally type in the rewritten url.

So what is your question?  You presumably know (and can easily log) the web addresses your browser has been requesting before it has been rewritten.  At the very least you can capture the GET requests by following the TCP stream with a tool like wireshark.

You know where the redirect rule has ultimately sent you; e.g., the location is now displayed in your web browser.  If you have access to the apache logs from the webserver side you'll see something like:

127.0.0.1 - - [2/Feb/2012:12:36:17 -0400] "GET /old.html HTTP/1.0" 301 315 "-" "Mozilla/5.0"
127.0.0.1 - - [2/Feb/2012:12:36:17 -0400] "GET /descriptive-directory/new.html HTTP/1.0" 200 1702 "-" "Mozilla/5.0"

though you could easily just look in the apache configuration to find the actual rewrite rules.

Note: none of this has anything to do with where the content is stored on the web server.  There may be no directory called descriptive-directory or files called new.html or old.html on the web server.  The entire http response from a request to http://www.example.com/descriptive-directory/new.html could be taken by the web server and then return a dynamically written html page.  E.g., the following simple webpy code can be executed to act as web server without any html files existing.

# call this file silly_website.py
import web
urls = (
    '/descriptive-directory/new.html', 'new',
    )
class new(object):
    def GET(self):
        return "<title>Hello</title>World! from new"

app = web.application(urls, globals())
if __name__ == '__main__':
    app.run()

which could be then run as python silly_website.py [your_ip] and you have a running webserver that will give back a very simple webpage for a request to /descriptive-directory/new.html.  As such there's no generic way of finding out where content returned from the web server is actually stored on the webserver (even in relation to the web server's root directory).


How to detect new device in Android? I'd like to notify my users if a login happens from a new device. Like Google does for Gmail logins. Android ID and IMEI usage for tracking is discouraged by google. How can I track devices without using hardware identifiers? What is the best way to track devices without violating users privacy?

From your description it seems that for your purposes, a persistent file in your app will be enough. You will get some 'false positives' when users wipe the app data, or uninstall your app and reinstall it later, but this should not be a big problem if it only results in a private mail notification, as for Google logins.


Listing of DNS vulnerabilities I am currently studying how to setup DNS servers and all aspects of the DNS system. I would also like to study the security aspect. I want to use current DNS server attack on my test servers. Is there one place that lists the current attacks that are used by hackers so I can learn how to prevent them?

I'm not sure that there's any single place that lists all of the vulnerabilities related to DNS, but here are some pointers you might use for further research.

General DNS Weaknesses

One broad category of DNS vulnerabilities would be at the protocol- and system-layer.

The wikipedia article on DNS lists security issues with the system.
A particular vulnerability is cache poisoning.
You can learn about DNSSEC as a countermeasure against some of the weaknesses in the protocol.
Here's a list of notes on DNS that point out several system-level weaknesses.
DNS is described in numerous RFCs. (That list is not up to date. You can find newer RFCs by looking at the references section in a recent DNS RFC.) Modern RFCs include a "Security Considerations" section that discusses security aspects related to the topic of the RFC.

Specific Vulnerabilities in DNS Implementations

Another broad category of vulnerabilities are bugs in specific implementations of DNS. There have been so many bugs in ISC Bind, for example, that this attack vector is much more likely to be successful than an attack at the system level (this depends on the target and the environment, though).

Search the National Vulnerabilities Database. (E.g. ISC Bind)
Search at SecurityFocus
Look for exploits in the exploit database.
Metasploit and various other scan tools may be able to automatically detect vulnerabilities on unpatched servers.

Complex Interactions

Studying DNS in a vacuum isn't really enough, though. DNS interacts with other protocols in interesting ways.

For example, if your network doesn't protect against rogue DHCP servers, it may be possible for an attacker to run a DHCP server that hands out a lease that points to a rogue DNS server. The DNS server then returns whatever addresses the attacker wants -- substituting his own address for paypal.com, or rerouting email, for example.


Need asymmetric encryption(not signing) where server encrypts and client decrypts So I'm trying to build a licensing server, where the licenses of the applications need to be checked when logging in or when the application gets used. But some of those application work offline most of the time, so I need to have some sort of 'caching' of the last check of the license with a date where the license should next be checked(let's say like every week). For the moment I'm storing this in the database of the application, but I need to make sure that that 'next check date' can't be changed by the user of the application.

So I came up with the following idea: When a license needs to get checked(because it has been more than a week), the server will check the license and will decide the 'next check date'. He will then encrypt that date and send it to the application which will store it in the database. Then when the application will be used, it will get that encrypted date, then decrypt it and check it. So when the application tries to encrypt a date himself, he won't be able to decrypt is because he doesn't use the same key that the server used to encrypt.

At first thought I came up with a private key on the server and public key on the application, but then it wouldn't be encryption but signing, and that would involve sending the date in clear text, which is not what I want. Or is there a way to use signing that the application can't change the date?

Despite your question title, you still want digital signatures, not encryption. You want something that the client can verify but not produce by itself; this is exactly what signatures are about. Trying to think about it in terms of encryption will only lead to more confusion.

The basic working of a license file is that it contains some vendor-chosen information that the vendor signed; the client uses the vendor public key to verify that the license file is genuine, then applies whatever policy is incarnated by the information in the license file. Typically, a license file would identify the customer and the allowed range of usage dates, possibly along with a unique identifier for the machine on which the software may run. The client code will then refuse to work if the current date is not in the allowed range, or if the local machine identifier does not match that what was specified in the license file.

As was pointed out, licensing can always be defeated in the case of software, because the code that enforces the license policy runs on the user's machine. If the user wants to bypass the license, he can reverse-engineer the code to simply deactivate the license check; this is about as impossible to prevent as music and video copying. Changing the local clock is the simplest form of "reverse-engineering", and even users with very little knowledge of programming can do that. If you want to enforce usage rules and licensing, then make it so that part of the code runs on your servers, not on the user's machine (but then, the software is no longer usable when offline).


Are there Ciphers designed to be slow? To safely store a passwords, it is better to store them hashed using a hashing function designed to be slow like bcrypt. The goal is to trump brute force attacks.

Are there any ciphers slow enough to prevent brute force attacks? I am especially interested about SSH private key storage. Would a brute force attack work if my passphrase is as small as 8 characters?

Most encryption algorithms are already comparatively slow and judging success is also much more difficult.  When you are trying to determine the input for a hash, you know the desired output.  When you are trying to crack encryption however, you don't generally know the desired plaintext, even if you do, the potential input space is generally much, much, much larger.

Each digit of a password is only worth about 7 bits of entropy, even if ideally randomly chosen.  Even the low end of a standard symmetric key generally uses 128 bits of entropy.  The speed of hashing wouldn't matter much if everyone used truly random 18 character passwords. Plus, the plain text you need to reach is generally unknown to the attacker and encryption algorithms generally operate a bit slower anyway since they have to do more complicated operations on a longer set of data.

So, in a sense, no, there aren't algorithms designed to specifically be slow as a design goal, but they don't need to be as the level of security provided and the normal speed of the algorithm doesn't need to be slowed to be practical.  A brute force attack against a well chosen key on a 128 bit encryption algorithm with no systematic vulnerabilities would already take longer than our sun will be burning, to say nothing of 256 bit keys (which would not be done on current hardware before the heat death of the universe).  Going slower simply isn't necessary.

If you were to use a key derivation function for a password derived key, that would need to be slow, but you wouldn't want to make the decryption itself slow as that would be inefficient.

As for SSH private key storage, it would depend entirely on the implementation of the key derivation function, not the speed of the encryption algorithm, but I'd suggest probably at least 10 characters if you want it to strongly resist brute forcing even for a reasonably slow key derivation (I'm not sure what SSH private key storage uses, and it may vary by client.)


How to identify compromised SIM Cards? Reason for this question:

This article regarding NSA / GCHQ SIM Hacking) states some manufacturers of SIM-Card have been hacked to steal SIM-Card "Ki". I want to know the likelihood of the SIM-Cards I deal with being compromised.

Is it possible for me to identify the manufacturer of a given SIM Card?
If yes: How?

EDIT:

Someone mentioned the text printed on the SIM-Card:

Is there any way to identify the Manufacturer if these markings are gone because the Card was cropped to fit in a smaller socket?

I know that there is no such thing as absolute security even if the Cards i deal with are not from Gemalto. But i am still curious if the Cards i deal with are certainly compromised.

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

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

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

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

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


Modifying a SHA256 system to be ASIC resistant I am looking for a way to protect a system utilizing SHA256 on semi-weak passwords against brute force attacks using ASIC-levels of hash-power, ideally by designing a system that is ASIC resistant.
The following scenario is theoretical in nature, and is concluded as a question on how ASICs work at a hardware level.
Suppose I have a platform in which funds are protected by a 12 character password which is A-Z, a-z, 0-9
The hash used on the passwords is SHA256, and sufficient salt is used to prevent rainbow table attacks.
Suppose there are GPUs that can brute force SHA256 around 2000 MH/s and an attacker has an expensive stack of 100 of these GPUs. If the hash of a single password were leaked, it would take ~250 years on average for the attacker to find the password for the leaked hash.
Now, suppose ASICs start emerging for brute forcing SHA256 and can do so at around 100Th/s (similar to what we are seeing Bitcoin mining ASICs accomplish with Bitcoin's SHA256d), if one of these ASICs was then applied to my leaked salted hash, it would now take on average ~2 days to crack.
(Note: The main flaw here is that the passwords used by my platform are weak as they have to be 12 characters long, increasing the length would obviously solve this problem, but in my scenario the length must be 12 characters long)
I set out to devise a scheme that will be ASIC resistant, I propose we use a variable we will call 'sugar' which would be a bit of data added to the salted hash, which is then hashed again, e.g. SHA256(sugar+SHA256(salt+weakPassword)). The theory behind this is that, if an ASIC is built to brute force my platform, I can simply change the 'sugar' and now the entire ASIC is designed to brute force the old set up on a hardware level.
Would this work or am I misunderstanding how ASICs are built and it would be trivial for an ASIC to update the proposed 'sugar' variable?

A problem with SHA256 is that it's fast, which makes it possible to verify many possible passwords each second. A standard way to make a password hashing function slow is to perform many iterations of an underlying hash function. For example, PBKDF2 is more or less a loop of hash calculations. When performing 10,000 hash calculations for one password, cracking also becomes 10,000 times slower.
ASICs may be faster at computing hashes, but they differ from general computers in that they lack memory. Scrypt tries to take advantage of that, by requiring memory for the hash function. By requiring a couple of MB of memory, the hash is still easy to compute for computers, but it becomes harder and more expensive to implement that in ASICs.
Finally, I would recommend Argon2 as a password hash function. Another password hashing function such as bcrypt, scrypt or PBKDF2 are also fine. But hashing passwords with a single round of SHA256 is really not sufficient, especially if you are worried about attackers with custom hardware and unlimited budget.

I propose we use a variable we will call 'sugar' which would be a bit of data added to the salted hash

This is usually called a pepper, and I would say there is no consensus on whether using a pepper is a good idea from a security point of view.


John the Ripper / Hashcat rule, reject candidate if char at position X is the same as character at position Y I'm using John to generate some word lists and I'm trying to figure out the most optimized way to do the next step. What I want to do is add ever possible 3 digit number to a set where the first digit of the number is not the same as the first digit in the set

Set example 123ABC

to add

+ 213 = 123ABC213 OK

+ 131 = 123ABC131 REJECT

I see rules that reject unless a string includes, but not a comparison function like this.

I could make the whole list and prune it after with a python script, but it would be way bigger than needed.

Thank you!

You can make Hashcat output the list to stdout and pipe the output to a python script that filters it, then pipe the output to another instance of Hashcat (or John).

hashcat --stdout [list generation options] | python_filter | hashcat -a 0 -m HASH_TYPE HASH_FILE

I am not aware of rules in hashcat that would do this comparison, I hope this helps.


What is the reason for DMARC spec to not require specifically SPF or DKIM pass? DMARC produces "pass" result if and only if at least one of SPF and DKIM checks pass. It has been noted that DKIM provides stronger protection of the two (if implemented properly). But, in order to require namely DKIM passing by a DMARC policy, one needs to "disable" SPF (either by not publishing SPF records or by publishing an SPF record which disallows everything).

I do not understand the reason for such design of DMARC: there are two checks (SPF and DKIM), but there is no way to enforce a particular one of the two by the policy. It requires changing the other check itself.

What could be the reason for the DMARC specification to have no flags for specifically requiring either of (SPF, DKIM) to pass?

I did not find anything about this but I'm guessing that the arguments went the following way:

Both SPF and DKIM might break (forwarding, message transformation).
To increase robustness a domain should probably implement both anyway and hopefully only one will break then.
There are ways these mechanisms can accidentally fail, but there is no way for an attacker to deliberately make them falsely succeed.
Thus in the interest of robustness require only that at least one of these succeeds.

I very much doubt argument number 3 though. For a scenario where SPF might be tricked into returning Pass see this mailing list thread which actually contains a proposal to have something more strict than just SPF or DKIM. For ways to abuse DKIM by an attacker see this article (disclaimer: own research).


Is there a point to obfuscating form field values? Our company provides omnichannel (web, mobile, etc.) solutions for the banking industry.

One of our customers is pushing for obfuscating or encrypting the contents of the form fields (client-side, on the fly) in its HTML apps (ie. web banking), they argue that this prevents users from "seeing" the field values when inspecting the web page using Firebug and similar tools.

I cannot see or imagine a valid reason for this. Can anyone argue in favor of this?

I can absolutely see the value in this: if you are supplying sensitive information to the client-side that you hope the client never sees.

One used to see this when you had hidden form fields, like "sale_pct". If a user was able to see that field, they could modify the sale price, and potentially buy product at a negative price. Don't laugh. It happened.

The much, much, MUCH bigger question is why one would rely on obscurity on the client side at all. Don't send it to the client if you don't want them to see it. But maybe the business has a legitimate reason to rely on this ... I doubt it


Activesync: If I disable or rename the AD account does that mean the phone won't be wiped? Suppose an Activesync phone needs to be wiped because it was lost, stolen, or it was an employee termination.

If we disable the account prior to wiping the device (or the device receiving the wipe command) does that mean the device may not be erased?

My understanding is that the wipe is unrelated to the user account, as the phone itself is now tied to Exchange.


Feasibility of cracking a SHA256 of a UUIDv4 Given the UUIDv4 08ab4280-0043-4630-b4c7-a5393083546c which hashes to 27fd3a1ea8a58bd06cced89927fadffbb2f4815203723e5cd4ab18acbe37b659.

How feasible is it to crack a SHA256 of an unsalted UUIDv4? The lack of salt shouldn't be relevant given that we're already dealing with a random string.

Assuming the attacker knows that the secret is a UUIDv4 and that it's using lowercase alphabetical characters.

Assuming the UUIDv4 is generated with a CSPRNG (this is not guaranteed), it will have 122 bits of entropy. This is only 64 times easier than brute-forcing a 128 bit key, so it's still plenty far into the realm of impossible in our lifetime, even for a nation state (barring quantum computers fast enough to perform on the order of 261 hash operations with Grover's algorithm).


Cloud-specific standards and regulations Not specific to any particular industry or requirements, but in general - are there currently commonly accepted standards regarding cloud-based applications?

I* am developing a system that will be deployed in the "cloud" (i.e. hosted by an IaaS/PaaS provider, ala Amazon EC2).
Besides any regulation or standard that applies specifically to my application - is there any formulated set of guidelines (not just best practices) or regulations specific to cloud architecture that I should comply with?

This is irrelevant to the type or content of the application, I'm asking specifically about the cloud infrastructure configuration.

The main intent here is to comply with any expectations the (enterprise) customers may have. (For actual security we are not relying on the regulations...)

(*) Okay, it's not really me, it's my client, but close enough.

There are no Cloud-specific ones I am aware of, however you should definitely think about SoD:

Most Financial Audit regulations require Segregation of Duties (SoD), and generally these are relatively easy to manage in a traditional environment. In a virtualised environment (I'm looking at the wider scope of 'cloud' here) front and back office IT may end up being managed by the same individual or team, and may actually be on the same server, so when viewed from an audit perspective there is an increased risk of insider fraud. Regulations like Sarbanes-Oxley do require strict controls around segregation of duties, despite not being explicitly worded for IT in virtual environments.

Data Protection regulations are also likely to present an issue. Despite not being cloud specific, these regs tend to require that personal information remains within specific jurisdictions (eg Europe, US, UK) and if you have a standard 'cloud' there may not be any controls to restrict where data is actually stored. For example, if I wanted to store UK personal customer data on a cloud that is partially in the US I could fall foul of the UK's Data Protection Act 1998.

In terms of client expectations, cloud is often touted as being very resilient, due to its distributed nature, however outages do occur, and when they do, you are entirely reliant on the cloud provider sorting it out "in the cloud". See Amazon's April 2011 outage for an example.


Will new data written to disk while BitLocker is encrypting the disk be encrypted? When you enable BitLocker, there is a period of time where BitLocker is slowly encrypting the contents of the drive in the background. During this time, is it guaranteed that new data written to the disk will be encrypted as it is written? Or is it possible that it will be written to the unencrypted part of the drive, and won't be encrypted until later?

The drive will be treated as a whole, since it's a Disk/Volume encryption (unlike file or system encryption), everything that goes into the disc will be encrypted as it goes in.

UPDATE

Behavior confirmed in Microsoft Tech Net

Credits to Chris Vasselli


Add account to android device seems less secure than allowing access for a single app I just removed and re-added my google account to my android phone. I was surprised that in order to add the account, I had to supply my normal password, and a TOTP from google authenticator. It was not an option to use an app-specific password. Since google authenticator was installed on the phone in question, it does not seem to be an appropriate method for 2FA. Of course, a potential attacker would still require access to the phone AND my password, so there are still two factors of authentication, just not how I expected it.

Is my understanding correct, that an app-specific password would be more secure? If so, it doesn't seem right to me that allowing a single app to access part of my account is more secure than full account access.

Is it possible to change a setting to require "add account" on an android device to use an app-specific password, or at least to use a TOTP from a different device?

There is a similar question on the android stack exchange site. Is it appropriate to repeat the question here to get a security perspective on the question? I would also be open to suggestions for a google forum where I could post this question (I found two which gave me error 554).

Yes, you are correct. There are so many issues with using your normal password for the authentication on a 3rd party app.  IFF the app implements the o-auth correctly, the app should never see the password.. but there's no way for the user to know if they have implemented it correctly. Such a shame.

Also, yes the 2FA doesn't help as much if the authentication app is on the same phone, but sometimes you need to authenticate to 2FA apps with fingerprint and it also would add an extra layer of security if an attacker wanted to install the app on their phone and had your password.


Prevent phishing attacks through abuse of Apple iOS URL scheme I am building an Apple iOS application that will have the following flow:

A user completes registration from the web.
Upon completion of registration, a link is sent to his email.
Once the link is clicked on an iOS device, my iOS app will be launched and will prompt the user for credentials.

The thing is another malicious app can register to the same URL scheme as my app. In such a situation, the malicious app can be launched instead of my legitimate app, and easily steal the credentials of my users.

What can I do prevent data leakage in this situation? (i.e. make sure that the malicious app cannot imitate my app and/or implement a mechanism that will enable users to easily differentiate between my app and the malicious app)

I've seen some answers here: https://stackoverflow.com/questions/30461145/best-practices-in-dealing-with-the-abuse-of-custom-url-scheme-to-make-phishing-a

But all of them propose implementing a mechanism that will eventually enable the malicious application to completely imitate my application.

Before giving any solution, it is important to remember that, if an app is being installed on a user's device, then given time and dedication, a malicious user can replicate/reverse engineer the app. That said, there are certain techniques which can be used to make the job of reverse engineering the app difficult and eventually replicating the app difficult. Some of the techniques can be:

For every request a secret value can be sent, this secret value can be a hash of concatenated strings of (password + current time + domain + a constant string) etc. Any such scheme can be created, but make sure the code is obfuscated enough so that it is hard for the attacker to break. By frequently altering this algorithm, malicious app need to also do that to keep up.
Secondly, you can include anti-debugging checks like having ptrace with PT_DENY_ATTACH call  or using sysctl approach.  But again a determined and skilled attacker can circumvent these checks. These checks can be disabled by altering the app binary. But by having frequent hash checks of the binary can make the job of attacker further difficult.
Use of SSL pinning can also protect against some script kiddies from looking at network traffic, but tools like SSL KillSwitch makes bypassing this check trivial.


Is an OpenPGP signature made before a key is revoked considered valid? If a signature was made before the key was revoked will it still be considered as valid after revocation? Assuming that the key was revoked as superseded, the answer is obvious if the key was compromised.

In particular I'm interested in the answer to this question in relation to a master OpenPGP key migration and signing the new key with the old one. Does it make sense to wait before revoking the old key after the new one (and the signature) was published?

I found this question which is similar to mine but it does not concern GPG and web of trust specifically but digital signatures in general.

The short version: there is no way to differentiate between signatures issued before and after revoking a key. Faked system times and how attackers could exploit them provide a rather obvious explanation for this.

The slightly longer version with interactive exploration: RFC 4880, OpenPGP does not specify any rules on how to handle signatures issued by revoked keys -- apart from the sentence "A
revoked key is not to be used". The behavior in this case is implementation dependent. The most common implementation is probably GnuPG, so let's try how GnuPG acts. Consider following situation:

created keypair A in home directory A
signed a test document with this key
exported public key A
imported public key A into home directory B
created keypair B in home directory B
signed public key A with private key B

We now have a non-revoked key A, a document signed by this key, and this key A is certified by some other party B (and thus the key and its signatures validate successfully).

Now, what happens if we revoke key A (after signing the document)?

gpg: Signature made Wed Nov  1 15:39:35 2017 CET
gpg:                using RSA key 658787F11DEFDEE1DA206171C2F6C4CC6B298CA6
gpg: Good signature from "A" [full]
gpg: WARNING: This key has been revoked by its owner!
gpg:          This could mean that the signature is forged.
gpg: reason for revocation: Key is superseded

What happens if create another signature after revoking A (I took a copy GnuPG home directory A before revoking the key), so B tries to verify a signature issued by an already-revoked key?

gpg: Signature made Wed Nov  3 15:42:31 2017 CET
gpg:                using RSA key 658787F11DEFDEE1DA206171C2F6C4CC6B298CA6
gpg: Good signature from "A" [full]
gpg: WARNING: This key has been revoked by its owner!
gpg:          This could mean that the signature is forged.
gpg: reason for revocation: Key is superseded

With other words: you cannot discriminate between a signature issued before the revocation and one issued after. And this is a reasonable solution: as no third-party timestamping was involved after all, you cannot be sure about the signature's timestamp anyway. In fact, I also faked the system time when issuing the second signature. "Does OpenPGP key expiration add to security?" provides a similar discussion.

Waiting some time might be useful, anyway: for example if you provide a key transition statement, waiting for some time after issuing this (and notifying your peers about it) before revoking the old key might be reasonable. By doing so, people still see the non-revoked old key and can sign your new key, if their signing policy allows this.


hashcat hash type, convert sha256 binary to hex I am attempting to use hashcat to crack a hash that is 32 characters in length. I know the hash is sha256.

When i run the following command

hashcat -m 1400 binary-hashfound.txt /path/to/rockyou.txt

I receive the following error:

This copy of hashcat will expire soon ...
Skipping line  (line length exception)
No hashes loaded

My first guess is that because the hash I am using is 32 characters long, I gathered that it is a binary type sha256hash - I assumed that because of this thread with RickNZ's comment  : https://stackoverflow.com/questions/2240973/when-using-a-sha256-hash-how-long-is-the-hash-ie-how-long-should-my-mysql-va

Is this a correct assumption? I don't see another relevant sha256 hash type selection option for "sha256 binary 32" or something.

Not sure where to turn

This question basically comes down to the encoding method that is being used to encode the SHA256 hash.

A SHA256 hash is 256 bits long.

So, a SHA256 hash could be represented by a string of 64 hexadecimal characters, because there are 16 different hexadecimal characters  [0123456789ABCDEF], so each hexadecimal character represents 4 bits (2^4=16).  256 bits * (1 character / 4 bits) = 64 characters.

Or, a SHA256 hash could be represented by a string of 43 base64 characters, because there are 64 different base64 characters [a-z, A-Z, 0-9, +, /], so each base64 character represents 6 bits (2^6=64).  256 bits * (1 character / 6 bits) = 42.667 characters.

But, you are saying that the SHA256 hash that you are dealing with is 32 characters long.  So, that would mean that each character would represent 8 bits.  256 bits * (1 character / 8 bits) = 32 characters.  So in this case, each character could have 256 different values (2^8=256).

Do the characters in your hash look like they could be from a characters set which could potentially have 256 different characters?

If so, then you may need to convert the encoding to some other encoding that is more widely-used to represent SHA256 hashes, such as hexadecimal.  If not, then it may not be a SHA256 hash after all.


Is basic HTTP proxy authentication secure? I have been looking for cloud based proxies, and I notice that it's very common to authenticate to a proxy using basic auth over an unencrypted connection. I don't understand why this is considered acceptable.
Is proxy authentication different than regular basic auth? Based on this article, it seems like it is not different. Does basic proxy authentication expose credentials to anyone listening on the connection?

HTTP Basic over an unsecured connection exposes the username and password, as you expected. Even over an encrypted connection, basic auth isn't ideal because it exposes the credentials on every new request, which means they're constantly held in memory, you can't revoke a session, and using a secure password hashing function (which should take a good fraction of a second) would be prohibitively expensive.
However, for services where there's no actual resources being protected (no sensitive user account data or control of restricted services) and the goal is just to keep the riff-raff off the proxy, it might be sufficient. Knowing the proxy credentials probably won't give the attacker any ability that they didn't already need in order to capture those credentials, except the ability to use the proxy themselves. Obviously that's bad if the proxy is doing something like access to a corporate internal network - those should be protected by a VPN or similar - but if it's just changing the country your connection appears to come from? Probably not a big deal.


Do we really need a long and complicated password for websites? Most of websites that handle important information (Gmail, for instance) have some kind of brute force protection. Sometimes if you try more than X times it will lock the account or at least give you a captcha to solve.

Currently all the security experts keep saying the same thing: make long, mixed chars, high entropy passwords. This makes a lot of sense if you think about a RSA key, or something that could be decrypted offline, but is it really important when we talk about online account passwords?

For example, we create a password for Gmail using only 6 letters from the english alphabet. This is approximately 26^6 = 309 million combinations. If we consider that we can test 1 password per second (which I think is faster than we actually can, if you take into account the Gmail captchas), we will need up to 10 years to break and 5 years on average.

Points to consider:

If you use the same password on different website, another website could be hacked and you password exposed. I'm assuming that the password is unique. Used only with Gmail.
If somebody can grab the database they could brute force the hash of your password offline. I'm assuming that the website uses at least a salted hash (very unlikely that the hacker will try to break all passwords) and/or is very unlikely that the database will be hacked (it's a fair assumption with Gmail)
I am also assuming that your password is not a dictionary word or something easy to guess. This should rule out multiple account brute force (eg. testing the same common password across multiple accounts).

Is it safe to assume that we don't need a really long password to websites as soon as we follow the other security measures?
If we suggest that people use a long password just because they normally don't follow the other security advice (use same password across accounts, etc). Aren't we really trying to fix the symptoms and not the cause?

PS: Some other questions address almost the same thing, but the answers always consider that the person is using the same password across websites or that the website database is easily stolen.

The following doesn't really do this justice, but in summary...

In an ideal world no, complicated passwords should not be required for online resources.

But, in that ideal world we are dependent on the administrators of the system to harden systems to prevent unauthorised access to the 'password file', the following will minimise the risk:

Securely configure the infrastructure;
Apply patches promptly;
Have some form of monitoring to identify a compromise in the event of a zero-day exploit scenario (so that users can be 'told' to change their passwords);
Have and follow 'secure' programming/development methodologies;
Only employ trustworthy individuals.

The complete combination of which is unlikely for many sites.

Weaknesses in the above list may result in exploits that enable passwords to be bypassed altogether, but irrespective of the nature of a successful exploit it is a safe bet that, after gaining unauthorised access to a system attackers will attempt to exfiltrate the password file and subsequently brute force it to aid onward compromise of other systems (by exploiting password recycling).

So while there is no guarantee that a strong(er) password will prevent all bad stuff, it can help to mitigate for weaknesses in providers' solutions (whether known or not).

For the avoidance of doubt we are also dependent upon the service provider to do the following:

Apply hashing and salting to passwords;
Ensure the password is never exchanged in clear-text.

I guess for most end-users the decision about password complexity and length will come down to the information the site (and therefore password) gives access to.

My recommendation is: if it is something important use a complex password so that in the event of a system compromise other people's passwords are likely to be discovered first. But if it something trivial and convenience is more important take a chance on a weaker password, but accept that a hack could lead to loss of access to the account and/or release of information from the account.

For many site owners I suspect the decision to require complex passwords is a combination of FUD and the desire to minimise the impact of a critical failure of controls by increasing the amount of time to brute-force passwords, thus giving longer to rectify and minimise actual user account compromise (although if an attacker has access to password hashes they probably have sufficient system access to compromise the system in other ways anyway).


What are the dangers of extending my PATH? Are there any dangers of extending my PATH, say by adding /Users/me/bin?

It is obviously dangerous to add a directory to the PATH where other and potential malicious users can write into, where others can modify existing binaries or where you have symlinks pointing to places which can be modified by others.  If instead everything is fully under your own control and only under your control then adding a directory to a PATH is less a problem. Of course, you can still screw up things by placing a binary there with the same name as a common binary but with a different behavior then an existing binary but this is shooting in your own foot.


One-way function with conditions as inputs I need to write a one-way function, with some conditions as inputs, for example:

if ((a==b && c==2 ) || (c > 10000))
    return 1;
else
    return 0;

The result would only be 2 values (e.g., 0 or 1).

The key point is, by looking at the function and the result, we cannot figure out what the conditions (e.g., (if ((a==b && c==2 ) || (c > 10000))) ) are. Just like a hash function.

Is there any function (tricks) to do this?

You could do something like, where you encode all the conditions in a hash, that is carefully constructed to return specific bits at certain positions. Note that the hash will output a random value, so you would yourself need to bruteforce some of the constants to get the output you want:

if chr(sha512((length(c) > 1000) + "764065445" + b + md5(b.substr(0,10))).substring(15,1)) % 64 then (repeat as many times as neccessary to pick out bits)

BUT: This also means you have to accept some false positives, eg where input is rejected even if this does not result in a vulnerability being exploited.

Here, the attacker of course will be able to see the first condition, that length of c either needs to be above or below 1000. But here, the 10 first characters of b, need to result in a unknown md5 hash, that combined with the length of c being either above or under 1000, and result of b, will result in specific bits of a sha512 hash being 1 or 0.

Picking out more bits of the sha512 hash will make false positives less likely, but will also increase the possibility of finding the vulnerability by using rainbow tables.

By only picking out so many bits neccessary to reduce false positives to a minimum, attempting to brute-force the hash or use rainbow tables, will just result in a unlimited number of results.

This is similiar to vanitygen to bitcoin, where you bruteforce out some constant to get certain bits of the hash you want. Note that you DONT test for the full sha512 hash, you only test for certain bits to be true or false.


Is it ill-advised to use the same password for lock screen and full disk encryption (Windows 10 BitLocker)? I am wondering which attacks can be prevented by using a different password for the lock screen and full disk encryption. The goal is to prevent people from accessing my data. The details of my setup would be as follows:

Windows 10 (up to date, freshly installed).
Bitlocker FDE for C: drive using the same password as the administrator user.
Administrator user using the same password as the FDE.

Now as far as I know things like encryption and lock screens are a form of protection against physical attacks. But please correct my if I am wrong about that. I am currently only considering physical access attacks (leaving laptop behind, theft, etc.).

If the device is turned off there should be no additional risk for having the same password. You have to pass FDE before you even get to pass the lock screen. The lock screen password hash is also encrypted. If you can pass FDE you can access the data anyway (using something like delocker+linux), so my goal to protect my data has already failed.

If the device is turned on, fde passed (decrypted), but locked it shouldn't be possible to bypass the lock screen. Afaik one can't retrieve the password in plain text, from the lock screen, on the newest version of Windows 10. Also a "cold boot attack" should already be possible at this stage even if the password is different.

If the device is turned on, fde passed (decrypted), and unlocked... well at this point all is lost.

My knowledge on security is limited, so I might be missing something. Because as far as I see it, this is one of those odd cases where using the same password has no real bad repercussions. So my question is, am I missing something?

If you're the only user of the system and your password is string, then yes, there's minimal risk to using the same password.

Two caveats.

Even without FDE, your system encrypts certain data using your lockscreen password, for example DPAPI, which is used by some password managers like the one built into Chrome.

Also, consider that FDE password is something that you only need to type once for every boot, while the lockscreen password, you need to type everytime you lock your screen, which if you have good clean desk hygiene, you should be locking your screen everytime you leave your desk, so you'll likely be locking the screen dozens of times per day as you go for lunch, to the toilet, quick break, etc. Depending on how paranoid you are about your security,  you have the opportunity to use a stronger password for the FDE password and to use an easier to type password for your lockscreen. If you use the same password for both, you'll have to find a compromise by finding one password that satisfies both requirements.


Would it be more secure or not if all computers in the network use the same operating system? If all the computers use the same operating system, attackers only need to focus on one operating system, would it be unsafe?

In 2003, Dan Geer from @Stake published a seminal paper on this very topic - CyberInsecurity: The Cost of Monopoly.  Surprisingly (given that he was employed by Microsoft at the time) he comes squarely down into the camp claiming that diversity is vital to security (emphasis mine):

  Regardless of the topic – computing versus electric power generation
  versus air defense – survivability is all about preparing for failure
  so as to survive it. Survivability, whether as a concept or as a
  measure, is built on two pillars: replicated provisioning and
  diversified risk....

  ...redundancy has little ability to protect against cascade
  failure; having more computers with the same vulnerabilities cannot
  help if an attack can reach them all. Protection from cascade failure
  is instead the province of risk diversification – that is, using more
  than one kind of computer or device, more than one brand of operating
  system, which in turns assures that attacks will be limited in their
  effectiveness. This fundamental principle assures that, like farmers
  who grow more than one crop, those of us who depend on computers will
  not see them all fail when the next blight hits. This sort of
  diversification is widely accepted in almost every sector of society
  from finance to agriculture to telecommunications.

(He went on to conclude that Microsoft was a threat insofar as it introduced a monoculture; which turned out to be a Career Limiting Move for him at Microsoft.)

In the comments, @Johnny suggests that this is a credentialist answer.  While I've chosen to quote a respected professional's well-written paper here, I do so because it mirrors my 20+ years of experience in the computer and security industry.  (Which, heck, almost seems like secondary credentialism.  But I'm just saying that I'm referencing rather than parroting).

For example, the 3-tier (web/app/db) architecture became a widely accepted improvement in security terms a long time ago, because the separation between differing functions helped enforce security.  In that vein, my experience has been that there is a tradeoff between the additional work setting up heterogenous systems (say, IIS with a MySQL-on-Linux backend) and the additional benefit of diversity when attacks (or patches!) introduce disruption into the stack.  And that I've regretted having a larger problem more times than I regretted the extra work :)

Virgin field epidemics - either because you're not segmenting your networks, or because you're using the same passwords, or you've only got one [DNS/Hosting/Network] provider, or because you're using the same OS everywhere - all end badly.


sqlmap - Dump multiple columns at once? I'm playing around with sqlmap, and I'm having a little trouble dumping database columns.

I can dump all of them at once which is great, but this database has thousands of users and dumping every column would take over a day, whereas dumping columns individually only takes about 15 minutes. The only problem with this is that all the data is dumped from A-Z, which means I have no idea which hash is for which user.

Is there a way of dumping multiple columns (but not all) at once to prevent them being mixed up?

Cheers!

The switch you're looking for here is -C which specified the columns to be dumped from a target table (which you specify with -T).  More info is here


Is it possible to increase the cost of BCrypt or PBKDF2 when its already calculated and without the original password? I just wanted to know if you can increase the cost (iterations) of those two algorithms off-line.
I want to increase the cost every year of my users passwords.

One solution is to recalculate them when the user logs in, but a user may have not logged in that period, and I don't want to wait till he logs in.

This could be done with password stretching (ex. iterating over a sha-256 hash), but I'm not aware if this is possible with BCrypt and/or PBKDF2.
Thank you.

PBKDF2 and Bcrypt do not support increasing the cost, starting from the output at a given iteration count, without knowledge of the password. There is no intrinsic reason for that; a password hashing process could allow for such offline stretching while still be "good". But these algorithms happen not to allow it.

What can be done is the following: a normal bcrypt or PBKDF2 output includes the salt s, the iteration count i, and the hash output v. In bcrypt implementations, the three values are often encoded into printable characters (with a Base64-like encoding); see for instance this answer. Assuming you have s and v, you can store the following:

the salt s;
an iteration count i;
an extra iteration count j;
the value h(h(h(...h(h(v))...))) which is the result of hashing v repeatedly, with a secure hash function h, done j times.

For password verification, you have to recompute the bcrypt/PBKDF2 from the given password (using s and i), and then hash the resulting value j times, to see if it matches the stored value.

This is mostly secure, if you use a strong hash function for h, like SHA-256. It can be shown that the repeated hashing reduces the space of possible values, but should reach an inner "cycle" of size roughly sqrt(N) if the hash output values are in a space of size N; moreover, if that cycle is small enough to be explored exhaustively, then a collision on the hash function h can be computed (see this page for a nice diagram). Thus, if h is collision-resistant (like SHA-256), then the scheme above is safe.

The important point is that you can increase j afterwards, in an offline way. However, note that this kind of stretching relies on the computing cost involved in doing many extra hash function computations. Unfortunately, usual hash functions like SHA-256 map really well on what GPU can do; thus, the advantage obtained that way over the attacker might not be as great as initially wished for. In other words, using the stretching described above voids any advantage of bcrypt over PBKDF2 (see this answer for a discussion on this subject). You could apply it as a temporary measure, until the said user comes back, so that the bcrypt step could be done again with a higher iteration count (i).

Moreover, the scheme I describe above is homemade crypto, and that's bad. I can get away with it because I am totally awesome, but this cannot be promoted on a general basis.


Possible to determine what plugins and versions are being used in a wordpress site? I have been thinking about creating a Wordpress vulnerability scanner that would look for plugins being used by a Wordpress site and then search osvdb for known vulnerabilities.

I'm curious if there is an automated way to determine what plugins (and their version) a Wordpress site is using?  So far the only idea I have had is to go through each page and look for paths to the default:  http://mysite.com/wp-content/plugins/whatever path and then perhaps dig into js files to see if you can find a version number.

Can anyone think of a better way to do this?

Are you aware of existing software that does the same thing?

wpupdatescan
wpscan
Acunetix (free version of commercial product)

Use a method to parse what plugins are used on a WordPress site, and then it's a simple compare to a vulnerability database.


In the light of recent information about RarVM, can we still trust RAR files? See:

http://blog.cmpxchg8b.com/2012/09/fun-with-constrained-programming.html
https://github.com/taviso/rarvmtools

It would seem according to these two sources that rar files can contain custom code thanks to the WinRAR virtual machine, which under normal circumstances may only access the data being uncompressed. What is intriguing however is that the following is mentioned in the RarVM Toolchain docs:

  Known Bugs

  There are several known bugs in the RarVM.

  [redacted as some have security consequences]

Should we start considering RAR files insecure?

Note that in this case, what is deemed insecure is the RarVM implementation found in WinRAR, and probably not in the core design of the VM (if so, more interesting).

So you can either assume WinRar itself is insecure (something not improbable) or that all RAR files are insecure (more improbable than before).

What you do with this information, is probably nothing. You can decide you only accept ZIP files, but you're going to have trouble implementing that.


Authentication between two internal servers I have two internal servers that are going to communicate with each other; they speak HTTPS. Is there a best practice for authenticating communications between internal servers?

Short of a best practice, my current idea is to have both the server and the "client" (really another server, but a client in the HTTP sense) verify that the other end presents a cert that is signed by a well known CA. I'm thinking of using a self-signed cert as the CA, and just distributing this cert to the machines as part of our automated deployment. (We also have a cert for example.com and *.example.com, but I'm not sure how wildly I want to distribute that cert's corresponding private key. Also, it's my understanding of centralized CA's that I can't create a foo-service.example.com cert without giving more money to and waiting on an external CA.) Is this fine?

Mostly, if the client inadvertently gets pointed at the wrong server (e.g., a DNS record gets pointed to the wrong IP) then things refuse to work. (Also, someone roguely connecting to the server shouldn't have their request accepted.)

I've thought about having the servers just have secrets, and pass them over HTTP headers, but someone would be passing their secret first without having first authenticated the other side. (Though crypto could fix this, it seemed like I'd just re-invent TLS certs.)

There is no need to involve a certificate authority (CA), or trusted 3rd party,  when you control client and the server.  By avoiding the need to have a CA,  you are no longer threatened by rogue certificate authorities, and rogue certificate authority certificates.

Using two self-signed certificates it is possible to create a very strong TLS connection between two systems.  Both the client and the server generate their own self-signed certificate, then the public keys are swapped.

The server uses TLS Client Authentication to ensure the client is using a known certificate.
The client uses certificate pinning to ensure that the server is using a known certificate.  There is a draft RFC which extends HTTP-Strict Transport Security (HSTS) to allow for signature chain validation.  In the near future, the client will use HSTS for this requirement.  For now, client-side certificate pinning requires a platform specific implementation.


Where and how many times does encryption take place when we browse the internet? I'm taking a cryptography course and what I've gathered so far is: PGP takes place at the application layer TLS takes place at the transport layer IPsec takes place in the network layer WPA2 Encryption takes place in the physical layer
I understand the protocols and such but don't really get how they are used in practice. Do any one of the above protocols take place? Are they all used at the same time?
For example say I'm sending an email to a friend. Will it first be encrypted with PGP by the application, then by TLS at the transport layer, then by IPsec in the network layer, and then by WPA2 in the physical layer? Or is any single one of the above done? Consider I'm sending an email over an HTTPS connection through a VPN and am connected to a router using WPA2.
If encryption and decryption is happening multiple times is it safe to remove all but one of the above? If not what is the purpose of using each of them together?

The answer is that they all protect against different kinds of eavesdropping, so they are not at all in use at the same time, and are not always relevant.  For instance:

WPA2 protects the physical link layer, but only in the case of WIFI communication.  WPA2 is what stops someone else on your WIFI network from listening to the traffic between your computer and your router.  Once your network traffic leaves the WIFI router and goes to the "internet", this is no longer relevant, and the traffic between your WIFI router and your ISP is likely unencrypted by default.
TLS can be used in a variety of protocols, but the simple example is for HTTP when talking to a web server.  In that case, TLS is used to encrypt the communication between your web browser and the web server (e.g. security.stackexchange.com) that you are communicating with.  This means that if you were only communicating with services that used TLS, it wouldn't matter as much whether your WIFI network was protected with WPA2.  Similarly, the fact that you are using TLS to communicate with web servers is important because, most likely, the physical layer from your router to the web server is otherwise unencrypted, so if you didn't use TLS then anyone in between your router and the web server would be able to read your requests and responses (like in the early days of the internet when HTTP was more commonplace).  Lack of TLS and lack of WPA2 made it possible for someone in a coffee shop to take over the facebook accounts of everyone using facebook on the same network.
PGP is not really used by default anywhere, but for your average user, is most likely to be used for email.  Email is an especially tricky one because email servers don't always talk to eachother over encrypted channels, and since the communication is being handled between email servers rather than your computer and a destination computer directly, you have less control.  PGP seeks to encrypt your emails before it leaves your computer in a way that can only be decrypted by the final recipient, so it would be an example of end-to-end encryption.  As the name implies, the goal of this is to ensure that any communication can be decrypted only by the two communicating parties, regardless of whether or not the systems that are transmitting the data use encryption themselves.  Theoretically, when using end-to-end encryption, encryption at all other layers becomes redundant.

The trouble, as you might gather from the above descriptions, is that many encryption systems can only encrypt certain parts of the communication channel.  As a result, even if it was possible to "remove all but one", it wouldn't be a good idea because sometimes your encryption "stops" at unexpected places.
For example, theoretically, if I'm only browsing HTTPS websites then I don't need to worry about WIFI encryption.  However, you might be surprised when someone still knows what domains you visit because your computer makes DNS requests in plain text.  You probably won't care that the exact pages you visit are encrypted when everyone can still see that you are visiting https://some-obscure-and-private-sexual-fetish.example.com.


How did SSLv3 get AES? IANA maintains a registry of TLS cipher suites at TLS Parameters. TLS provides TLS_RSA_WITH_AES_128_CBC_SHA, its value is {0x00, 0x2f}, and its available in TLS 1.0 and above. The AES cipher suites were added to TLS with RFC 3268, AES Ciphersuites for TLS in 2002.

However, AES cipher suites were not added to SSLv3 because SSLv3 is not under the control of the IETF. From RFC 5746, Section 4.5:

  While SSLv3 is not a protocol under IETF change control (see [SSLv3]),
  it was the original basis for TLS and most TLS implementations also
  support SSLv3.

OpenSSL provides TLS_RSA_WITH_AES_128_CBC_SHA via cipher AES128-SHA (see OpenSSL's docs on ciphers(1)). AES128-SHA works with SSLv3 via s_client, and a quick Wireshark trace shows cipher suite {0x00, 0x2f} is used.

$ openssl s_client -ssl3 -connect google.com:443 -cipher "AES128-SHA"
CONNECTED(00000003)
...
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
...
SSL-Session:
    Protocol  : SSLv3
    Cipher    : AES128-SHA
...

I cannot find a reference where the AES cipher suites are valid in SSLv3. I looked in the draft The SSL Protocol Version 3.0 from 1996, RFC 6101, The Secure Sockets Layer (SSL) Protocol Version 3.0 from 2011, and RFC 3268, AES Ciphersuites for TLS from 2002. I even searched IETF Tools for AES and SSL.

Where are the AES ciphers suites covered for the SSLv3 protocol?

SSL 3.0 is not a standard. Realistically, it is "what Netscape was doing at that time". When the protocol was turned into a standard, it became RFC 2246, aka "TLS 1.0".

The original document which the TLS authors used as source was later on (much later on) put in the RFC format and became RFC 6101, which has category "Historic". Historic RFC are quite low on the standards ladder; they are even below the "Informational" RFC. Before publication of that RFC, people intent on writing an SSL library would first implement TLS 1.0 as per the RFC, then wade through OpenSSL's source code and make interoperability tests with existing implementations to also offer SSLv3.

Since SSLv3 is a de facto but not de jure standard, you will not find a RFC which specifies the standard way of doing AES with SSL 3.0; by definition, there cannot be such a standard. At best, one may imagine an "Historic" RFC which would document the common practice, which is namely direct usage of RFC 3268. SSL 3.0 is very similar to TLS 1.0, so the backport of AES cipher suites from TLS 1.0 to SSL 3.0 is not ambiguous; as someone who already did that (several times !), I can confirm that getting AES support "right" in SSL 3.0 is not hard (where "right" means: "works with existing SSL clients and servers").


I get the feeling that Microsoft and Mac use two different forms of AES I have an AES string being produced with this class, the AesCryptoServiceProvider Class provided by Microsoft.

And I need to decode this encryption with Ruby's SSL::Cipher class .

The problem is that if one encrypts one with one, you can't decrypt it with the other.

An example of my VB.NET code :

Private Const AesIV As String = "!QAZ2WSX#EDC4RFV"
Private Const AesKey As String = "5TGB&YHN7UJM(IK<"
aes.Mode = CipherMode.CBC
aes.Padding = PaddingMode.PKCS7
aes.BlockSize = 128
aes.KeySize = 128

Which produces this string :

p6SI3+hMRFRsQG5Vk+R1YdXv9EaCsfAuB0ZSsqkBcy83ki20U0bV5TZrwxJ0C4dlpSEJDwc7b5znd/8UNXEhcXV0m8tAms3lp4ZS2aUaSfc=

And then my ruby code does this :

cipher = OpenSSL::Cipher::AES128.new :CBC
# ^ That's 128 bit block in CBC mode, it defaults to 128 key size
cipher.iv = "!QAZ2WSX#EDC4RFV"
cipher.key = "5TGB&YHN7UJM(IK<"

solution = cipher.update("p6SI3+hMRFRsQG5Vk+R1YdXv9EaCsfAuB0ZSsqkBcy83ki20U0bV5TZrwxJ0C4dlpSEJDwc7b5znd/8UNXEhcXV0m8tAms3lp4ZS2aUaSfc=")

> "\xAC\xF3J{Cw\x95\xD8\x0F'\xC2\xB4,\xF2\x8E\xFE\xC9\x95\xD7\xE6JcB7\v\xBA\xD8kP'\a\x80\x81\x00\xC1\xCC\xE4\x95\x9E_5Ws\xF9j\xDF\xAC\xBA\"K\xF2\xB7,\x7F4\n\r\xB2\xF5\xC7R\xCFn\x97B\x05\\\xE70\\\x11x\xFA\v\xA2k\xBE(\x1E\xEB*O$\xDCc\xD7\xBEfs\x99\xADD\xC0\x1F\xBB9"

solution << cipher.final

> OpenSSL::Cipher::CipherError: wrong final block length

There are several weird things in your setup:

ECB mode does not use any IV. You should not specify an IV when using ECB mode. Or, rather, you should not use ECB, which is weak (generally speaking).
AES processes binary input, produces binary output, and uses a binary key. There is no character string whatsoever in AES; thus, any notion of encoding like UTF-8 should be completely irrelevant and out of scope. If you need to specify an encoding, then this means that there is some character string which is converted to bytes or back, and that can be a source of your problems.
What you call "bit size" is obscure. A bit is a bit. Maybe you mean "block size". AES uses blocks of 128 bits, always.