I'm pretty much sure I must be doing something completely wrong, but why is this test failing for the last two assertions?
Two relatively similar, but nevertheless different Strings (basically JWT) test ok with the hashes of the other?
#Test
public void testMoreHashing() {
String longToken = "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJCTFVCQl9BVURJRU5DRSIsInN1YiI6IkNZOXJ6VVloMDNQSzNrNkRKaWUwOWc9PSIsIm5iZiI6MTUxMzI4NzAzNCwiaXNzIjoiSVNTVUVSIiwiZXhwIjoxNTE4NDcxMDM0LCJpYXQiOjE1MTMyODcwMzQsImVtYWlsIjoiYUBiLmNvbSJ9.IYMKztYEIJxzYgHpUDhCHcG22h28OQAsMg7TEMBVYELSczeniwv8IKxgrSBub9Q0X14UT6LnQUu4yeeTofRYH2jRSwW42gfaW5uK8NJQVdluNdZwUsWHVG05gbaSM7ZeS4tH3-SVbUOO3uJ-N2sVcBF5AFLaIAu0GD9CzPU1CjYYc9JiAArztAS5j7pK-xGNTRCKvcoGLa9iG9nhvssTZkPH6kPOJj9RHFo30mgSnPIGSc6040h7n8X7LCUC4qfUe1sOknHomN_RKTQk4Q5FBL1snTyCTxcaErVwvjv__YK9FQ40pDfOboEsSk81CYW6SbqDIdVlyr09VrDzIwJpPA";
String shortToken = "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJCTFVCQl9BVURJRU5DRSIsInN1YiI6IlU3bFFoV09TUDBmMDdOZ1BWTkd3d0E9PSIsIm5iZiI6MTUxMzI4NzAzNSwiaXNzIjoiSVNTVUVSIiwiZXhwIjoxNTE4NDcxMDM1LCJpYXQiOjE1MTMyODcwMzUsImVtYWlsIjoiYUBiLmNvbSJ9.";
String longTokenHash = BCrypt.hashpw(longToken, BCrypt.gensalt(13));
assertTrue(BCrypt.checkpw(longToken, longTokenHash));
String shortTokenHash = BCrypt.hashpw(shortToken, BCrypt.gensalt(13));
assertTrue(BCrypt.checkpw(shortToken, shortTokenHash));
assertFalse(longToken.equalsIgnoreCase(shortToken));
assertFalse(longTokenHash.equalsIgnoreCase(shortTokenHash));
assertFalse(longToken.contains(shortToken));
assertFalse(BCrypt.checkpw(longToken, shortTokenHash));
assertFalse(BCrypt.checkpw(shortToken, longTokenHash));
}
the used version of jBCrypt as copied from my pom.xml is
<dependency>
<groupId>de.svenkubiak</groupId>
<artifactId>jBCrypt</artifactId>
<version>0.4</version>
</dependency>
junit is version 4.12
Thanks for helping :)
as #tadman pointed out, the used blowfish algorithm is truncating passwords at 72 characters, and the differences in the used passwords only start at 79.
see also https://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length
Related
I'm trying unit testing for the first time with Jest on a personal project, and some of my tests failed even though the data received was the exact same as expected, here's an example:
test("decrypt method works correctly", () =>{
const myAES = new rijndael("", "0bdfa595235c307a105d593fb78fbb13", { key: "SOME 128 BIT KEY", bits: 128, rounds: 9 })
expect(myAES.decrypt()).toStrictEqual({
"c": "0bdfa595235c307a105d593fb78fbb13",
"p": "ATTACK AT DAWN!",
"errors": []
})
}
So then I tried to check if it's a problem with Jest or my code:
const r = myAES.decrypt()
console.log(typeof r.p) // string
console.log(r.p === "ATTACK AT DAWN!") // false
Which just made me even more confused as the strings look the same. The code that I'm testing is an AES encryption function (Don't worry it's just a personal project for fun won't be used in production) that processes text as nodeJS Buffers, and in the end uses the toString() method to convert it back to a string. I'm thinking that may be why I'm having issues, but can't seem to find exactly why. Would love it if someone could point me in the right direction so I can get rid of this error. Thank you in advance.
P.S. I'll save everyone the pain of reading my AES implementation for now as I don't think it's a problem with the encryption but let me know if that's necessary
Ok, so turns out it was a stupid mistake where I overlooked the series of null bytes that tend to end up in the end of the buffer after decryption. While toString() will turn the buffer into the string I want the computer will not recognise it as the same string. So all I had to do was strip the null bytes that follow. Assuming that the null bytes should only appear at the end of the string as they normally do:
const i = buffer.indexOf(0x00)
const result = buffer.slice(0, i).toString() //solves the problem
TypeScript does not produce any errors for the following code:
const maybe_a_string: undefined | string = undefined;
const false_or_string: false | string = false;
// I'd like the following to produce an error/warning...
const message_string = `Some readable string info should be here: ${maybe_a_string} ${false_or_string}`;
Is there some kind of setting I can turn on, or simple alternative ways to write the last line that will warn me about trying to use non-string variables inside strings like this? (but without needing to add extra lines of code for every sub-string to be asserted individually)
I guess it treats them as fine because some types like bools, numbers and misc objects have a .toString() method...
But especially in the case of undefined (which actually doesn't have a .toString() method) - it's quite common for you to have a bug there, as the only time you really want to see the string "undefined" inside another string is for debugging purposes. But there's a lot of these bugs out there in the wild where end users are seeing stuff like "hello undefined" unintentionally.
Personally I would handle this by making the string template into a function. That way you can specify that the arguments must be strings.
const createMessageString = (first: string, second: string): string => {
return `Some readable string info should be here: ${first} ${second}`;
}
const message_string = createMessageString( maybe_a_string, false_or_string );
// will give an error unless types are refined
Vote for https://github.com/microsoft/TypeScript/issues/30239 [Restrict template literal interpolation expressions to strings]
Additionally, you can try workarounds from the issue comments.
Which setting(s) in Resharper 8 are reformatting my object initializer like this? (i.e. with the comma on it's own line).
var snowDepthProcessor = new DataProcessor<SnowDepthModel>
{
Name = "Snow Depth"
,
DataRetriever = snowReportRetriever
,
Parser = new SnowDepthParser()
,
...
};
I've tried every combination of settings I can find/think of; I do want the lines chopped but I don't want the comma to be on its own line.
I share your pain. I've to admit my solution is just partial because it needs change style from what you'd like to use to
List<string> demo = new List<string>
{
"a",
"b",
"c"
}
Then formatting is not changed. I'd also much rather use syntax you've described so I've created R# ticket https://youtrack.jetbrains.com/issue/RSRP-453704 but until it's resolved this is only way how suppress that (it behave in same way even in latest R#10)
EDIT: Good news. Seems to be fixed since R# 2017.1
I have an Object which stores pairs for a find and replace that I perform on up to 1500 Strings at a time.
The Object is populated with pairs using a method that will accept a String and then store this as a property with the value being an automatically assigned base 36 number, like this:
function addShort(long:String):void
{
_pairs[long] = _nextShort;
}
_nextShort returns an automatically incremented value being the subject of .toString(36), so running the above a few times might make _pairs look like this:
_pairs:Object = {
"class": "0",
"testing.objects.TestBlock": "1",
"skin.x": "2",
"skin.y": "3",
...........
"someString": "az1"
};
This Object could realistically end up being really large, having over a couple hundred pairs stored.
I then have a method that will take a "long" String (which will include the Strings I've given to addShort() previously) and return a new String where these have been replaced with their respective short value.
The method looks like this:
public function shorten(long:String):String
{
for(var i:String in _pairs)
long = long.split(i).join(_pairs[i]);
return long;
}
Nice an simple, however in my mind I foresee a massive problem in a case where I might want to "shorten" 2000+ Strings and the _pairs Object has at the same time has over 500 pairs.
That ends up being 1,000,000 iterations all up which obviously doesn't seem very efficient at all.
How can I improve this process significantly?
Based on comments from #kapep I realized what I needed is actually a compression library that will do this work for me.
I stumbled across an LZW compression class within a package called Calista which works great.
I did notice that the compression was really slow, which is understandable, but if there are any suggestions for something quicker I'm open to them.
How about Regular Expressions for replacing String patterns? Catch some code.
If I have a Set that I know contains a single element, what's the best way to extract it? The best I can come up with is this, but it doesn't feel very groovy:
set = [1] as Set
e = set.toList()[0]
assert e == 1
If I'm dealing with a list, I've got lots of nice ways to get the element, none of which seem to work with Sets:
def list = [1]
e = list[0]
(e) = list
e = list.head()
One other possibility (which will work in Java or Groovy):
set.iterator().next()
A few alternatives, none of them very pretty:
set.iterator()[0]
set.find { true }
set.collect { it }[0]
Finally, if it's guaranteed that that set has only one item:
def e
set.each { e = it }
The underlying issue, of course, is that Java Sets provide no defined order (as mentioned in the Javadoc), and hence no ability to get the nth element (discussed in this question and this one). Hence, any solution is always to somehow convert the set to a list.
My guess is that either of the first two options involve the least data-copying, as they needn't construct a complete list of the set, but for a one-element set, that should hardly be a concern.
Since Java 8, here is another solution that will work for both Java and Groovy:
set.stream().findFirst().get()
Even when this question is quite old, I am sharing my just a bit prettier solution.
(set as List).first()
(set as List)[0]
If you need to take null into account (not the case in this question):
(set as List)?.first()
(set as List)?.get(index)
Hope it helps! :)