Why a string instead of char buffer?
Because it should be immutable? Why a CharBuffer instead of a string?
It’s just returning what the underlying document model is returning which (in theory) may have some complicated data structure underneath that it has to synthesize into a string. Thus it should definitely be immutable.
So the question is why not a string?
Sorry meant char array. Was messing with StringBuffer so had buffers on the brain.
Shouldn’t passwords not be mutable at a minimum?
Not sure that really makes that much different though.
There may be one too many negatives for me to parse that question correctly.
Anything returned from DocumentModel should be immutable because you have no idea what underlying data structure is being used and modifying it directly may not even be possible through a simpler interface.
So, yes, then we are left with the option to return char or return a string. The same amount of work needs to go into both. String better describes that you are getting a read-only view of something. Returning the value as a whole copy char array seems unwise.
I’m not sure what the use-case is for modifying the result after you get it… but not in a way that at all modifies what the text component shows. And if you just want your own copy of a char array to muck around with for some reason (surely an extremely rare use-case) then String can give you one in a single call.
Still learning security so I was trying to see why Oracle did it one way and you another. I see now your right.
Going to give this a try and see what happens. Probably old news though to everyone but me.
jni port
https://docs.lazycode.co/lazysodium/about
of this,
https://download.libsodium.org/doc/
What is it that you are using that for?
For example, if you just want to hash passwords, Java already has built in stuff for that.
public static String hash( String value, String type ) {
try {
MessageDigest digest = MessageDigest.getInstance(type);
byte[] result = digest.digest( value.getBytes( "UTF-8" ) );
// Convert to a big integer for easy hex conversion
BigInteger bi = new BigInteger( 1, result );
String val = bi.toString(16);
// should only execute once, but just in case
while( val.length() < result.length * 2 ) {
val = "0" + val;
}
return val;
} catch( Exception e ) {
throw new RuntimeException( "Error creating digest", e );
}
}
String hashed = hash(“My Password Is Really String”, “SHA-256”);
…or whatever. (It should be properly salted, of course.)
I’m kicking this one to the curb. Cant even run the only test for it. The documentation for install on Libosodium main site for windows is total dung.
Just to note, current standards of hashing are PKBDF2 and that you hash the password and transmit the hash for comparison of the stored hash. That is to say when you create an account with a password you hash the password locally, send it and save the hash. Then when you log in, you hash the password again locally before sending and compare the stored hash with the transmitted one. That way no passwords are stored or transmitted.
You could argue that password textbox binding is insecure in itself because it means the password is stored in memory. That part isn’t really my forte except in theory. If memory serves, password textbox binding is forbidden.
2 Likes
Well that was easier to grasp than these security docs explain things.
Most of these security docs are so terse and bloviated its painful.
The best doc I read on this entire security stuff is from crackstation. I’ve seen others link to it here. His library was easy to use but now its outdated.
well the idea of using char array over String for password is as follows:
- string is immutable, thus once created the password stays in memory unless garbage collected
- with char array, after the password is no longer needed, you can overwrite the char array to remove it from memory (this is the advantage of char array over String when considering security)
1 Like
I’ve read this but seen it rebutted. Because the user is generating the hash, it means for bad things to happen they are already compromised.
This is how crackstation says to do this.
- First time user creates account, they use their username (or email) concatenated with my domain name as the client-side salt, hash that with their password and send me the hash.
- I generate a my salt and hash their hash.
- I save both the salt and the generated hash in the user database.
Every time they login, they repeat step 1.
I then retrieve my salt and hash from the database.
I use the my salt and hash they sent and hash again.
I Compare the returned hash with the hash from the database. If they match, the password is correct. Otherwise, the password is incorrect.
Is this what you are saying?
Yep, that’s the way I do it… must have read the same article. 
That’s all I have on this. I am starting to get into the server stuff now so I will have more questions for another thread eventually.
Thank you.
Yeah. Just save your hash and salt in the same database column or whatever divided by a colon. That’s the general way to keep them together so they are never separated or mixed with someone else’s.
hash:salt