i've found scrypt for delphi but desire to use it cross-platform and don't know enough about removing stuff for windows... is there an scrypt available for FPC or lazarus that is easily implemented and used?

i've found scrypt for delphi but desire to use it cross-platform and don't know enough about removing stuff for windows... is there an scrypt available for FPC or lazarus that is easily implemented and used?

Did you try dcrypt, I think it works with FPC ?
Also, there is a hmac unit in fpc, as well as a sha1 unit. It should work cross-platform, but there is an optimized version for i386.

Michael.

Depends on whether he's specifically looking for Scrypt or just something to do the job. I've used (parts of) DCPcrypt with Lazarus.

no, i haven't heard of dcrypt... i'm specifically after scrypt for securing passwords in a database... i don't know if dcrypt is using a different method than scrypt or if that's just the name of the code...

It is of course DCPCrypt:
http://wiki.freepascal.org/DCPcrypt

As for the exact algorithm: there are many algorithms available, you can choose any one, really.

Unless you're writing military grade or intelligence agency applications, I don't think it really matters which one you use...

Michael.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 26 Oct 2015 16:54:16 -0400, Wkitty42 ()
wrote about "Re: [fpc-pascal] is scrypt available?" (in ):

[snip]

no, i haven't heard of dcrypt... i'm specifically after scrypt for securing passwords in a database...

So what you are really after is a hash, rather than streaming or block cryptography.

I use PostgreSQL, which offers MD5 hashing of passwords as a built-in, without me adding any of my own (or anybody else's) code to perform hashing.

HTH
- --
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlYuqQIACgkQogYgcI4W/5RChQCeJxDxcBuycuHZRJKywuQdhwDo 8DYAoIXF4Q0kgOpMZNdHtNIcH8RFfO/n
=tvjb
-----END PGP SIGNATURE-----

ahh! that makes a difference ;)

As for the exact algorithm: there are many algorithms available, you can choose any one, really.

i'll take a look... one thing that might be problematic is if it relies on additional units... the use case in question uses all custom written units and nothing much from the FCL or similar...

Unless you're writing military grade or intelligence agency applications, I don't think it really matters which one you use...

that's true ;)

pretty much, yes...

I use PostgreSQL, which offers MD5 hashing of passwords as a built-in, without me adding any of my own (or anybody else's) code to perform hashing.

sadly MD5 have been being cracked in little time for over a decade... that's why we're looking at other means... bcrypt came up first in the searched and then scrypt was pointed out along with bcrypt's failings... the question now is being able/willing to use someone else's code or to reinvent the wheel... if it were me, i'd use the other code if its license fits the app in question...

HTH

it does... it is always good to hear from you, too :)

how do you use it without lazarus being anywhere around? the wiki only talks about how to install lpk files and how to pull from a git repo...

sorry if this is very basic... the information available leaves much to be desired :(

i'll take a look... one thing that might be problematic is if it relies on additional units...

not sure what you mean by that. DCPcrypt is a project that consists of a few units. It can be used in Console or GUI (eg: LCL or fpGUI) applications. I've used it for both Console and GUI for many years.

Regards,
- Graeme -

use someone else's code or to reinvent the wheel...

When it comes to security the first rule of thumb applies... Never reinvent the wheel! It takes years for security related code to be well tested and vetted.

Regards,
- Graeme -

the wiki only talks about how to install lpk files and how to pull from a git repo...

No it doesn't. Please read the wiki again. There are two packages:

"dcpcrypt.lpk" which is a run-time only packages, and doesn't require any installation.

"dcpcrypt_laz.plk" which is a design-time only package - this is what is installed in Lazarus so icons appear in the component palette of the IDE. This is 100% optional.

The first package just makes it easier for you to associated DCPcrypt with your project, and for Lazarus to find the units. But you don't need to use Lazarus or Lazarus Packages. If you don't, then simply include the units you need in your project, set up the Unit Paths to find DCPcrypt and instantiated the classes you need.

Regards,
- Graeme -

the project in question uses very few outside developed libraries or units... we don't want to drag in a whole lot of stuff that's not needed or used by the rest of the project... it is one reason why some existing procedures are reinvented instead of using them from the FCL or similar...

DCPcrypt is a project that consists of a few units. It can be used in Console or GUI (eg: LCL or fpGUI) applications. I've used it for both Console and GUI for many years.

ok... one thing that confused me when looking at the wiki is it pointing out the lpk files and the repo but not much of anything else... the screen shot is ok for how it looks in the lazarus gui but aside from that, there's not much else describing the capabilities available or giving examples...

i'll probably take a closer look at it soonish... it depends on other factors at hand, though...

very true... which is why things are looked at very closely to see if they are going to drag in a bunch of other unwanted stuff... in some cases, it is possible to recreate those other needed routines but not always ;)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 26 Oct 2015 22:02:23 -0400, Wkitty42 ()
wrote about "Re: [fpc-pascal] is scrypt available?" (in ):

On 10/26/2015 06:28 PM, David W Noon wrote:

[snip]

Well, we can start here:

<https://en.wikipedia.org/wiki/Secure_Hash_Algorithm>

I also own a couple of books by Bruce Schneier, the doyen of cryptography.

More recently, there is RFC 6234. This was published in 2011 and its hashes are considered secure at the moment.

<https://tools.ietf.org/html/rfc6234>

I could code up almost any of these algorithms you want. I have reference implementations under Linux to test the validity of my code. I would make any such code available under the Berkeley License (or GPL v3). Indeed, I would make the source code available to all FPC users if there is interest in hashing here.
- --
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlYvuqwACgkQogYgcI4W/5QTEACeIgNf72/m5i1d4XY4RkMbN0UR QocAnRBkqsYbQR7e7LGDOFK/ZVkG6/G7
=qaUT
-----END PGP SIGNATURE-----

There always is, I think.

From my point of view: when coding internet-connected applications,

you often meet all kinds of hashing algorithms.

Michael.

the project in question uses very few outside developed libraries or units... we don't want to drag in a whole lot of stuff that's not needed or used by the rest

The reason there are many units is because it is well refactored. Each unit represents a new Hash or Cipher implementation. So if you only want one (out of the many options), it will probably only pull in 2, maybe 3 units.

ok... one thing that confused me when looking at the wiki is it pointing out the lpk files and the repo but not much of anything else...

The wiki contains many Lazarus related things.... lpk is a Lazarus feature - ie: Lazarus Packages. The DCPCrypt project supplies a Lazarus Package for easy integration, but it is NOT required. I never use lpk's any more in any of my projects.

the screen shot is ok

I guess the problem with that is that there is nothing else to take a screenshot of - how does a screenshot of Hashes or Ciphers look like. ;-) So the brighten up the wiki page, a screenshot of the Component Palette icons was chosen.

there's not much else describing the capabilities available or giving examples...

If you looked at the actual "Ciphers" and "Hashes" directories, those units are pretty self explanatory. eg: Blowfish, TwoFish, Mars, ICE, IDEA etc can be seen in the unit names.

The wiki also gives an example (pure code) if you look in the Bug section of the wiki page. As for the bug, that is a corner case, and I haven't tested or reseached it much. But I doubt it would affect many people, so don't judge the whole DCPCrypt project based on that alone.

Regards,
- Graeme -

my comment was directed more at (eg) not using FCL or LCL to avoid pulling in all their stuff that is not needed... currently the project's server binary is less than 500K... the next largest binary is ~700K... the server implements 5 or 6 different protocols for connections... pretty sweet for such a small package compared to other things that do less but are much larger... oh yeah, this is completely non-GUI, too... all text/console mode O:)

the real problem, which i was apparently not clear about, is that it is a screen shot... that's all fine and good but a simple text list is easier to copy'n'paste into a plain text message when conversing with others ;)

yeah, that means i already have it... this is/was research before wasting the time downloading something that may not fit B)

The wiki also gives an example (pure code) if you look in the Bug section of the wiki page. As for the bug, that is a corner case, and I haven't tested or reseached it much. But I doubt it would affect many people, so don't judge the whole DCPCrypt project based on that alone.

no, that's not possible :lol:

David W Noon wrote

<https://en.wikipedia.org/wiki/Secure_Hash_Algorithm> <https://tools.ietf.org/html/rfc6234>

Do not use a normal hash function to store passwords. If the password file is stolen, the attackers can quickly determine most passwords.

There are special algorithms to securely store passwords. Common recommendations are: PBKDF2, bcrypt, scrypt.

Explanation from
https://en.wikipedia.org/wiki/Password_cracking#Prevention

"Many hashes used for storing passwords, such as MD5 and the SHA family, are designed for fast computation and efficient implementation in hardware. As a result, they are ineffective in preventing password cracking, especially with methods like rainbow tables. Using key stretching Algorithms, such as PBKDF2, to form password hashes can significantly reduce the rate at which passwords can be tested."

See also:
https://en.wikipedia.org/wiki/Key_derivation_function

scrypt for pascal appears to be offered here:
http://www.wolfgang-ehrhardt.de/crchash_en.html

2015-10-29 17:56 GMT+01:00 Klaus Hartnegg :

Good point. I'd even ask the question: do you really need to store the passwords? IOW, do you want to be able to send them back to the user? Or do you only need to check them?

Frederic Da Vitoria wrote

Good point. I'd even ask the question: do you really need to store the passwords? IOW, do you want to be able to send them back to the user? Or do you only need to check them?

in the use case being studied, passwords can only be compared or reset...

Frederic Da Vitoria wrote

I'd even ask the question: do you really need to store the passwords? IOW, do you want to be able to send them back to the user? Or do you only need to check them?

My latest access system does not use server sends the users an email, they must click on a link inside. With password there would have to be a plan B in case users forget a password. This is typically insecurity-questions, or an email with a link for a password reset. This means that whoever can access the emails, can gain access anyway. Thus using this as primary access method does not reduce recurity. I would argue that in most cases it even improves it.

The best way to store passwords is to not store passwords, not even hashes.

In our previous episode, Klaus Hartnegg said:

With password there would have to be a plan B in case users forget a password.

And now you need a plan B for when the user changes email address.

They also have to be created, and unless you're careful that will leave copies around the place in clear.

getPasswordFromUserWithRepeat(password);
password := salt + password;

If the string isn't already long enough, that second operation might create a new one on the heap without sanitising the original. This was discussed here a year or so ago [April '14] and it was agreed to be a problem, Michael VC contributed a fix but it's not the default.

Now that might seem to be a strictly local problem, but an increasing number of systems are implementing suspend/resume or process migration, which could leave sensitive data on disc or move it over a network.

2015-10-30 0:33 GMT+01:00 :

Do you really need to compare them or simply to validate them? I ask because in one project I worked on for an insurance company, we were forbidden to store the passwords. We stored only a kind of checksum for them. With something like CRC32 or even a higher resolution algorithm, you can efficiently check that the password is correct (with really low chances of false positives), minimize the storage space required and completely eradicate the possibility that someone will get the actual passwords from your database. This could be relevant if this is for a web site, many people use the same password on all the web sites so that if their password is revealed on one site, they would need to change all their passwords.

Frederic Da Vitoria wrote on Fri, 30 Oct 2015:

Do you really need to compare them or simply to validate them? I ask because in one project I worked on for an insurance company, we were forbidden to store the passwords. We stored only a kind of checksum for them. With something like CRC32 or even a higher resolution algorithm, you

Never ever use CRC32 in a crypto context, it's completely unsuited and easily cracked. The subject of this thread is already about finding an implementation for scrypt, which is a (at this time considered) secure hashing algorithm.

Jonas

2015-10-30 16:39 GMT+01:00 Jonas Maebe :

My point is precisely that in this situation, there would be nothing to crypt. Just check validity. So use CRC64 if you want (the size difference won't probably be relevant by current standards), but don't store the actual password. What isn't there can't be cracked, not even with future technology :-)

Frederic Da Vitoria wrote on Fri, 30 Oct 2015:

Yes, that's what *secure* hash functions are for. CRC32 is not secure in any way. scrypt and bcrypt are secure.

So use CRC64 if you want (the size difference won't probably be relevant by current standards), but don't store the actual password. What isn't there can't be cracked, not even with future technology :-)

It can already be cracked very quickly with yesterday's technology, using so-called rainbow tables. Or even just by quickly creating a hash collision, see e.g.
http://www.irongeek.com/i.php?page=videos/weak-hashing-algorithms-outlook-pst-file-crc32-password-cracking-example or http://www.woodmann.com/fravia/crctut1.htm

Jonas

that's what i meant... store only the hash and then compare the hashes...

this is for an old-school BBS that's being updated for the modern world... you remember BBSes, right? those things we used to dial into before the internet came along? back before win95 was foisted on the world? they used to be run on a few different mainframes, PDP-11s, Radio Shack Color Computers (aka the coco), TRS-80s, Apple //c, Macintoshes, IBMPC compatibles, TI-99s and many others ;)

this is what brought me here looking for SCrypt code... i had already found that BCrypt is easily cracked ;)

2015-10-30 10:04 GMT+01:00 Marco van de Voort :

Yes, this is where things could go wrong. And this is probably why some web sites ask 2 different mail addresses or one mail address and one phone number. OTOH, each time I lost my password recently, I NEVER got it back from a web site, I always got a link to reset it or a temporary password. This seems to indicate that the majority of the big web sites currently don't store the passwords.

Ideally you shouldn't store store the hash to the password. In this way, someone at your business, or someone with access to your business, or if someone mistakenly installs some malicious software, your users passwords can never be retrieved.

When someone logs into your software/site they send their password. Your server then converts that password to a hash and compares it to a hash associated with their account, and the password then goes away. No one can steal your customer password list since they are never stored and thus cannot be compromised.

The downside of that approach however is that it this opens up the possibility to create a matching hash on "inappropriate" passwords (too short, easy to look up/guess) and hence get access...

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Ralf Quint wrote

The downside of that approach however is that it this opens up the possibility to create a matching hash on "inappropriate" passwords (too short, easy to look up/guess) and hence get access...

And that's why we use cryptographically secure hash functions. This prevents the malicious attacker from creating a collision on purpose, and with a random collision at p = 1/2**128 you can practically ignore that possibility. It is more probable that the comparison function gets a zap from some cosmic ray and tells you a one for a zero.